Message ID | 87sin0gvr3.fsf@naesten.mooo.com |
---|---|
State | New, archived |
Headers |
Received: (qmail 32687 invoked by alias); 20 Jun 2014 02:28:35 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 32574 invoked by uid 89); 20 Jun 2014 02:28:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=unavailable version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-qa0-f44.google.com Received: from mail-qa0-f44.google.com (HELO mail-qa0-f44.google.com) (209.85.216.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 20 Jun 2014 02:28:24 +0000 Received: by mail-qa0-f44.google.com with SMTP id hw13so2716666qab.31 for <multiple recipients>; Thu, 19 Jun 2014 19:28:21 -0700 (PDT) X-Received: by 10.140.49.171 with SMTP id q40mr539625qga.7.1403231301272; Thu, 19 Jun 2014 19:28:21 -0700 (PDT) Received: from hydrogen (naesten-pt.tunnel.tserv4.nyc4.ipv6.he.net. [2001:470:1f06:57::2]) by mx.google.com with ESMTPSA id m1sm11424831qaz.27.2014.06.19.19.28.19 for <multiple recipients> (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 19 Jun 2014 19:28:20 -0700 (PDT) Received: from naesten by hydrogen with local (Exim 4.82) (envelope-from <naesten@gmail.com>) id 1WxoYq-0005SR-TU; Thu, 19 Jun 2014 22:28:16 -0400 From: Samuel Bronson <naesten@gmail.com> To: binutils@sourceware.org,gdb-patches@sourceware.org Cc: gcc-patches@gcc.gnu.org Subject: [RFC] Add a .gitattributes file for use with git-merge-changelog Date: Thu, 19 Jun 2014 21:59:19 -0400 Message-ID: <87sin0gvr3.fsf@naesten.mooo.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes |
Commit Message
Samuel Bronson
June 20, 2014, 1:59 a.m. UTC
[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
Comments
>>>>> "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'.
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