[RFC] Add a .gitattributes file for use with git-merge-changelog

  [Am I really supposed to CC this to gcc@ like binutils/MAINTAINERS
says I should?]

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. Added this to my ~/.gitconfig:

--8<---------------cut here---------------start------------->8---
[merge "merge-changelog"]
        name = GNU-style ChangeLog merge driver
        driver = git-merge-changelog %O %A %B
--8<---------------cut here---------------end--------------->8---

    (You could just put it in the .git/config file for a given
    repository, but I can't really see much point in that.)

With this patch applied and the above two tasks done by whatever means
you deem best, you can say goodbye to merge conflicts in ChangeLog
files.

*IF* people will stop renaming the danged things, anyway.

[1]: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/git-merge-changelog.c

[Note: The docs for git-merge-changelog (the comments at the top) say
you need a .gitattributes in every directory.  The docs are wrong.
Ignore the docs.

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 "/".]

[Note 2: I already have copyright assignment papers on file for GDB.]
---
 .gitattributes | 3 +++
 1 file changed, 3 insertions(+)
 create mode 100644 .gitattributes
  

>>>>> "Samuel" == Samuel Bronson <naesten@gmail.com> writes:

Samuel> [Am I really supposed to CC this to gcc@ like binutils/MAINTAINERS
Samuel> says I should?]

I think just for files that are intended to be put in both trees and
shared.

Samuel> Individual users will still have to:
Samuel>  1. Install git-merge-changelog
Samuel>  2. Set up the merge driver in their git config

What happens if they do not?

Tom
  

Samuel Bronson <naesten@gmail.com> writes:

> diff --git a/.gitattributes b/.gitattributes
> new file mode 100644
> index 0000000..75abe79
> --- /dev/null
> +++ b/.gitattributes
> @@ -0,0 +1,3 @@
> +# See gnulib's lib/git-merge-changelog.c (or git-merge-changelog(1))
> +# to activate this
> +ChangeLog       merge=merge-changelog

NOTE: without feedback, I am likely to commit a .gitattribute file like
this as "obvious", though probably with some things moved from the
commit message to the file itself.

Also, I'm still wondering if it would be ChangeLog-worthy.
  

Samuel Bronson <naesten@gmail.com> writes:

> NOTE: without feedback, I am likely to commit a .gitattribute file like
> this as "obvious", though probably with some things moved from the
> commit message to the file itself.
>
> Also, I'm still wondering if it would be ChangeLog-worthy.

On second thought, it looks like my followup to Tromey's post got lost
on its way to gdb-patches (at least) because I missed a mail from gmane
telling me I needed to authorize for it to actually get sent.

Oops!  I guess I should tread more carefully when I see "Newsgroups: "
headers in my message-mode buffers ...  I wonder how many other mails
got lost in limbo?

So, maybe people were just waiting to see my response before chiming in,
rather than being totally uninterested in my proposal.

(The thinking behind the previous message was basically "If nobody
actually cares, nobody will care enough to revert it either, right?"
Obviously, this assumes that I don't somehow cause anything to explode,
but then I rarely propose to commit a change to anything that I *expect*
will cause explosions.)
  

Ouch; it looks like my last attempt to reply to this missed gdb-patches@
due to a gmane accident?

Samuel Bronson <naesten@gmail.com> writes:

> Tom Tromey <tromey@redhat.com> writes:
>>>>>>> "Samuel" == Samuel Bronson <naesten@gmail.com> writes:
>>
>> Samuel> [Am I really supposed to CC this to gcc@ like binutils/MAINTAINERS
>> Samuel> says I should?]
>>
>> I think just for files that are intended to be put in both trees and
>> shared.
>
> Well, they're certainly welcome to add such a file to their repository.
>
>> Samuel> Individual users will still have to:
>> Samuel>  1. Install git-merge-changelog
>> Samuel>  2. Set up the merge driver in their git config
>>
>> What happens if they do not?
>
> Not much; git just falls back to the default ("text") merge driver in
> that case.  (This appears to have been so obvious that nobody actually
> bothered to document it?)
>
> I find myself wondering: how much commentary should go into the
> .gitattributes file, and do such files get ChangeLog entries?
>
> --
> Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!
>
>
  

Ping?  If nobody has anything else to say, I'm going to assume that such
a change is unobjectionable, and should not be listed in the ChangeLog.

Samuel Bronson <naesten@gmail.com> writes:

> Ouch; it looks like my last attempt to reply to this missed gdb-patches@
> due to a gmane accident?
>
> Samuel Bronson <naesten@gmail.com> writes:
>
>> Tom Tromey <tromey@redhat.com> writes:
>>>>>>>> "Samuel" == Samuel Bronson <naesten@gmail.com> writes:
>>>
>>> Samuel> [Am I really supposed to CC this to gcc@ like binutils/MAINTAINERS
>>> Samuel> says I should?]
>>>
>>> I think just for files that are intended to be put in both trees and
>>> shared.
>>
>> Well, they're certainly welcome to add such a file to their repository.
>>
>>> Samuel> Individual users will still have to:
>>> Samuel>  1. Install git-merge-changelog
>>> Samuel>  2. Set up the merge driver in their git config
>>>
>>> What happens if they do not?
>>
>> Not much; git just falls back to the default ("text") merge driver in
>> that case.  (This appears to have been so obvious that nobody actually
>> bothered to document it?)
>>
>> I find myself wondering: how much commentary should go into the
>> .gitattributes file, and do such files get ChangeLog entries?
  

Hi Samuel,

This seems like a good idea to me.

On 07/08/2014 02:35 AM, Samuel Bronson wrote:
> Ping?  If nobody has anything else to say, I'm going to assume that such
> a change is unobjectionable, and should not be listed in the ChangeLog.

When in doubt, look for precedence.

grep will show changes to other .git* files were listed in ChangeLog:

 $ grep "\.git" ChangeLog* gdb/ChangeLog*
 ChangeLog:      * .gitignore: Import from gdb repository.
 ChangeLog:      * .gitignore: New file.
 gdb/ChangeLog-2011:     * .gitignore: New file.
 gdb/ChangeLog-2012:     * .gitignore: Add go-exp.c.
 gdb/ChangeLog-2012:     * .gitignore: Ignore more files.
 gdb/ChangeLog-2012:     * .gitignore (/gdbtui): Remove.
 gdb/ChangeLog-2013:     * .gitignore: Add /gcore.

Likewise 'git log .gitignore gdb/.gitignore'.