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

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

[Samuel Bronson]

[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

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
-- 
2.0.0

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

[Tom Tromey]

>>>>> "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

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

[Samuel Bronson]

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!

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

[Samuel Bronson]

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!
>
>

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!

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

[Samuel Bronson]

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! I'm a .signature virus! Copy me into your ~/.signature to help me spread!

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

[Pedro Alves]

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'.

-- 
Pedro Alves

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

[Samuel Bronson]

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.

[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
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.]
---
 .gitattributes | 20 ++++++++++++++++++++
 ChangeLog      |  4 ++++
 2 files changed, 24 insertions(+)
 create mode 100644 .gitattributes

diff --git a/.gitattributes b/.gitattributes
new file mode 100644
index 0000000..06d51d2
--- /dev/null
+++ b/.gitattributes
@@ -0,0 +1,20 @@
+# -*- conf -*-
+
+## Set merge driver for ChangeLog files 
+# See gnulib's lib/git-merge-changelog.c (or git-merge-changelog(1))
+# for per-user setup instructions.
+#
+# The short version of this (optional) procedure is:
+# 
+# (1) Install git-merge-changelog (this is the tricky part!)
+#
+# (2) Add something like the following to your ~/.gitconfig:
+#
+# [merge "merge-changelog"]
+#         name = GNU-style ChangeLog merge driver
+#         driver = git-merge-changelog %O %A %B
+#
+# (3) Enjoy mostly effortless ChangeLog merges, at least until the
+#     file gets renamed again ...
+
+ChangeLog       merge=merge-changelog
diff --git a/ChangeLog b/ChangeLog
index 16047d3..5c8fe15 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2014-07-25  Samuel Bronson  <naesten@gmail.com>
+
+	* .gitattributes: New file for use with git-merge-changelog.
+
 2014-07-21  Joel Sherrill  <joel.sherrill@oarcorp.com>
 
 	Disable gdb for or1k*-*-* until supported
-- 
2.0.1

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

[Samuel Bronson]

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.

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!

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

[Samuel Bronson]

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.)

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!