Re: ChangeLog (was Re: bug with named pipes and process substitution)

[Daniel Shahaf <d.s@daniel.shahaf.name>]

Kamil Dudka wrote on Thu, Jul 23, 2015 at 10:15:40 +0200:
> On Wednesday 22 July 2015 18:46:18 Bart Schaefer wrote:
> > On Jul 23,  3:03am, Mikael Magnusson wrote:
> > }
> > } > "git stash"-ing all my changes to re-apply after sourceforge is back.
> > }
> > } Why would you do that rather than just committing them?
> > 
> > Because (a) I spent the last six days thinking "gee, they've got to be
> > back on line any minute now" and (b) I prefer to "git pull" and then
> > edit the ChangeLog to reduce the chances of a conflict on ChangeLog,
> > because (c) even with --rebase I find the way git handles overlapping
> > diffs in a file that grows at the top to be really annoying and (d) I
> > want the ChangeLog entry to be the same commit as the rest of the diff.
> 
> Do the ChangeLog entries actually capture anything that commit messages
> can not?  Would not it be better to just generate ChangeLog from git log?
> 
> Unlike ChangeLog as a text file, a conflict on commit messages can never 
> happen.
> 

That's what I do: locally I have just the log messages, and I generate
the ChangeLog from them prior to pushing.  (I just reuse the first
sentence verbatim, but any transformation could be substituted.)

An alternative is to use a custom merge tool that automatically resolves
conflicts on ChangeLog, and defers to the default merge tool for
conflicts on other files.  I think http://svn.apache.org/r1491816 is
exactly the sort of functionality that would be useful for the ChangeLog
file: it just concatenates the "<<<<<<" and ">>>>>>" sides of the
conflict.

(I don't know if git has equivalent functionality built-in, however,
I do know that mergetools are configurable so I think custom mergetool
could implement equivalent functionality.)

> Kamil