{"thread":{"id":"23554","subject":"bug in name-rev on linux-2.6 repo?","startedAt":"2010-04-21T19:58:22Z","lastAt":"2010-04-24T23:04:15Z","messageCount":13,"participants":["maximilian attems","Tay Ray Chuan","Jonathan Nieder","Andreas Schwab","Jeff King","Linus Torvalds","tytso@mit.edu"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"140048","messageId":"20100421195822.GX10984@baikonur.stro.at","threadId":"23554","inReplyTo":null,"subject":"bug in name-rev on linux-2.6 repo?","fromName":"maximilian attems","fromEmail":"max@stro.at","sentAt":"2010-04-21T19:58:22Z","receivedAt":"2010-04-21T19:58:22Z","isPatch":false,"sender":{"key":"max@stro.at","avatar":"https://avatars.githubusercontent.com/u/1266461?v=4"},"body":"~/src/linux-2.6$ git name-rev a1de02dccf906faba2ee2d99cac56799bda3b96a\n a1de02dccf906faba2ee2d99cac56799bda3b96a undefined\n\n\n git --version\n git version 1.7.0.4\n\n\n~/src/linux-2.6$ git branch | grep ^*\n* master\n\nnever happened to me before but don't seem to get ancestry of\nthat ext4 merge, can you check what is wrong there?\nbug verified also on older git 1.6.5\n\nthanks\n\n-- \nmaks\n"},{"id":"140119","messageId":"r2sbe6fef0d1004220354g6443218ezbd0452428ad9e4b5@mail.gmail.com","threadId":"23554","inReplyTo":"20100421195822.GX10984@baikonur.stro.at","subject":"Re: bug in name-rev on linux-2.6 repo?","fromName":"Tay Ray Chuan","fromEmail":"rctay89@gmail.com","sentAt":"2010-04-22T10:54:18Z","receivedAt":"2010-04-22T10:54:18Z","isPatch":false,"sender":{"key":"rctay89@gmail.com","avatar":"https://avatars.githubusercontent.com/u/61553?v=4"},"body":"Hi,\n\nOn Thu, Apr 22, 2010 at 3:58 AM, maximilian attems <max@stro.at> wrote:\n> ~/src/linux-2.6$ git name-rev a1de02dccf906faba2ee2d99cac56799bda3b96a\n>  a1de02dccf906faba2ee2d99cac56799bda3b96a undefined\n\nhave you fetched tags too?\n\n-- \nCheers,\nRay Chuan\n"},{"id":"140123","messageId":"20100422121408.GI3211@stro.at","threadId":"23554","inReplyTo":"r2sbe6fef0d1004220354g6443218ezbd0452428ad9e4b5@mail.gmail.com","subject":"Re: bug in name-rev on linux-2.6 repo?","fromName":"maximilian attems","fromEmail":"max@stro.at","sentAt":"2010-04-22T12:14:08Z","receivedAt":"2010-04-22T12:14:08Z","isPatch":false,"sender":{"key":"max@stro.at","avatar":"https://avatars.githubusercontent.com/u/1266461?v=4"},"body":"On Thu, 22 Apr 2010, Tay Ray Chuan wrote:\n\n> Hi,\n> \n> On Thu, Apr 22, 2010 at 3:58 AM, maximilian attems <max@stro.at> wrote:\n> > ~/src/linux-2.6$ git name-rev a1de02dccf906faba2ee2d99cac56799bda3b96a\n> >  a1de02dccf906faba2ee2d99cac56799bda3b96a undefined\n> \n> have you fetched tags too?\n\n~/src/linux-2.6$ git tag | grep v2.6.34-rc1\n\nv2.6.34-rc1\n\ndid you try to reproduce at aboves repo the specific commit?\n-- \nmaks\n"},{"id":"140125","messageId":"20100422124042.GA1433@progeny.tock","threadId":"23554","inReplyTo":"20100422121408.GI3211@stro.at","subject":"Re: bug in name-rev on linux-2.6 repo?","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-04-22T12:40:43Z","receivedAt":"2010-04-22T12:40:43Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi maks,\n\nmaximilian attems wrote:\n\n> ~/src/linux-2.6$ git name-rev a1de02dccf906faba2ee2d99cac56799bda3b96a\n>  a1de02dccf906faba2ee2d99cac56799bda3b96a undefined\n\nThanks for pointing it out.  This is weird.\n\nThe commit doesn’t seem to be part of any tagged release, nor linus’s\nmaster:\n\n| $ git log ^v2.6.34-rc5 ^origin/master a1de02dccf --oneline\n| a1de02d ext4: fix async i/o writes beyond 4GB to a sparse file\n\nSo maybe it was rewritten; searching for a commit with the same subject:\n\n| $ git log v2.6.33..origin/master --grep='ext4: fix async' --oneline\n| a1de02d ext4: fix async i/o writes beyond 4GB to a sparse file\n\nHuh?  Is it included in origin/master or not?\n\n| $ git version\n| git version 1.7.1.rc1\n\nJonathan\n"},{"id":"140133","messageId":"m2hbn37e7q.fsf@igel.home","threadId":"23554","inReplyTo":"20100422124042.GA1433@progeny.tock","subject":"Re: bug in name-rev on linux-2.6 repo?","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2010-04-22T14:29:29Z","receivedAt":"2010-04-22T14:29:29Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"Jonathan Nieder <jrnieder@gmail.com> writes:\n\n> Hi maks,\n>\n> maximilian attems wrote:\n>\n>> ~/src/linux-2.6$ git name-rev a1de02dccf906faba2ee2d99cac56799bda3b96a\n>>  a1de02dccf906faba2ee2d99cac56799bda3b96a undefined\n>\n> Thanks for pointing it out.  This is weird.\n>\n> The commit doesn’t seem to be part of any tagged release, nor linus’s\n> master:\n\n$ git branch --contains a1de02dccf906faba2ee2d99cac56799bda3b96a\n* master\n$ git merge-base v2.6.34-rc1 a1de02dccf906faba2ee2d99cac56799bda3b96a\na1de02dccf906faba2ee2d99cac56799bda3b96a\ngit merge-base v2.6.33 a1de02dccf906faba2ee2d99cac56799bda3b96a\n724e6d3fe8003c3f60bf404bf22e4e331327c596\n\nSo it has been merged beween v2.6.33 and v2.6.34-rc1\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"},{"id":"140135","messageId":"20100422144433.GB28923@coredump.intra.peff.net","threadId":"23554","inReplyTo":"m2hbn37e7q.fsf@igel.home","subject":"Re: bug in name-rev on linux-2.6 repo?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-04-22T14:44:33Z","receivedAt":"2010-04-22T14:44:33Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Apr 22, 2010 at 04:29:29PM +0200, Andreas Schwab wrote:\n\n> Jonathan Nieder <jrnieder@gmail.com> writes:\n> \n> > Hi maks,\n> >\n> > maximilian attems wrote:\n> >\n> >> ~/src/linux-2.6$ git name-rev a1de02dccf906faba2ee2d99cac56799bda3b96a\n> >>  a1de02dccf906faba2ee2d99cac56799bda3b96a undefined\n> >\n> > Thanks for pointing it out.  This is weird.\n> >\n> > The commit doesn’t seem to be part of any tagged release, nor linus’s\n> > master:\n> \n> $ git branch --contains a1de02dccf906faba2ee2d99cac56799bda3b96a\n> * master\n> $ git merge-base v2.6.34-rc1 a1de02dccf906faba2ee2d99cac56799bda3b96a\n> a1de02dccf906faba2ee2d99cac56799bda3b96a\n> git merge-base v2.6.33 a1de02dccf906faba2ee2d99cac56799bda3b96a\n> 724e6d3fe8003c3f60bf404bf22e4e331327c596\n> \n> So it has been merged beween v2.6.33 and v2.6.34-rc1\n\nHmm. Maybe clock skew in the commit timestamps is at fault? With this\npatch to git:\n\ndiff --git a/builtin/name-rev.c b/builtin/name-rev.c\nindex 06a38ac..7a024ab 100644\n--- a/builtin/name-rev.c\n+++ b/builtin/name-rev.c\n@@ -29,9 +29,6 @@ static void name_rev(struct commit *commit,\n \tif (!commit->object.parsed)\n \t\tparse_commit(commit);\n \n-\tif (commit->date < cutoff)\n-\t\treturn;\n-\n \tif (deref) {\n \t\tchar *new_name = xmalloc(strlen(tip_name)+3);\n \t\tstrcpy(new_name, tip_name);\n\nI get:\n\n  $ $ git name-rev a1de02dccf906faba2ee2d99cac56799bda3b96a\n  a1de02dccf906faba2ee2d99cac56799bda3b96a tags/v2.6.34-rc1~199^2~35\n\nbut I haven't tracked down the problematic commit and timestamp yet.\n\n-Peff\n"},{"id":"140136","messageId":"20100422145111.GA4801@progeny.tock","threadId":"23554","inReplyTo":"m2hbn37e7q.fsf@igel.home","subject":"Re: bug in name-rev on linux-2.6 repo?","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-04-22T14:51:11Z","receivedAt":"2010-04-22T14:51:11Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Andreas Schwab wrote:\n> Jonathan Nieder <jrnieder@gmail.com> writes:\n\n>> The commit doesn’t seem to be part of any tagged release, nor linus’s\n>> master:\n>\n> $ git branch --contains a1de02dccf906faba2ee2d99cac56799bda3b96a\n> * master\n> $ git merge-base v2.6.34-rc1 a1de02dccf906faba2ee2d99cac56799bda3b96a\n> a1de02dccf906faba2ee2d99cac56799bda3b96a\n> git merge-base v2.6.33 a1de02dccf906faba2ee2d99cac56799bda3b96a\n> 724e6d3fe8003c3f60bf404bf22e4e331327c596\n> \n> So it has been merged beween v2.6.33 and v2.6.34-rc1\n\nTo first commit after rc8, to be exact.  But for some reason, the\nrevision walker doesn’t notice that:\n\n $ git rev-list origin/master..a1de02dcc | wc -l\n 1\n\nThe tip of the relevant branch before merging was 64e290e (thanks to\nJohan’s --ancestor-path suggestion and Junio’s nice implementation).\nSo we can walk up through the revisions:\n\n $ git rev-parse 64e290e~35\n a1de02dccf906faba2ee2d99cac56799bda3b96a\n $ git rev-list origin/master..64e290e~35 | wc -l\n 0\n $ git rev-list origin/master..$(git rev-parse 64e290e~35) | wc -l\n 1\n $ for i in 36 35 34 33 32 31 30\n > do\n >\tprintf \"%d \" \"$i\"\n >\tgit rev-list origin/master..$(git rev-parse 64e290e~$i) | wc -l\n > done\n 36 0\n 35 1\n 34 2\n 33 3\n 32 4\n 31 0\n 30 0\n\nUsing v2.6.34-rc1~199 (the ext4 merge commit) instead of origin/master\nreveals the same problem.  v2.6.34-rc1~199^2 (the tip of the ext4\nbranch) does not.\n\nHope that helps.\nJonathan\n"},{"id":"140137","messageId":"20100422145455.GC28923@coredump.intra.peff.net","threadId":"23554","inReplyTo":"20100422144433.GB28923@coredump.intra.peff.net","subject":"Re: bug in name-rev on linux-2.6 repo?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-04-22T14:54:55Z","receivedAt":"2010-04-22T14:54:55Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Apr 22, 2010 at 10:44:33AM -0400, Jeff King wrote:\n\n> Hmm. Maybe clock skew in the commit timestamps is at fault? With this\n> patch to git:\n> \n> diff --git a/builtin/name-rev.c b/builtin/name-rev.c\n> index 06a38ac..7a024ab 100644\n> --- a/builtin/name-rev.c\n> +++ b/builtin/name-rev.c\n> @@ -29,9 +29,6 @@ static void name_rev(struct commit *commit,\n>  \tif (!commit->object.parsed)\n>  \t\tparse_commit(commit);\n>  \n> -\tif (commit->date < cutoff)\n> -\t\treturn;\n> -\n>  \tif (deref) {\n>  \t\tchar *new_name = xmalloc(strlen(tip_name)+3);\n>  \t\tstrcpy(new_name, tip_name);\n> \n> I get:\n> \n>   $ $ git name-rev a1de02dccf906faba2ee2d99cac56799bda3b96a\n>   a1de02dccf906faba2ee2d99cac56799bda3b96a tags/v2.6.34-rc1~199^2~35\n> \n> but I haven't tracked down the problematic commit and timestamp yet.\n\nStill looking, but definitely some kind of skew problem. Reverting the\npatch above and doing this also works:\n\ndiff --git a/builtin/name-rev.c b/builtin/name-rev.c\nindex 06a38ac..198e04d 100644\n--- a/builtin/name-rev.c\n+++ b/builtin/name-rev.c\n@@ -5,7 +5,7 @@\n #include \"refs.h\"\n #include \"parse-options.h\"\n \n-#define CUTOFF_DATE_SLOP 86400 /* one day */\n+#define CUTOFF_DATE_SLOP (60*86400)\n \n typedef struct rev_name {\n \tconst char *tip_name;\n\nbut a 59-day slop does not.\n\n-Peff\n"},{"id":"140138","messageId":"20100422150325.GB4801@progeny.tock","threadId":"23554","inReplyTo":"20100422145455.GC28923@coredump.intra.peff.net","subject":"Re: bug in name-rev on linux-2.6 repo?","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-04-22T15:03:25Z","receivedAt":"2010-04-22T15:03:25Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Jeff King wrote:\n\n> Still looking, but definitely some kind of skew problem.\n\nThat explains it, then:\n\n$ git log --format=%cd' %h' 19f5fb7 ^v2.6.34-rc1~200\nSun Jan 24 14:34:07 2010 -0500 19f5fb7\nMon Dec 7 10:36:20 2009 -0500 d2eecb0\nFri Jan 1 01:00:21 2010 -0500 f8ec9d6\nWed Dec 23 07:45:44 2009 -0500 71f2be2\nFri Jan 22 17:40:42 2010 -0500 1f2acb6\nMon Feb 15 20:17:55 2010 -0500 15121c1\nThu Feb 4 23:58:38 2010 -0500 a1de02d\n\nThis part of the history is linear.\n\nIs the rule that every commit must be at most one day before each of\nits parents?  This should probably be documented somewhere, since it\nis possible to override the committer date with GIT_COMMITTER_DATE.\n\nJonathan\n"},{"id":"140139","messageId":"20100422151708.GA15039@coredump.intra.peff.net","threadId":"23554","inReplyTo":"20100422150325.GB4801@progeny.tock","subject":"Re: bug in name-rev on linux-2.6 repo?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-04-22T15:17:08Z","receivedAt":"2010-04-22T15:17:08Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Apr 22, 2010 at 10:03:25AM -0500, Jonathan Nieder wrote:\n\n> Jeff King wrote:\n> \n> > Still looking, but definitely some kind of skew problem.\n> \n> That explains it, then:\n> \n> $ git log --format=%cd' %h' 19f5fb7 ^v2.6.34-rc1~200\n> Sun Jan 24 14:34:07 2010 -0500 19f5fb7\n> Mon Dec 7 10:36:20 2009 -0500 d2eecb0\n> Fri Jan 1 01:00:21 2010 -0500 f8ec9d6\n> Wed Dec 23 07:45:44 2009 -0500 71f2be2\n> Fri Jan 22 17:40:42 2010 -0500 1f2acb6\n> Mon Feb 15 20:17:55 2010 -0500 15121c1\n> Thu Feb 4 23:58:38 2010 -0500 a1de02d\n> \n> This part of the history is linear.\n\nThanks for confirming, that was the same stretch of history I ended up\nlooking at.\n\n> Is the rule that every commit must be at most one day before each of\n> its parents?  This should probably be documented somewhere, since it\n> is possible to override the committer date with GIT_COMMITTER_DATE.\n\nThere is no hard and fast rule. We have to deal with _some_ clock skew,\nbut I think it has been anybody's guess how much. One can always treat\nthe graph purely topologically (which is what my first patch removing\nthe cutoff_date check did), but that usually means more computation. In\nthis case, we go all the way to the roots instead of looking at a\n\"recent\" subgraph. I think we also look at timestamps in rev-list when\nlinearizing to avoid doing a full topo-sort, but I don't remember what\neffects clock skew can have there.\n\nSo what should we do with this incident?\n\n  1. Declare it too much clock skew and ignore it.\n\n  2. Drop the cutoff optimization in favor of correctness. We already do\n     this for --stdin, as there is no sensible cutoff for multiple\n     inputs. So you can see how much slower it is:\n\n       $ time git name-rev a1de02dccf906faba2ee2d99cac56799bda3b96a\n       a1de02dccf906faba2ee2d99cac56799bda3b96a undefined\n\n       real    0m0.163s\n       user    0m0.140s\n       sys     0m0.020s\n\n       $ time echo a1de02dccf906faba2ee2d99cac56799bda3b96a |\n         git name-rev --stdin\n       a1de02dccf906faba2ee2d99cac56799bda3b96a (tags/v2.6.34-rc1~199^2~35)\n\n       real    0m3.411s\n       user    0m3.244s\n       sys     0m0.164s\n\n     So perhaps it is something one would want to enable with a\n     command-line option. Or even something we could fall back on\n     automatically as a \"slow case\" when coming up with an un-nameable\n     rev.\n\n  3. Bump the slop date. 60 days would work here. What's reasonable? A\n     year? At one year, we are still noticeably slower:\n\n       # patched for CUTOFF_SLOP_DATE (365*86400)\n       $ time git name-rev a1de02dccf906faba2ee2d99cac56799bda3b96a\n       a1de02dccf906faba2ee2d99cac56799bda3b96a\n       tags/v2.6.34-rc1~199^2~35\n\n       real    0m1.075s\n       user    0m1.028s\n       sys     0m0.044s\n\n-Peff\n"},{"id":"140141","messageId":"20100422162504.GA4913@progeny.tock","threadId":"23554","inReplyTo":"20100422151708.GA15039@coredump.intra.peff.net","subject":"Re: bug in name-rev on linux-2.6 repo?","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-04-22T16:25:04Z","receivedAt":"2010-04-22T16:25:04Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi Ted,\n\nmaximilian attems attems noticed that ‘git name-rev’ has trouble with\nsome commits from the ext4 tree [1].  Jeff King investigated:\n\nJeff King wrote:\n> On Thu, Apr 22, 2010 at 10:03:25AM -0500, Jonathan Nieder wrote:\n>> Jeff King wrote:\n\n>>> Still looking, but definitely some kind of skew problem.\n>>\n>> That explains it, then:\n>>\n>> $ git log --format=%cd' %h' 19f5fb7 ^v2.6.34-rc1~200\n>> Sun Jan 24 14:34:07 2010 -0500 19f5fb7\n>> Mon Dec 7 10:36:20 2009 -0500 d2eecb0\n[...]\n> Thanks for confirming, that was the same stretch of history I ended up\n> looking at.\n\nIt seems that the committer date is set to coincide with the author\ndate for ext4 patches, which breaks some assumptions by git that each\ncommit has a later or equal committer date than all parents (modulo\nsome skew).\n\nHow is the ext4 tree generated from your patch queue?\n\nJonathan\n\n[1] http://thread.gmane.org/gmane.comp.version-control.git/145449\n\n>> Is the rule that every commit must be at most one day before each of\n>> its parents?  This should probably be documented somewhere, since it\n>> is possible to override the committer date with GIT_COMMITTER_DATE.\n>\n> There is no hard and fast rule. We have to deal with _some_ clock skew,\n> but I think it has been anybody's guess how much. One can always treat\n> the graph purely topologically (which is what my first patch removing\n> the cutoff_date check did), but that usually means more computation. In\n> this case, we go all the way to the roots instead of looking at a\n> \"recent\" subgraph. I think we also look at timestamps in rev-list when\n> linearizing to avoid doing a full topo-sort, but I don't remember what\n> effects clock skew can have there.\n>\n> So what should we do with this incident?\n>\n>   1. Declare it too much clock skew and ignore it.\n>\n>   2. Drop the cutoff optimization in favor of correctness. We already do\n>      this for --stdin, as there is no sensible cutoff for multiple\n>      inputs. So you can see how much slower it is:\n>\n>        $ time git name-rev a1de02dccf906faba2ee2d99cac56799bda3b96a\n>        a1de02dccf906faba2ee2d99cac56799bda3b96a undefined\n>\n>        real    0m0.163s\n>        user    0m0.140s\n>        sys     0m0.020s\n>\n>        $ time echo a1de02dccf906faba2ee2d99cac56799bda3b96a |\n>          git name-rev --stdin\n>        a1de02dccf906faba2ee2d99cac56799bda3b96a (tags/v2.6.34-rc1~199^2~35)\n>\n>        real    0m3.411s\n>        user    0m3.244s\n>        sys     0m0.164s\n>\n>      So perhaps it is something one would want to enable with a\n>      command-line option. Or even something we could fall back on\n>      automatically as a \"slow case\" when coming up with an un-nameable\n>      rev.\n>\n>   3. Bump the slop date. 60 days would work here. What's reasonable? A\n>      year? At one year, we are still noticeably slower:\n>\n>        # patched for CUTOFF_SLOP_DATE (365*86400)\n>        $ time git name-rev a1de02dccf906faba2ee2d99cac56799bda3b96a\n>        a1de02dccf906faba2ee2d99cac56799bda3b96a\n>        tags/v2.6.34-rc1~199^2~35\n>\n>        real    0m1.075s\n>        user    0m1.028s\n>        sys     0m0.044s\n>\n> -Peff\n"},{"id":"140143","messageId":"alpine.LFD.2.00.1004221119290.26046@i5.linux-foundation.org","threadId":"23554","inReplyTo":"20100422162504.GA4913@progeny.tock","subject":"Re: bug in name-rev on linux-2.6 repo?","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2010-04-22T18:20:34Z","receivedAt":"2010-04-22T18:20:34Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 22 Apr 2010, Jonathan Nieder wrote:\n>\n> Hi Ted, [ nip ]\n> \n> It seems that the committer date is set to coincide with the author\n> date for ext4 patches, which breaks some assumptions by git that each\n> commit has a later or equal committer date than all parents (modulo\n> some skew).\n\nArgh. Yeah, that's just _evil_. Admittedly, git should never care, but in \npractice it does, because doing the whole graph walk can be _very_ \nexpensive. So git wants to think that the committer dates at least have \n_some_ real-life significance.\n\n\t\tLinus\n"},{"id":"140308","messageId":"20100424230415.GA667@thunk.org","threadId":"23554","inReplyTo":"alpine.LFD.2.00.1004221119290.26046@i5.linux-foundation.org","subject":"Re: bug in name-rev on linux-2.6 repo?","fromName":"","fromEmail":"tytso@mit.edu","sentAt":"2010-04-24T23:04:15Z","receivedAt":"2010-04-24T23:04:15Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Thu, Apr 22, 2010 at 11:20:34AM -0700, Linus Torvalds wrote:\n> On Thu, 22 Apr 2010, Jonathan Nieder wrote:\n> >\n> > Hi Ted, [ nip ]\n> > \n> > It seems that the committer date is set to coincide with the author\n> > date for ext4 patches, which breaks some assumptions by git that each\n> > commit has a later or equal committer date than all parents (modulo\n> > some skew).\n> \n> Argh. Yeah, that's just _evil_. Admittedly, git should never care, but in \n> practice it does, because doing the whole graph walk can be _very_ \n> expensive. So git wants to think that the committer dates at least have \n> _some_ real-life significance.\n>\n> > How is the ext4 tree generated from your patch queue?\n\nArgh, sorry, I didn't realize git cared.  I didn't realize it was\ndoing optimizations based on the committer dates.\n\nI'm using guilt to generate the ext4 tree.  The realize why I like\nguilt is that keep the patch queue stored in git, both for revision\nhistory purposes and because it allows other people to see and\npotentially collaborate on the patch queue maintenance.\n\nA long time ago (as in years), I put in a feature request to the guilt\nmaintainer that the author and committer dates should be set from the\nfile modtimes.  This has the property that when I go back and forth\nbetween commits, it doesn't generate excess garbage for git to deal\nwith, since with the author and committer dates the same, if I do a\n\"guilt pop\" followed by a \"guilt push\", the commit id of HEAD stays\nthe same.\n\nSo far, so good, until it happens that I decide I need to rewind the\npatch queue and update a patch description (maybe to add a kernel\nbugzilla entry, or an tested-by, etc.)  Since that touches the\nmodtime, you can end up with crazy date sequences such as this:\n\nSun Jan 24 14:34:07 2010 -0500 19f5fb7\nMon Dec 7 10:36:20 2009 -0500 d2eecb0\nFri Jan 1 01:00:21 2010 -0500 f8ec9d6\nWed Dec 23 07:45:44 2009 -0500 71f2be2\nFri Jan 22 17:40:42 2010 -0500 1f2acb6\nMon Feb 15 20:17:55 2010 -0500 15121c1\nThu Feb 4 23:58:38 2010 -0500 a1de02d\n\nIn any case, I didn't realize this causes problems, so I can add some\nmanual processing to make sure this doesn't happen in the future, and\nI can look into hacking guilt so that enforces the invariant that the\ncommiter time/date must always be increasing.\n\nSorry about causing problems,\n\n\t\t\t\t\t- Ted\n"}]}