Udev and systemd to merge

Posted Apr 4, 2012 9:43 UTC (Wed) by Aissen (subscriber, #59976)
Parent article: Udev and systemd to merge

Sad thing about this merge of source trees: loss of udev's git history. Where is my git blame ? (Ok, we'd blame it all on Kay anyway).

History preservation would have been possible with subtree merging:
http://help.github.com/subtree-merge/

Udev and systemd to merge

Posted Apr 4, 2012 11:35 UTC (Wed) by mezcalero (subscriber, #45103) [Link] (8 responses)

udev's git history is not lost. We merged the two repositories with both full histories. The wonders of git.

Udev and systemd to merge

Posted Apr 4, 2012 11:48 UTC (Wed) by zuki (subscriber, #41808) [Link] (7 responses)

Yeah, systemd now seems to go all the way back to:

commit f0083e3d4eb49e11fd7e37532dc64a6e6f5d4039
Author: Greg KH <greg@press.(none)>
Date: Tue Apr 26 20:59:47 2005 -0700

added initial files.

Udev and systemd to merge

Posted Apr 4, 2012 12:51 UTC (Wed) by yoshi314 (guest, #36190) [Link] (6 responses)

too bad http://cgit.freedesktop.org/systemd/systemd/log/src/udev does not show much, even though the global log does.

Udev and systemd to merge

Posted Apr 4, 2012 13:00 UTC (Wed) by Aissen (subscriber, #59976) [Link] (5 responses)

Exactly my point. The first thing I did was:

$ git log --follow src/udev/udevd.c
commit 3e2147858f21943d5f4a781c60f33ac22c6096ed
Author: Kay Sievers <kay.sievers@vrfy.org>
Date: Tue Apr 3 21:24:46 2012 +0200

move imported udev into place

--
And that was all. Then git blame on the same file seems to have all the history. So what should I do to have git log show me the full history ?

Udev and systemd to merge

Posted Apr 4, 2012 14:20 UTC (Wed) by niner (subscriber, #26151) [Link] (4 responses)

You have to use the path the file had in the original repository.

Udev and systemd to merge

Posted Apr 4, 2012 14:54 UTC (Wed) by Aissen (subscriber, #59976) [Link] (3 responses)

Indeed, "git log --follow -- src/udevd.c" is giving the expected result — almost: it only shows the old commits.
It's a weird behaviour "git log" is having here, I don't fully understand why.

Udev and systemd to merge

Posted Apr 4, 2012 20:28 UTC (Wed) by przemoc (guest, #67594) [Link] (2 responses)

Maybe "merging" wasn't done right after all?

commit ad29a9f14fa8b1932c0e418bfcf1c10ce6a35a33
Author: Kay Sievers <kay.sievers@vrfy.org>
Date: Thu Jan 5 22:41:45 2012 +0100

merge udev/, libudev/, systemd/ files in src/; move extras/ to src/

R099 udev/udevd.c src/udevd.c

commit 3e2147858f21943d5f4a781c60f33ac22c6096ed
Author: Kay Sievers <kay.sievers@vrfy.org>
Date: Tue Apr 3 21:24:46 2012 +0200

move imported udev into place

R099 src/udev/src/udevd.c src/udev/udevd.c

Or git is losing some traces?

$ git log --follow --name-status -- src/udev/src/udevd.c
commit 3e2147858f21943d5f4a781c60f33ac22c6096ed
Author: Kay Sievers <kay.sievers@vrfy.org>
Date: Tue Apr 3 21:24:46 2012 +0200

move imported udev into place

D src/udev/src/udevd.c

It's interesting that the only history of this file is its deletion. ;-)

--
1.7.9.1

Udev and systemd to merge

Posted Apr 4, 2012 23:26 UTC (Wed) by geofft (subscriber, #59789) [Link] (1 responses)

If you pass a filename argument to git log with --stat or similar, it'll only show the changes that apply to that filename.

(I'm not sure this is the correct behavior, but it is the current behavior.)

Udev and systemd to merge

Posted Apr 6, 2012 7:33 UTC (Fri) by MaZe (subscriber, #53908) [Link]

This is a fundamental git metadata format bug.

a commit object includes 0 or more parent hashes.
initial commit having 0,
normal commits having 1,
merges having 2 or more.

a normal two-way merge thus has 2 parent hashes.
a subtree two-way merge also has 2 parent hashes.

nowhere in the merge commit metadata is the fact that it is a subtree merge recorded (nor is the subtree directory recorded)

ie. the fix would be to include not only the parent's hash, but also the subdirectory at which the parent commit is being merged.

Since the subtree merge commit does not include anything to distinguish it from a normal non-subtree merge, it is not possible to (cheaply in terms of processing power) determine that all changes happening at path X/Y/Z within the subtree parent history should actually be treated as happening at subtree/X/Y/Z.

When running something like git log across a commit, ie. across it's history, git has to look at hundreds or thousands or tens of thousands of merges, it cannot afford to devote cpu time to figuring out whether a merge commit is a subtree commit, so it assumes all of them aren't.

As a result of this, once starts looking at the parent of a subtree merge (and its parents), the assumption that the tree is rooted at / is no longer correct.

As a result:
git log subtree/X/Y/Z will show changes to Z since the subtree merge
git log X/Y/Z will show changes to Z before the subtree merge

Worse, if you have Makefile, and merge another project with a Makefile into subdirectory dir:
git log dir/Makefile shows changes since the subtree merge
git log Makefile shows all changes to the Makefile and changes to dir/Makefile from before the subtree merged - interspersed.

This could be fixed by having instead of
parent <hash>
information in the commit object something like
parent <hash> @ subtree

[for extra brownies also allow the opposite, ie. supertree merges, where you merge not commit into directory, but commit:directory into /, or even super-subtree merges, where you merge commit:directory into other_directory]

so the generic format should allow:
parent <hash>:directory/path @ subtree/path

and all the tools should be taught to follow such parent links properly.

Unfortunately, this will not fix subtree merges performed with old versions of git, and it is a backwards incompatible change.