{"thread":{"id":"2838","subject":"Tracking files across tree reorganizations","startedAt":"2005-12-14T21:15:59Z","lastAt":"2005-12-15T08:12:14Z","messageCount":13,"participants":["H. Peter Anvin","Petr Baudis","Linus Torvalds","Junio C Hamano","Martin Langhoff"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"13631","messageId":"43A08B8F.1000901@zytor.com","threadId":"2838","inReplyTo":null,"subject":"Tracking files across tree reorganizations","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-12-14T21:15:59Z","receivedAt":"2005-12-14T21:15:59Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Did anything ever happen with that?\n\n\t-hpa\n"},{"id":"13640","messageId":"20051214223656.GJ22159@pasky.or.cz","threadId":"2838","inReplyTo":"43A08B8F.1000901@zytor.com","subject":"Re: Tracking files across tree reorganizations","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-12-14T22:36:56Z","receivedAt":"2005-12-14T22:36:56Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Hah, here we go again. :-)\n\nDear diary, on Wed, Dec 14, 2005 at 10:15:59PM CET, I got a letter\nwhere \"H. Peter Anvin\" said that...\n> Did anything ever happen with that?\n\nLinus is against it.\n\nCogito will do it anyway ;-), when someone sends me a nice patch or when\nI get to it (probably not very soon). I imagine it like this:\n\n(a) User can explicitly note file moves / renames. We follow those notes.\nProbably the most viable for recording the notes is appending them at\nthe tail of the commit message.\n\n(b) If there are no notes for the given commit, we do the rename\nautodetection already implemented in GIT. If it yields something,\nwe follow it.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"13644","messageId":"43A0A6E1.9070903@zytor.com","threadId":"2838","inReplyTo":"20051214223656.GJ22159@pasky.or.cz","subject":"Re: Tracking files across tree reorganizations","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-12-14T23:12:33Z","receivedAt":"2005-12-14T23:12:33Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Petr Baudis wrote:\n> Hah, here we go again. :-)\n> \n> Dear diary, on Wed, Dec 14, 2005 at 10:15:59PM CET, I got a letter\n> where \"H. Peter Anvin\" said that...\n> \n>>Did anything ever happen with that?\n> \n> Linus is against it.\n> \n\nI don't think so. Linus is against the user having to explicitly record \nthe moves, but we can detect the moves at the point of reorganization.\n\n> Cogito will do it anyway ;-), when someone sends me a nice patch or when\n> I get to it (probably not very soon). I imagine it like this:\n> \n> (a) User can explicitly note file moves / renames. We follow those notes.\n> Probably the most viable for recording the notes is appending them at\n> the tail of the commit message.\n> \n> (b) If there are no notes for the given commit, we do the rename\n> autodetection already implemented in GIT. If it yields something,\n> we follow it.\n\nI don't see anything in Linus' posts that says (b) is unacceptable.\n\n\t-hpa\n"},{"id":"13648","messageId":"Pine.LNX.4.64.0512141538440.3292@g5.osdl.org","threadId":"2838","inReplyTo":"20051214223656.GJ22159@pasky.or.cz","subject":"Re: Tracking files across tree reorganizations","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-12-14T23:39:52Z","receivedAt":"2005-12-14T23:39:52Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 14 Dec 2005, Petr Baudis wrote:\n> \n> Linus is against it.\n> \n> Cogito will do it anyway ;-), when someone sends me a nice patch or when\n> I get to it (probably not very soon). I imagine it like this:\n\nI warn people that if cogito starts polluting the commit messages too \nmuch, I'll stop pulling from such trees.\n\n\t\tLinus\n"},{"id":"13649","messageId":"43A0AE6B.3040309@zytor.com","threadId":"2838","inReplyTo":"Pine.LNX.4.64.0512141538440.3292@g5.osdl.org","subject":"Re: Tracking files across tree reorganizations","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-12-14T23:44:43Z","receivedAt":"2005-12-14T23:44:43Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Linus Torvalds wrote:\n> \n> On Wed, 14 Dec 2005, Petr Baudis wrote:\n> \n>>Linus is against it.\n>>\n>>Cogito will do it anyway ;-), when someone sends me a nice patch or when\n>>I get to it (probably not very soon). I imagine it like this:\n> \n> I warn people that if cogito starts polluting the commit messages too \n> much, I'll stop pulling from such trees.\n> \n\nI agree, putting that into the commit messages sounds like a pretty bad \nthing. If anything it should go in the commit header, possibly in the \nform of an object reference (with the object carrying the actual data.)\n\nHOWEVER, I maintain that this is unnecessary (and, as Linus has pointed \nout several time, losing) -- we already detect renames without relying \non commit-time metadata. If it's too expensive to generate the metadata \non every merge, it can be cached.\n\n\t-hpa\n"},{"id":"13650","messageId":"20051214234504.GL22159@pasky.or.cz","threadId":"2838","inReplyTo":"43A0A6E1.9070903@zytor.com","subject":"Re: Tracking files across tree reorganizations","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-12-14T23:45:04Z","receivedAt":"2005-12-14T23:45:04Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Thu, Dec 15, 2005 at 12:12:33AM CET, I got a letter\nwhere \"H. Peter Anvin\" said that...\n> Petr Baudis wrote:\n> >Hah, here we go again. :-)\n> >\n> >Dear diary, on Wed, Dec 14, 2005 at 10:15:59PM CET, I got a letter\n> >where \"H. Peter Anvin\" said that...\n> >\n> >>Did anything ever happen with that?\n> >\n> >Linus is against it.\n> >\n> \n> I don't think so. Linus is against the user having to explicitly record \n> the moves, but we can detect the moves at the point of reorganization.\n\nLinus' :\n\n - you're doing the work at the wrong point for _another_ reason. You're\n freezing your (crappy) algorithm at tree creation time, and basically\n making it pointless to ever create something better later, because\n even if hardware and software improves, you've codified that \"we have\n to have crappy information\".\n\n I tend to agree with this now - although I disagree about his\nperformance point in the mail; but we can cache the autodetection\nresults out of commit objects to improve the performance, if it's\nworth it (and I suspect it actually isn't, if you don't care about\nthe \"A renamed to B and new A introduced, both in the same commit\"\ncase).\n\n Note that the intent of the explicit rename recording is to really\nrecord file reorganizations, not code refactoring. When you just\nreorganize your tree, Linus' \"meaningless special case\" becomes very\nmeaningful, because at such point all the code inside the file travels.\nBut if you just move big chunks of code around and rename files based on\nprevailing code origin or something (that's a weird thing to do but I've\nseen people do it), then that's probably where the file as a whole\nshouldn't be marked renamed.\n\n To encourage this practice, I might check the similarities of the\nrenamed files at the time of recording them, and print a big fat warning\nto the user if it's less than say 90% or so. But I think that the huge\nmajority of cases where people want to rename is when they reorganize\ntheir trees and move files as a whole, and that's why it's so useful\nto support explicit renames recording.\n\n> >Cogito will do it anyway ;-), when someone sends me a nice patch or when\n> >I get to it (probably not very soon). I imagine it like this:\n> >\n> >(a) User can explicitly note file moves / renames. We follow those notes.\n> >Probably the most viable for recording the notes is appending them at\n> >the tail of the commit message.\n> >\n> >(b) If there are no notes for the given commit, we do the rename\n> >autodetection already implemented in GIT. If it yields something,\n> >we follow it.\n> \n> I don't see anything in Linus' posts that says (b) is unacceptable.\n\n If we do it at the walk time, not commit time - I didn't emphasize\nthat in my previous mail while I should have.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"13651","messageId":"43A0AF29.6020009@zytor.com","threadId":"2838","inReplyTo":"20051214234504.GL22159@pasky.or.cz","subject":"Re: Tracking files across tree reorganizations","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-12-14T23:47:53Z","receivedAt":"2005-12-14T23:47:53Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Petr Baudis wrote:\n>>>\n>>>(b) If there are no notes for the given commit, we do the rename\n>>>autodetection already implemented in GIT. If it yields something,\n>>>we follow it.\n>>\n>>I don't see anything in Linus' posts that says (b) is unacceptable.\n> \n> If we do it at the walk time, not commit time - I didn't emphasize\n> that in my previous mail while I should have.\n\nExactly. This is the right thing to do, because it means that just \nbecause you made the checkin with version foo, you're forever limited to \nthe capabilities of version foo.\n\n\t-hpa\n"},{"id":"13654","messageId":"7vd5jzurfi.fsf@assigned-by-dhcp.cox.net","threadId":"2838","inReplyTo":"43A0AE6B.3040309@zytor.com","subject":"Re: Tracking files across tree reorganizations","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-12-15T00:36:49Z","receivedAt":"2005-12-15T00:36:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"H. Peter Anvin\" writes:\n\n> HOWEVER, I maintain that this is unnecessary (and, as Linus has pointed \n> out several time, losing) -- we already detect renames without relying \n> on commit-time metadata. If it's too expensive to generate the metadata \n> on every merge, it can be cached.\n\nI agree; I was wondering why you brought it up again.\n"},{"id":"13656","messageId":"43A0C095.20708@zytor.com","threadId":"2838","inReplyTo":"7vd5jzurfi.fsf@assigned-by-dhcp.cox.net","subject":"Re: Tracking files across tree reorganizations","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-12-15T01:02:13Z","receivedAt":"2005-12-15T01:02:13Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Junio C Hamano wrote:\n> \"H. Peter Anvin\" writes:\n> \n> \n>>HOWEVER, I maintain that this is unnecessary (and, as Linus has pointed \n>>out several time, losing) -- we already detect renames without relying \n>>on commit-time metadata. If it's too expensive to generate the metadata \n>>on every merge, it can be cached.\n> \n> \n> I agree; I was wondering why you brought it up again.\n> \n\nJust because of Petr's comment about adding stuff to commit messages.\n\n\t-hpa\n"},{"id":"13660","messageId":"20051215014453.GN22159@pasky.or.cz","threadId":"2838","inReplyTo":"43A0AE6B.3040309@zytor.com","subject":"Re: Tracking files across tree reorganizations","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-12-15T01:44:53Z","receivedAt":"2005-12-15T01:44:53Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Thu, Dec 15, 2005 at 12:44:43AM CET, I got a letter\nwhere \"H. Peter Anvin\" said that...\n> HOWEVER, I maintain that this is unnecessary (and, as Linus has pointed \n> out several time, losing) -- we already detect renames without relying \n> on commit-time metadata. If it's too expensive to generate the metadata \n> on every merge, it can be cached.\n\nJust for the record, I'm not convinced at all (there's probably no\npoint in elaborating the reasons again). I give up, though - I don't\nknow how to store the explicit rename information \"invisibly\" so that\nLinus would be willing to merge commits containing it, and that would\nmake the whole thing pretty much pointless at least for the kernel.\n\nI plan to revive some old patches changing large portions of cg-log\nin the next few days, consequently making it trivial to add the\non-the-fly automatic renames detection to per-file cg-log.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"13668","messageId":"46a038f90512142138x77e57850ib095c1d68ecdfd13@mail.gmail.com","threadId":"2838","inReplyTo":"43A08B8F.1000901@zytor.com","subject":"Re: Tracking files across tree reorganizations","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2005-12-15T05:38:02Z","receivedAt":"2005-12-15T05:38:02Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 12/15/05, H. Peter Anvin wrote:\n> Did anything ever happen with that?\n\nPerhaps I'm slow today, but git-merge -s recursive was supposed to do\nit transparently (automagically). At least it was merged into git with\nthat excuse ;-)\n\nDoes it not work for you or am I missing something?\n\n\nmartin\n"},{"id":"13669","messageId":"46a038f90512142140s31fe4a6ay706efb8b1d4c833b@mail.gmail.com","threadId":"2838","inReplyTo":"20051215014453.GN22159@pasky.or.cz","subject":"Re: Tracking files across tree reorganizations","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2005-12-15T05:40:28Z","receivedAt":"2005-12-15T05:40:28Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 12/15/05, Petr Baudis wrote:\n> in the next few days, consequently making it trivial to add the\n> on-the-fly automatic renames detection to per-file cg-log.\n\nDoes it matter? Who makes a big file reorg and doesn't put \"big tree\nreorganization\" in the commit message, and can we shoot him?\n\ncheers,\n\nmartin\n"},{"id":"13675","messageId":"43A1255E.50400@zytor.com","threadId":"2838","inReplyTo":"46a038f90512142138x77e57850ib095c1d68ecdfd13@mail.gmail.com","subject":"Re: Tracking files across tree reorganizations","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-12-15T08:12:14Z","receivedAt":"2005-12-15T08:12:14Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Martin Langhoff wrote:\n> On 12/15/05, H. Peter Anvin wrote:\n> \n>>Did anything ever happen with that?\n> \n> Perhaps I'm slow today, but git-merge -s recursive was supposed to do\n> it transparently (automagically). At least it was merged into git with\n> that excuse ;-)\n> \n> Does it not work for you or am I missing something?\n> \n\nI'll try it.\n\n\t-hpa\n"}]}