automake-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [FYI] Fix regression in test `colon4.test'.


From: Ralf Wildenhues
Subject: Re: [FYI] Fix regression in test `colon4.test'.
Date: Mon, 13 Sep 2010 22:10:15 +0200
User-agent: Mutt/1.5.20 (2010-08-04)

* Stefano Lattarini wrote on Mon, Sep 13, 2010 at 09:41:18PM CEST:
> On Monday 13 September 2010, Ralf Wildenhues wrote:
> > * Stefano Lattarini wrote on Mon, Sep 13, 2010 at 03:14:25PM CEST:
> > > Regression introduced by change "Modernize, improve and/or
> > > extend tests `colon*.test" (Stefano Lattarini, 2010-08-08).
> > 
> > If you refer to older commits, you can just do that with the string
> > generated by 'git describe' rather than the summary line of the
> > change, or the author.

> But I think it's better to keep the content of the ChangeLog
> self-contained in this respect, if possible.

IMVHO it's better to do away with the ChangeLog completely.
But that's for another day.  My point is that this practice
keeps the git log worse than it could be.  I'm really mostly
interested in having a decent git log, since with branching
and all, the ChangeLog is only good for copyright recording.

> After all, if
> someone has access to the git repository, he can just look up
> what the parent commit of the bug-fixing commit is, and voila,
> he knows what the bug-introducing commit is.

This assumes that everyone follows this all the time, that
readers are aware of the policy, and that you never need to
refer to commits other than the previous one.

I'm pushing this to maint.


    * HACKING: Hint at old commits with `git describe' output.

diff --git a/HACKING b/HACKING
index d9b2099..ecbd0a8 100644
--- a/HACKING
+++ b/HACKING
@@ -143,6 +143,8 @@
   the active branches descending from the buggy commit.  This offers a
   simple way to fix the bug consistently and effectively.
 
+* When referring to older commits, use 'git describe' output as pointer.
+
 * There may be a number of longer-lived feature branches for new developments.
   They should be based off of a common ancestor of all active branches to
   which the feature should be merged later.  The next branch may serve as



reply via email to

[Prev in Thread] Current Thread [Next in Thread]