{"thread":{"id":"15365","subject":"Directory renames without breaking git log.","startedAt":"2008-09-03T21:38:28Z","lastAt":"2008-09-04T22:06:27Z","messageCount":8,"participants":["Kai Blin","Tarmigan","Junio C Hamano","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"89693","messageId":"200809032338.35359.kai@samba.org","threadId":"15365","inReplyTo":null,"subject":"Directory renames without breaking git log.","fromName":"Kai Blin","fromEmail":"kai@samba.org","sentAt":"2008-09-03T21:38:28Z","receivedAt":"2008-09-03T21:38:28Z","isPatch":false,"sender":{"key":"kai@samba.org","avatar":"https://gravatar.com/avatar/bc7698f10d926406cee9c7bad46d2b345249777dadd9ece4501f6f2384a03e52?d=mp&s=160"},"body":"Hi folks,\n\nin an effort to make Samba development easier, we're trying to merge the \nSamba3 and Samba4 branches into a single branch. In order to do so, we need \nto rename the \"source\" directories both Samba 3 and Samba 4 have (we're \nplanning to use source3 and source4).\n\nUnfortunately, the directories are big enough that git log stops to track the \nrenamed files, so e.g. git log ./samba3 does not show the samba3 history. The \nhistory is not lost, of course, but it's way less intuitive to get it.\n\nHere's how we merged the two branches:\n\n$ mkdir samba-merged\n$ cd samba-merged\n$ git init\n... (create COPYING, README and other top-level files, git add them)\n$ git commit -m \"Initial commit of merged samba\"\n$ git remote add git://git.samba.org/samba.git samba\n$ git remote update\n$ cp -a ~/samba3/source source3\n$ cp -a ~/samba4/source source4\n$ git add source3 source4\n$ git write-tree\n$ echo \"merge branches\" | git commit-tree <sha1 git write-tree retured> \\\n      -p <sha1 of the initial commit> \\\n      -p <sha1 of the current samba3 head> \\\n      -p <sha1 of the current samba4 head>\n$ git reset --hard <sha1 returned by git commit-tree>\n$ git log\n... history is there as expected\n$ git log samba3\n... history is just the merge commit\n$ git log samba4\n... history is just the merge commit\n\nIs there any way to fix this that doesn't involve changing the history with \ngit-filter-branch?\n\nCheers,\nKai\n\n-- \nKai Blin\nWorldForge developer  http://www.worldforge.org/\nWine developer        http://wiki.winehq.org/KaiBlin\nSamba team member     http://www.samba.org/samba/team/\n--\nWill code for cotton.\n"},{"id":"89706","messageId":"905315640809031716j7d74d7a6m51b434f62b011135@mail.gmail.com","threadId":"15365","inReplyTo":"200809032338.35359.kai@samba.org","subject":"Re: Directory renames without breaking git log.","fromName":"Tarmigan","fromEmail":"tarmigan+git@gmail.com","sentAt":"2008-09-04T00:16:24Z","receivedAt":"2008-09-04T00:16:24Z","isPatch":false,"sender":{"key":"tarmigan+git@gmail.com","avatar":null},"body":"On Wed, Sep 3, 2008 at 2:38 PM, Kai Blin <kai@samba.org> wrote:\n> Hi folks,\n>\n> in an effort to make Samba development easier, we're trying to merge the\n> Samba3 and Samba4 branches into a single branch. In order to do so, we need\n> to rename the \"source\" directories both Samba 3 and Samba 4 have (we're\n> planning to use source3 and source4).\n>\n> Unfortunately, the directories are big enough that git log stops to track the\n> renamed files, so e.g. git log ./samba3 does not show the samba3 history. The\n> history is not lost, of course, but it's way less intuitive to get it.\n\nYou can try setting diff.renamelimit to 0 in your ~/.gitconfig.  See\nLinus's email here for a similar situation in the kernel:\nhttp://lwn.net/Articles/292948/\n\nThanks,\nTarmigan\n"},{"id":"89776","messageId":"905315640809041135m4026cf90h7f506bb3d295b09a@mail.gmail.com","threadId":"15365","inReplyTo":"200809040853.36433.kai@samba.org","subject":"Re: Directory renames without breaking git log.","fromName":"Tarmigan","fromEmail":"tarmigan+git@gmail.com","sentAt":"2008-09-04T18:35:45Z","receivedAt":"2008-09-04T18:35:45Z","isPatch":false,"sender":{"key":"tarmigan+git@gmail.com","avatar":null},"body":"(you're probably better off asking on the whole list, as I don't know much)\n\nOn Wed, Sep 3, 2008 at 11:53 PM, Kai Blin <kai@samba.org> wrote:\n> On Thursday 04 September 2008 02:16:24 you wrote:\n>> On Wed, Sep 3, 2008 at 2:38 PM, Kai Blin <kai@samba.org> wrote:\n>> > Unfortunately, the directories are big enough that git log stops to track\n>> > the renamed files, so e.g. git log ./samba3 does not show the samba3\n>> > history. The history is not lost, of course, but it's way less intuitive\n>> > to get it.\n>>\n>> You can try setting diff.renamelimit to 0 in your ~/.gitconfig.  See\n>> Linus's email here for a similar situation in the kernel:\n>> http://lwn.net/Articles/292948/\n>\n> That doesn't seem to fix \"git log path/to/file\" cases. The really interesting\n> part is that if I try git log --follow -M -C path/to/file, I don't get any\n> history at all. (--follow is the culprit, if I remove that I at least get the\n> merge commit)\n\nOK, I actually tried with your example, and see what you mean.  It\nlooks like follow does not work with this case.  See\nhttp://permalink.gmane.org/gmane.comp.version-control.git/85766\nfor an illustration of --follow not working with the subtree merge\nstrategy, which as far as I can tell is pretty much the same as this\ncase.  Also it sounds like follow only works with single files, and\nnot directories:\nhttp://kerneltrap.org/mailarchive/git/2008/5/4/1714694\n\nWhy these do not work is way beyond my git knowledge.  As far as I\nknow (which is very little), follow could work for these cases, but it\ncurrently does not.\n\n> git blame still works, and git log --sparse path/to/file works, of\n> course. --sparse makes giving a path a bit pointless, of course, but we\n> probably can live with that for time being. I'm still open for suggestions,\n> of course. :)\n\nGlad that git blame works.  If you haven't already, you should also\ntry git gui blame too for better interactivity.\n\nThanks,\nTarmigan\n"},{"id":"89786","messageId":"200809042145.09573.kai@samba.org","threadId":"15365","inReplyTo":"905315640809031716j7d74d7a6m51b434f62b011135@mail.gmail.com","subject":"Re: Directory renames without breaking git log.","fromName":"Kai Blin","fromEmail":"kai@samba.org","sentAt":"2008-09-04T19:45:09Z","receivedAt":"2008-09-04T19:45:09Z","isPatch":false,"sender":{"key":"kai@samba.org","avatar":"https://gravatar.com/avatar/bc7698f10d926406cee9c7bad46d2b345249777dadd9ece4501f6f2384a03e52?d=mp&s=160"},"body":"On Thursday 04 September 2008 02:16:24 Tarmigan wrote:\n> On Wed, Sep 3, 2008 at 2:38 PM, Kai Blin <kai@samba.org> wrote:\n> > Unfortunately, the directories are big enough that git log stops to track\n> > the renamed files, so e.g. git log ./samba3 does not show the samba3\n> > history. The history is not lost, of course, but it's way less intuitive\n> > to get it.\n>\n> You can try setting diff.renamelimit to 0 in your ~/.gitconfig.  See\n> Linus's email here for a similar situation in the kernel:\n> http://lwn.net/Articles/292948/\n\nThat doesn't seem to fix \"git log path/to/file\" cases. The really interesting \npart is that if I try git log --follow -M -C path/to/file, I don't get any \nhistory at all. (--follow is the culprit, if I remove that I at least get the \nmerge commit)\n\ngit blame still works, and git log --sparse path/to/file works, of \ncourse. --sparse makes giving a path a bit pointless, of course, but we \nprobably can live with that for time being. I'm still open for suggestions, \nof course. :)\n\nCheers,\nKai\n\n-- \nKai Blin\nWorldForge developer  http://www.worldforge.org/\nWine developer        http://wiki.winehq.org/KaiBlin\nSamba team member     http://www.samba.org/samba/team/\n--\nWill code for cotton.\n"},{"id":"89787","messageId":"7vtzcv1yk8.fsf@gitster.siamese.dyndns.org","threadId":"15365","inReplyTo":"200809042145.09573.kai@samba.org","subject":"Re: Directory renames without breaking git log.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-09-04T19:49:27Z","receivedAt":"2008-09-04T19:49:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Kai Blin <kai@samba.org> writes:\n\n> On Thursday 04 September 2008 02:16:24 Tarmigan wrote:\n>> On Wed, Sep 3, 2008 at 2:38 PM, Kai Blin <kai@samba.org> wrote:\n>> > Unfortunately, the directories are big enough that git log stops to track\n>> > the renamed files, so e.g. git log ./samba3 does not show the samba3\n>> > history. The history is not lost, of course, but it's way less intuitive\n>> > to get it.\n>>\n>> You can try setting diff.renamelimit to 0 in your ~/.gitconfig.  See\n>> Linus's email here for a similar situation in the kernel:\n>> http://lwn.net/Articles/292948/\n>\n> That doesn't seem to fix \"git log path/to/file\" cases. The really interesting \n> part is that if I try git log --follow -M -C path/to/file, I don't get any \n> history at all. (--follow is the culprit, if I remove that I at least get the \n> merge commit)\n>\n> git blame still works, and git log --sparse path/to/file works, of \n> course. --sparse makes giving a path a bit pointless, of course, but we \n> probably can live with that for time being. I'm still open for suggestions, \n> of course. :)\n\nGive both directories, like:\n\n\t\"git log -- newdir olddir\"\n\nperhaps?\n"},{"id":"89788","messageId":"m3ljy7prtj.fsf@localhost.localdomain","threadId":"15365","inReplyTo":"200809042145.09573.kai@samba.org","subject":"Re: Directory renames without breaking git log.","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-09-04T20:41:13Z","receivedAt":"2008-09-04T20:41:13Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Kai Blin <kai@samba.org> writes:\n\n> On Thursday 04 September 2008 02:16:24 Tarmigan wrote:\n> > On Wed, Sep 3, 2008 at 2:38 PM, Kai Blin <kai@samba.org> wrote:\n> > > Unfortunately, the directories are big enough that git log stops to track\n> > > the renamed files, so e.g. git log ./samba3 does not show the samba3\n> > > history. The history is not lost, of course, but it's way less intuitive\n> > > to get it.\n> >\n> > You can try setting diff.renamelimit to 0 in your ~/.gitconfig.  See\n> > Linus's email here for a similar situation in the kernel:\n> > http://lwn.net/Articles/292948/\n> \n> That doesn't seem to fix \"git log path/to/file\" cases. The really\n> interesting part is that if I try \"git log --follow -M -C\n> path/to/file\", I don't get any history at all. (--follow is the\n> culprit, if I remove that I at least get the merge commit)\n> \n> git blame still works, and git log --sparse path/to/file works, of \n> course. --sparse makes giving a path a bit pointless, of course, but we \n> probably can live with that for time being. I'm still open for suggestions, \n> of course. :)\n\nUnfortunately \"git log --follow <filename>\" works correctly only\non relative simple histories.  You are of course welcome to improve\nthis part of git.\n\nSimple workaround is to use \"git log <file>\" (optionally using\n--diff-filter) to get when file vanished, check using \"git show\" or\n\"git whatchanged\" on boundary commit, then use \n\"git log -C -C -- <old name> <new name>\"\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"89789","messageId":"200809042252.37329.kai@samba.org","threadId":"15365","inReplyTo":"7vtzcv1yk8.fsf@gitster.siamese.dyndns.org","subject":"Re: Directory renames without breaking git log.","fromName":"Kai Blin","fromEmail":"kai@samba.org","sentAt":"2008-09-04T20:52:34Z","receivedAt":"2008-09-04T20:52:34Z","isPatch":false,"sender":{"key":"kai@samba.org","avatar":"https://gravatar.com/avatar/bc7698f10d926406cee9c7bad46d2b345249777dadd9ece4501f6f2384a03e52?d=mp&s=160"},"body":"On Thursday 04 September 2008 21:49:27 Junio C Hamano wrote:\n\n> > git blame still works, and git log --sparse path/to/file works, of\n> > course. --sparse makes giving a path a bit pointless, of course, but we\n> > probably can live with that for time being. I'm still open for\n> > suggestions, of course. :)\n>\n> Give both directories, like:\n>\n> \t\"git log -- newdir olddir\"\n>\n> perhaps?\n\nBetter, but really ugly, as we'll have to keep doing this for the rest of the \nproject's life to get the full history. And while it's all nice and fun for \ngit log -- source3/configure.in source/configure.in, it's less fun for deeper \npaths.\n\nWe'll probably end up just doing a git-filter-branch renaming the samba3 \nsource dir source3 from the beginning and the samba4 source dir source4 from \nthe beginning, and then do the octopus merge. Without any paths changing, \nthat should probably work. It's a bit annoying to break all external \nbranches, but we only need to do this once, and people will only need to \ngit-format-patch and git-am once, and we can provide a step-by-step guide for \nthis as well.\n\nThanks for the feedback, though. :)\n\nCheers,\nKai\n\n-- \nKai Blin\nWorldForge developer  http://www.worldforge.org/\nWine developer        http://wiki.winehq.org/KaiBlin\nSamba team member     http://www.samba.org/samba/team/\n--\nWill code for cotton.\n"},{"id":"89796","messageId":"7vfxof1s7w.fsf@gitster.siamese.dyndns.org","threadId":"15365","inReplyTo":"200809042252.37329.kai@samba.org","subject":"Re: Directory renames without breaking git log.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-09-04T22:06:27Z","receivedAt":"2008-09-04T22:06:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Kai Blin <kai@samba.org> writes:\n\n> On Thursday 04 September 2008 21:49:27 Junio C Hamano wrote:\n>\n>> > git blame still works, and git log --sparse path/to/file works, of\n>> > course. --sparse makes giving a path a bit pointless, of course, but we\n>> > probably can live with that for time being. I'm still open for\n>> > suggestions, of course. :)\n>>\n>> Give both directories, like:\n>>\n>> \t\"git log -- newdir olddir\"\n>>\n>> perhaps?\n>\n> Better, but really ugly, as we'll have to keep doing this for the rest\n> of the project's life to get the full history. And while it's all nice\n> and fun for git log -- source3/configure.in source/configure.in, it's\n> less fun for deeper paths.\n\nYes, following across subtree merges _could_ be improved.\n\nBut another thing I should mention in this context is that you should not\ntake --follow option (at least in the current form) too seriously.\n\nI see it's been a while --- the last time I did this was October 2006 if I\nam not mistaken.  It's time of the year I should point at one of the most\nimportant articles ever written on this mailing list:\n\n    http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217\n\nAfter understanding what Linus envisioned back then, why what he said are\nimportant are important and why what he dismissed as uninteresting are\nindeed uninteresting, things to think about now are:\n\n - \"blame\" (especially with -C -C), as you found out already, does answer\n   the more important question \"where did this come from\"; and\n\n - the question \"log --follow $this_file\" is asking is exactly \"where did\n   this file come from\".  Remember what adjective was used for the\n   question in the article?\n\nI also should mention that --follow was done by Linus as a hack with\nknown limitations.\n\nPotential improvements to follow possible renames fully would involve:\n\n * allow not just a single path but a set of pathspecs to be recorded\n   during --follow traversal;\n\n * allow the above information be associated with individual commits, not\n   as a single global state in the traversal machinery;\n\n * enhance the logic to update the pathspecs information kept above when\n   you hit renames while traversing the history.  An important part of\n   this job involves inferring a wholesale rename of a directory by\n   looking at many files moved from one place to another, which we\n   currently do not do anywhere in git.\n\nIf you do all of the above, it will become a feature, not a hack with\nknown limitation.  But I do not think anybody so far thought it is worth\nthe effort, only to answer the \"where did this file come from\" (ituot ue\nzaf m eqzeunxq cgqefuaz).\n\nPersonally I feel that this is slightly closer to \"I might do this myself\nif I had infinite amount of time and I am really bored\" than \"I don't\ncare; patches welcome\" category.\n"}]}