Eric Blake wrote: > According to Jim Meyering on 4/7/2009 2:56 AM: >> - use ChangeLog-style "* full-relative-name/to-each-affected-file >> (func,rule,etc.): description..." in the log, because that is what >> goes into the ChangeLog for gnulib. In coreutils, the log is the >> primary source, and ChangeLog is automatically generated from that. >> In gnulib, we don't all agree on policy, so we retain use of a VC'd >> ChangeLog, and here, my ChangeLog entries are identical (modulo the >> leading TABs which are in the file but not in log). When sending in >> "git format-patch" patches, I prefer *not* to have ChangeLog diffs, >> because they're very likely not to apply. > > If you use Bruno's git-merge-changelog program, and attach a > .gitattributes notation to your changelog that you do so, then ChangeLog > diffs have a high probability of applying correctly, even when ChangeLog > changes in between patch generation and patch application. Gnulib already > has the .gitattributes in place, but it still depends on you making the > manual configuration changes (either via 'git config', or manually editing > .git/config or ~/.gitconfig). But for an automated approach to this, see > m4's bootstrap script, which sees if git-merge-changelog is available in > the path, and if so, adds the git changelog merge driver if it is not > already configured, and if not, suggests that the user look into using it.
Thanks, but does that also help when reordering change sets via e.g., git rebase -i?
