public inbox for
help / color / mirror / Atom feed
Subject: gdb and binutils branch master updated. a843ea33df65b47d5ff525231a5b582e9cd4e5b3
Date: Fri, 25 Jul 2014 22:43:00 -0000	[thread overview]
Message-ID: <> (raw)

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "gdb and binutils".

The branch, master has been updated
       via  a843ea33df65b47d5ff525231a5b582e9cd4e5b3 (commit)
      from  d54398a79e97eff8f51aed2035cb513cdc4fb319 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------;h=a843ea33df65b47d5ff525231a5b582e9cd4e5b3

commit a843ea33df65b47d5ff525231a5b582e9cd4e5b3
Author: Samuel Bronson <>
Date:   Thu Jun 19 21:59:19 2014 -0400

    Add a .gitattributes file for use with git-merge-changelog
    Individual users will still have to:
     1. Install git-merge-changelog
     2. Set up the merge driver in their git config
    See gnulib's lib/git-merge-changelog.c [1] for details.
    For example, I:
     1. Patched Debian's gnulib package to build git-merge-changelog, and
        sent the patch to the Debian maintainer, who then proceeded to not
        only accept my patch but even write a *manpage* for
        git-merge-changelog! (Let's hear it for Ian Beckwith.)
        So now, I can install it simply by running "apt-get install
        git-merge-changelog".  (Except, of course, that I already have it
        installed from when I was testing my patch.)
     2. Did step (2) from .gitattributes
    With this patch applied and the above two steps done by whatever means
    you deem best, you can say goodbye to merge conflicts in ChangeLog
    files -- at least *IF* people stop renaming the danged things, anyway.
    If you don't do step 2, you will continue to suffer from ChangeLog
    merge conflicts exactly as before, whether or not you did step 1.
    If you do step 2 but not step 1, git will likely start complaining
    that it can't find any "git-merge-changelog" to run.
    [Note: The docs for git-merge-changelog (the comments at the top) say
    that you need a .gitattributes in every directory.  The docs are wrong.
    Ignore the docs.  Well, not the whole docs; just that part.
    You really only need one at the top level, since .gitattributes uses
    the same pattern matching rules as .gitignore, which match files in
    any subdirectory unless you prefix the pattern with a "/", as
    explained in the gitignore(5) manpage.]


Summary of changes:
 .gitattributes |   20 ++++++++++++++++++++
 ChangeLog      |    4 ++++
 2 files changed, 24 insertions(+), 0 deletions(-)
 create mode 100644 .gitattributes

gdb and binutils

                 reply	other threads:[~2014-07-25 22:43 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).