What's missing from our changelogs [LWN.net]

What's missing from our changelogs

Posted Jul 27, 2013 2:18 UTC (Sat) by rjw@sisk.pl (subscriber, #39252)
Parent article: What's missing from our changelogs

Please allow me to disagree with this:

Without a chain of signoff lines, we lose more than a picture of which maintainers might have reviewed the patches; we also lose track of the path by which a patch finds its way into the mainline.

Given a commit hash you can always do

$ git log --ancestry-path --merges <commit>..HEAD

go to the bottom of the log and see whose hands the commit has gone through.

to post comments

What's missing from our changelogs

Posted Jul 27, 2013 13:31 UTC (Sat) by corbet (editor, #1) [Link] (2 responses)

Interesting, I just tried that with randomly chosen commit b4419e1a15905191661ffe75ba2f9e649f5d565e (a GPIO fix) and found that it listed the thermal and tracing trees, which are unlikely to have hosted that patch. --ancestry-path prints all intervening commits, so there's a lot of extra noise, while, of course, any fast-forward merges will be missing. A useful tool but not a definitive answer.

What's missing from our changelogs

Posted Jul 30, 2013 4:38 UTC (Tue) by neilbrown (subscriber, #359) [Link] (1 responses)

I'd suggest that was a poor example as it was merged directly by Linus, so there is only one interesting merge.

fast-forward merges are certain to cause problems, and we should probably dictate that maintainers *must*not*do*that* (--no-ff please!)(they probably already do?). Assuming a lack for fast-forward patches, "git name-rev" can help.

e.g.

$ git name-rev 453807f3006757a5661c4000262d7d9284b5214c
453807f3006757a5661c4000262d7d9284b5214c tags/v3.10-rc1~14^2~20^2~3^2~29

Then apply the following (which can obviously be scripted):

% git log -n1 --format=short tags/v3.10-rc1~14^2~20^2~3^2~29
commit 453807f3006757a5661c4000262d7d9284b5214c
Author: Lars-Peter Clausen <lars@metafoo.de>

    ASoC: ep93xx: Use ep93xx_dma_params instead of ep93xx_pcm_dma_params
% git log -n1 --format=short tags/v3.10-rc1~14^2~20^2~3     
commit 9eb8ae727dcb9f2530a895ee6b3496592853709d
Merge: 5561f17 6f1fd93
Author: Mark Brown <broonie@opensource.wolfsonmicro.com>

    Merge remote-tracking branch 'asoc/topic/dma' into asoc-next
% git log -n1 --format=short tags/v3.10-rc1~14^2~20    
commit 2fc565e4eaf8fc633bfc741b90e1f28dba732ee1
Merge: 7fc7d04 5cc50fc8
Author: Takashi Iwai <tiwai@suse.de>

    Merge tag 'asoc-v3.10-3' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-next
% git log -n1 --format=short tags/v3.10-rc1~14     
commit 05a88a43604abb816dfbff075bb114224641793b
Merge: daf799c 6c35ae3
Author: Linus Torvalds <torvalds@linux-foundation.org>

    Merge tag 'sound-3.10' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound

and you have the merge commits that merged the patch into the trunk and the people responsible. (interesting commits to experiment with can be found via

git log | git name-rev --stdin | grep '~.*~.*~.*~.*~'

with varying numbers of '~' in the 'grep')

What's missing from our changelogs

Posted Jul 30, 2013 16:07 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

> we should probably dictate that maintainers *must*not*do*that* (--no-ff please!)

Does setting the noff option in gitconfig still force pull-merges without pull.rebase to true? Merges with --no-ff are great, but pull merges are really quite a bit worse, IMO. (I don't care how often you pull from a remote, just don't modify the tree when you do it). Also, it means that if there are conflicts, they happen when merging a remote into your branch which is backwards since your branch is topologically older.