Re: displaying subtree merges

[Junio C Hamano <gitster@pobox.com>]

Zbigniew Jędrzejewski-Szmek  <zbyszek@in.waw.pl> writes:

> what is the best way to display merge commits of two branches with
> separate roots?
> ...
> % git log --oneline --follow -- src/udevd.c
> 4309599 warn about deprecated RUN+="socket:" use
> e64fae5 udevd: kill hanging event processes after 30 seconds
> 912541b tabs are as useful as a hole in the head
> ad29a9f merge udev/, libudev/, systemd/ files in src/; move extras/ to src/
> ...
>
> [src/udev/src/udevd.c is the original path]

I am absolutely sure I wrote on how to look at gitk and gitweb part of the
history on this list in the past few months, but my archive digging skill
seems to be failing me today X-<.

I'd do something like this

	(
		echo ^v1.7.9
		git rev-list --first-parent --parents \
                	v1.7.9..master -- gitk-git |
	        sed -e 's/.* //'
	) | xargs git log

when I want to see a more detailed history than

	git log v1.7.9..master -- gitk-git

would give me.  The inner rev-list grabs the tips of the gitk history as
of each merge points between v1.7.9..master, and the first echo ^v1.7.9
excludes the part of gitk history that were already in v1.7.9.

> Is there a way to follow the history also in the subtree?

In any case, from the point of view of the history that is merged into the
other history as its subpart, each and every merge looks like a humongous
rename with bunch of new additions.  It is a known limitation of the
"subtree" merge, which was an ugly hack I invented before submodules have
become ready.  It does not help that the "--follow" is merely a checkbox
hack and does not keep track of different set of paths for each individual
traversal point is digging the history for; improving "--follow" to do so
will make it more useful but nobody has bothered.