Stefano Lattarini wrote:
> On Saturday 10 December 2011, Jim Meyering wrote:
>> I have not taken the time to write a commit hook to warn me when
>> a git log fails to match the corresponding ChangeLog delta.
>> It doesn't seem worthwhile.
>>
> Absolutely agreed; especially because, as long as the ChangeLog
> is version-controlled, it can be fixed with later patches ...
Sounds like you misunderstood. What I would like is a git commit hook
that verifies, given there are ChangeLog diffs, that they match the commit
log text. Since packages that I care about that also VC a ChangeLog file
are so few, it hasn't been enough of a problem to merit my writing the script.
Perhaps you didn't see this:
A ChangeLog that is generated from gitlog-to-changelog may now be corrected:
http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/28858
...
>> > This is inspired to commit v1.11-389-g6da46f3, with additional
>>
>> s/inspired to/inspired by/
>>
> Ouch. But I have already pushed, so we can't change the git commit
> message without distrupting the history; this typo will have to
> live on. Annoying, but no biggie.
Yes, I noticed that, and do know that public git log are essentially
immutable. That's why I made it so gitlog-to-changelog can now
generate a corrected ChangeLog.
>> And in commit logs I like to use the 8-hex-digit SHA1
>> representation (perhaps in addition to something like you've
>> provided) because gitk automatically detects that and renders
>> it as a clickable link.
>>
> But reading from Automake's HACKING file:
>
> * When referring to older commits, use 'git describe' output as
> pointer.
>
> Do you think your use case would make it worth to change this policy
> and introducing another (admittedly small) inconsistency in the git
> commit messages from now on? I have no strong feelings, but I'd
> rather avoid another "policy churn" (albeit small) if the gain would
> be only marginal.
>
>> I admit that in a non-interactive rendering of the log,
>> your longer form is much more useful.
>>
> Also, note that at least git, qgit and gitk seems to understand the
> output of git-describe as well *when given as an argument on the
> command line*.
>
> Maybe you could file a feature-request to gitk and/or qgit so that
> they can recognize and highlight `git describe' outputs as well as
> eight-hexdigit SHA1. WDYT?
Yes, that would be better than making automake's log less readable.
I posted a patch to make gitk do that:
http://marc.info/?l=git&m=132352985007591&w=2
However, note that the commit in question might not be highlighted
with my patch, because it refers to another branch. You'd have to
run gitk with --all or, say, with arguments "master branch-1.11"
in order to see the new highlighting.
