--
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]
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]
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 (subscriber, #67594)
[Link]
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/
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]
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.