{"thread":{"id":"12503","subject":"tracking renames","startedAt":"2008-03-04T21:57:34Z","lastAt":"2008-03-07T08:19:45Z","messageCount":9,"participants":["Andrew Morton","Harvey Harrison","Jakub Narebski","Jean-François Veillette","Johannes Schindelin","Martin Langhoff","Steven Grimm"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"71000","messageId":"20080304135734.b2c2f473.akpm@linux-foundation.org","threadId":"12503","inReplyTo":null,"subject":"tracking renames","fromName":"Andrew Morton","fromEmail":"akpm@linux-foundation.org","sentAt":"2008-03-04T21:57:34Z","receivedAt":"2008-03-04T21:57:34Z","isPatch":false,"sender":{"key":"akpm@linux-foundation.org","avatar":null},"body":"\nWhen I do\n\n\tgit-whatchanged drivers/watchdog/iTCO_wdt.c\n\nit ends at \"mv watchdog tree under drivers\". I'd have expected it to\ntell me things about that file when it was in its original home at\ndrivers/char/watchdog/iTCO_wdt.c\n"},{"id":"71001","messageId":"590657100803041403q2cc68e21p1c92c244939eb148@mail.gmail.com","threadId":"12503","inReplyTo":"20080304135734.b2c2f473.akpm@linux-foundation.org","subject":"Re: tracking renames","fromName":"Harvey Harrison","fromEmail":"harvey.harrison@gmail.com","sentAt":"2008-03-04T22:03:54Z","receivedAt":"2008-03-04T22:03:54Z","isPatch":false,"sender":{"key":"harvey.harrison@gmail.com","avatar":null},"body":"On Tue, Mar 4, 2008 at 1:57 PM, Andrew Morton wrote:\n>\n> When I do\n>\n> git-whatchanged drivers/watchdog/iTCO_wdt.c\n>\n\ngit-whatchanged --follow drivers/watchdog/iTCO_wdt.c\n\nCheers,\n\nHarvey\n"},{"id":"71003","messageId":"20080304141029.52b12065.akpm@linux-foundation.org","threadId":"12503","inReplyTo":"590657100803041403q2cc68e21p1c92c244939eb148@mail.gmail.com","subject":"Re: tracking renames","fromName":"Andrew Morton","fromEmail":"akpm@linux-foundation.org","sentAt":"2008-03-04T22:10:29Z","receivedAt":"2008-03-04T22:10:29Z","isPatch":false,"sender":{"key":"akpm@linux-foundation.org","avatar":null},"body":"On Tue, 4 Mar 2008 14:03:54 -0800\n\"Harvey Harrison\" wrote:\n\n> On Tue, Mar 4, 2008 at 1:57 PM, Andrew Morton wrote:\n> >\n> > When I do\n> >\n> > git-whatchanged drivers/watchdog/iTCO_wdt.c\n> >\n> \n> git-whatchanged --follow drivers/watchdog/iTCO_wdt.c\n> \n\nOh. Thanks. It seems dumb that one needs to add an option to get it to do this.\n"},{"id":"71005","messageId":"m3zltegmj0.fsf@localhost.localdomain","threadId":"12503","inReplyTo":"20080304141029.52b12065.akpm@linux-foundation.org","subject":"Re: tracking renames","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-03-04T22:19:16Z","receivedAt":"2008-03-04T22:19:16Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Andrew Morton writes:\n\n> On Tue, 4 Mar 2008 14:03:54 -0800\n> \"Harvey Harrison\" wrote:\n>> \n>> git-whatchanged --follow drivers/watchdog/iTCO_wdt.c\n>> \n> \n> Oh. Thanks. It seems dumb that one needs to add an option to get\n> it to do this.\n\nIn \"git log ...\" or \"git whatchanged ...\" the \noption is \"path limiter\" and can be a directory. There can be more\nthan one path. And following renames is more costly.\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"71086","messageId":"965172C8-C7A4-4932-899B-1E1A77BD7C12@yahoo.ca","threadId":"12503","inReplyTo":"m3zltegmj0.fsf@localhost.localdomain","subject":"Re: tracking renames","fromName":"Jean-François Veillette","fromEmail":"jean_francois_veillette@yahoo.ca","sentAt":"2008-03-05T15:39:47Z","receivedAt":"2008-03-05T15:39:47Z","isPatch":false,"sender":{"key":"jean_francois_veillette@yahoo.ca","avatar":null},"body":"Le 08-03-04 à 17:19, Jakub Narebski a écrit :\n\n> Andrew Morton writes:\n>\n>> On Tue, 4 Mar 2008 14:03:54 -0800\n>> \"Harvey Harrison\" wrote:\n>>>\n>>> git-whatchanged --follow drivers/watchdog/iTCO_wdt.c\n>>>\n>>\n>> Oh. Thanks. It seems dumb that one needs to add an option to get\n>> it to do this.\n>\n> In \"git log ...\" or \"git whatchanged ...\" the \n> option is \"path limiter\" and can be a directory. There can be more\n> than one path. And following renames is more costly.\n\nAm I the only one who think rename could be explicit ?\nDon't take me wrong, I do appreciate the fact that git recognize \nrenames after-the-fact, when specifically asked for it.\nBut as a developer, at some point, a rename is no longer a point-of- \nview discovery, a rename is a rename by 'design', by the nature \nitself of the change, it's no longer an after-the fact realisation.\nIt seem to me that no mather how smart we try to discover renames, \nthere will always be cases where algorithm won't discover due to time/ \nspace/other constraints.\nI would like something like 'graft' where after the fact, we can \neducate git that there is a connection between 2 commits. In a \nsimilar way, at some point, I would like to tell git, 'ok stop trying \nto figure out which changes are renames, you guessed it right for the \nlast 10 times, just freeze it ... but let me adjust it if you guessed \nit wrong'.\n\nThis is a comment from a git user, I've not looked at the code at \nall (and probably won't do anytime soon).\n\n- jfv\n\n\n"},{"id":"71095","messageId":"200803051715.58375.jnareb@gmail.com","threadId":"12503","inReplyTo":"965172C8-C7A4-4932-899B-1E1A77BD7C12@yahoo.ca","subject":"Re: tracking renames","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-03-05T16:15:56Z","receivedAt":"2008-03-05T16:15:56Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Wed, 5 Mar 2008, Jean-François Veillette wrote:\n> Le 08-03-04 à 17:19, Jakub Narebski a écrit :\n>> Andrew Morton writes:\n>>>\n>>> On Tue, 4 Mar 2008 14:03:54 -0800\n>>> \"Harvey Harrison\" wrote:\n>>>>\n>>>> git-whatchanged --follow drivers/watchdog/iTCO_wdt.c\n>>>>\n>>>\n>>> Oh. Thanks. It seems dumb that one needs to add an option to get\n>>> it to do this.\n>>\n>> In \"git log ...\" or \"git whatchanged ...\" the \n>> option is \"path limiter\" and can be a directory. There can be more\n>> than one path. And following renames is more costly.\n> \n> Am I the only one who think rename could be explicit?\n\nNo, you are not the only one. Use Bazaar-NG (bzr) or Mercurial (hg)\nif you think you truly need rename _tracking_ as opposed to rename\n_detection_.\n\n> Don't take me wrong, I do appreciate the fact that git recognize \n> renames after-the-fact, when specifically asked for it.\n> But as a developer, at some point, a rename is no longer a point-of- \n> view discovery, a rename is a rename by 'design', by the nature \n> itself of the change, it's no longer an after-the fact realisation.\n\nThere is a point why git does rename detection and not (usually \nfile-id / file-inode based) rename tracking, besides historical\nreasons. This discussion crops now and there; you can search mailing\nlist archives (and perhaps look up GitFaq at GitWiki).\n\n> It seem to me that no mather how smart we try to discover renames, \n> there will always be cases where algorithm won't discover due to time/ \n> space/other constraints.\n\nThen we will improve rename (and copy) detection heuristics.\n\n> I would like something like 'graft' where after the fact, we can \n> educate git that there is a connection between 2 commits. In a \n> similar way, at some point, I would like to tell git, 'ok stop trying \n> to figure out which changes are renames, you guessed it right for the \n> last 10 times, just freeze it ... but let me adjust it if you guessed \n> it wrong'.\n\nThere was idea of _local_ second level of rerere (reuse resolved \nresolution of conficting merges), more persistant, which would remember \ntree merge conflicts (rename detection and other such conflicts).\nBut as far as I know it never got implemented.\n \nIMVHO it is only sensible solution, see below.\n\n> This is a comment from a git user, I've not looked at the code at \n> all (and probably won't do anytime soon).\n\nFirst, I think it could be good idea to store helper advisiory \ninformation about explicitely stated renames, or tree merge resolutions \nas a [proposed] 'note' header in commit object, to be remembered when \ntraversing graph of commits to find common ancestor(s) and later reuse \nin rename detection. But this never got past the wishful thinking...\n\n\nExplicit rename tracking has many caveats. \n\nIf you remember it with commit info, you would loose at least somewhat \nnice assertion that only endpoints (which includes merge bases) matters \nwhen doing merge, not the path taken. IIRC it is what Mercurial does.\n\nIf you use some kind of automatic assigned file-ids (file-inodes) you \ncan have problems with independently added (on different branches) \nfiles. Linus also suggests that if you have file-id conflict, you \nwould have to resolve it again, and again, and again. IIRC it is what \nBazaar-NG (following original Arch idea) does.\n\nAnd of course with rename (and copy) tracking you _have_ to explicitely\nstate renames, which is a bit out of question if some of your commits \ncomes as a patches in email, or from foreign SCM. Or if you forget to \nexplicitely state rename.\n\n\nBesides wholefile rename tracking is only small fragment of dealing with \ncode movement, something what \"git gui blame\" (\"git blame -C -C\") is \ngood at...\n\n-- \nJakub Narebski\nPoland\n"},{"id":"71097","messageId":"alpine.LSU.1.00.0803051738370.15786@racer.site","threadId":"12503","inReplyTo":"965172C8-C7A4-4932-899B-1E1A77BD7C12@yahoo.ca","subject":"Re: tracking renames","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-03-05T16:39:34Z","receivedAt":"2008-03-05T16:39:34Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 5 Mar 2008, Jean-François Veillette wrote:\n\n> Am I the only one who think rename could be explicit ?\n\nThis is one of the most FAQ. Please see\n\n\thttp://git.or.cz/gitwiki/GitFaq\n\nHth,\nDscho"},{"id":"71119","messageId":"46a038f90803051254i3a722e06h397a1a2d8a6c75da@mail.gmail.com","threadId":"12503","inReplyTo":"alpine.LSU.1.00.0803051738370.15786@racer.site","subject":"Re: tracking renames","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2008-03-05T20:54:22Z","receivedAt":"2008-03-05T20:54:22Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On Thu, Mar 6, 2008 at 5:39 AM, Johannes Schindelin\n wrote:\n> This is one of the most FAQ. Please see\n>\n> http://git.or.cz/gitwiki/GitFaq\n>\n\nAnd don't miss the entertaining and colourful email by Linus on the\nsubject here http://permalink.gmane.org/gmane.comp.version-control.git/217\n\n... this has also been a recurring flamefest in the past. So if anyone\nis feeling argumentative, have a good read of the thousands of flaming\nposts on the matter :-)\n\ncheers,\n\n\nm\n"},{"id":"71323","messageId":"526E4B08-9F52-461E-B542-4549987C4DFE@midwinter.com","threadId":"12503","inReplyTo":"200803051715.58375.jnareb@gmail.com","subject":"Re: tracking renames","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2008-03-07T08:19:45Z","receivedAt":"2008-03-07T08:19:45Z","isPatch":false,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"On Mar 5, 2008, at 8:15 AM, Jakub Narebski wrote:\n> No, you are not the only one. Use Bazaar-NG (bzr) or Mercurial (hg)\n> if you think you truly need rename _tracking_ as opposed to rename\n> _detection_.\n\nHaving watched (and participated in) this discussion several times as \nit's come up on the list, the one thing I don't understand is why \npeople -- not you, but others -- think this has to be an \"as opposed \nto\" issue. I have yet to see anyone propose that git should lose its \nrename detection, but the counterarguments and explanations about how \ninferior rename tracking is often seem to presuppose that that's \nwhat's being asked for.\n\nI think the setup the pro-rename-tracking crowd mostly wants is, \"git \nalways treats explicitly specified renames as renames and uses its \ncurrent detection regime if there is no explicit specification.\" As \nyou say later on in the parent message, a wish-list item that hasn't \nbecome reality yet.\n\nI am not saying I think it's too important, BTW; I'm just trying to \nclarify the other point of view. Personally, my only major wish item \nfor git's rename support is better handling of directory renames, but \nI don't really care how git knows that the directory in question has \nbeen renamed. The file rename support has worked very well for me in \npractice.\n\n-Steve\n"}]}