{"thread":{"id":"39368","subject":"git log --follow for directories","startedAt":"2015-05-19T13:56:48Z","lastAt":"2015-05-20T09:20:58Z","messageCount":4,"participants":["Laszlo Papp","Junio C Hamano","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"261551","messageId":"CAOMwXhP-BRd356xpfdLgZ0zKYTMVryt8jtmi3T2jhVh91hY04Q@mail.gmail.com","threadId":"39368","inReplyTo":null,"subject":"git log --follow for directories","fromName":"Laszlo Papp","fromEmail":"lpapp@kde.org","sentAt":"2015-05-19T13:56:48Z","receivedAt":"2015-05-19T13:56:48Z","isPatch":false,"sender":{"key":"lpapp@kde.org","avatar":"https://gravatar.com/avatar/cffb9fb0b214d200319b3133ff5e78dcf358cc4db1bf565991e622c8c095d185?d=mp&s=160"},"body":"Hi,\n\nI have just realized that this would not work on directories\ntriggering directory renames somewhat pointless for those who want to\nkeep track of a group of files in directories.\n\nIt is unfortunate when you have a directory with many files and more\noften than not, you would like to look at the history of all rather\nthan individually.\n\nIs there any benefit about having it like it is today or is it just\nthe usual \"no one has implemented it yet\"?\n\nCheers, L.\n\nPS.: I will not stand up for implement this though, but of course I\nwill be very grateful if someone else decides to do so.\n"},{"id":"261562","messageId":"xmqqsias8rvy.fsf@gitster.dls.corp.google.com","threadId":"39368","inReplyTo":"CAOMwXhP-BRd356xpfdLgZ0zKYTMVryt8jtmi3T2jhVh91hY04Q@mail.gmail.com","subject":"Re: git log --follow for directories","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-05-19T16:16:17Z","receivedAt":"2015-05-19T16:16:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Laszlo Papp writes:\n\n> Is there any benefit about having it like it is today or is it just\n> the usual \"no one has implemented it yet\"?\n\nIt actually is even more sketchy than that. A single file following\nwas done merely as a checkbox item that works majority of the time,\nand any mergy history that renames the file on one side of the side\nbranch but not on the other may not truly follow it.\n"},{"id":"261627","messageId":"20150519235552.GB22748@peff.net","threadId":"39368","inReplyTo":"CAOMwXhP-BRd356xpfdLgZ0zKYTMVryt8jtmi3T2jhVh91hY04Q@mail.gmail.com","subject":"Re: git log --follow for directories","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-05-19T23:55:52Z","receivedAt":"2015-05-19T23:55:52Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, May 19, 2015 at 02:56:48PM +0100, Laszlo Papp wrote:\n\n> I have just realized that this would not work on directories\n> triggering directory renames somewhat pointless for those who want to\n> keep track of a group of files in directories.\n> \n> It is unfortunate when you have a directory with many files and more\n> often than not, you would like to look at the history of all rather\n> than individually.\n> \n> Is there any benefit about having it like it is today or is it just\n> the usual \"no one has implemented it yet\"?\n\nI have fooled around with accepting a full pathspec for --follow, rather\nthan a single file. In the single-file case, if we see a rename of \"A\"\nto \"B\" (and we are following \"B\"), we switch to following \"A\". With a\npathspec, that is not right. If you are following \"foo\" and \"foo/A\" is\nrenamed to \"bar/A\", you would want to start following \"bar/A\", but you\nwould _not_ want to stop matching \"foo\" (because you want to still look\nat \"foo/B\").\n\nThe most correct thing would be to match (\"!foo/A\", \"foo\", \"bar/A\").\nThat is, once we follow a rename, it is explicitly excluded from the\npathspec. It is much simpler to just do (\"foo\", \"bar/A\"). I.e., just\nalways add to the pathspec, but never take away. It is not correct, but\nit works OK in practice (and it always shows more than you might be\ninterested in, not less).\n\nJunio mentioned the other problem: our pathspec is global, but it\nactually should follow the graph itself. This is orthogonal to the\nquestion of whether we are matching one file or several, but in practice\nI suspect matching several files may make it worse (that is, the\ninaccuracies would surface more frequently).\n\nThe right way to do --follow is something like:\n\n 1. Topo-sort the commits. Attach the initial pathspec to each of the\n initial tip commits. Do our usual walk backwards (respecting the\n topo-sort).\n\n 2. If there are no renames to follow in a commit, attach the pathspec to\n its parents.\n\n 3. If there is a rename, make a new pathspec (as above) to attach to\n the parents.\n\n 4. When we try to attach a pathspec to a commit that already has one,\n we need to reconcile the two. I haven't thought hard about it, but\n it's probably something like a union of the two pathspecs. E.g.,\n consider a traversal starting at two tips, and we're interested in\n path \"B\". One line of commits renamed \"A\" to \"B\", so we start\n matching \"A\". The other created it from scratch. When we come to\n the shared ancestor of the two branches, we are probably interested\n in both \"A\" and \"B\".\n\n But like I said, I haven't really thought hard about it. That's\n just my intuition.\n\n-Peff\n"},{"id":"261652","messageId":"loom.20150520T111434-930@post.gmane.org","threadId":"39368","inReplyTo":"xmqqsias8rvy.fsf@gitster.dls.corp.google.com","subject":"Re: git log --follow for directories","fromName":"Laszlo Papp","fromEmail":"lpapp@kde.org","sentAt":"2015-05-20T09:20:58Z","receivedAt":"2015-05-20T09:20:58Z","isPatch":false,"sender":{"key":"lpapp@kde.org","avatar":"https://gravatar.com/avatar/cffb9fb0b214d200319b3133ff5e78dcf358cc4db1bf565991e622c8c095d185?d=mp&s=160"},"body":"Junio C Hamano pobox.com> writes:\n\n> \n> Laszlo Papp kde.org> writes:\n> \n> > Is there any benefit about having it like it is today or is it just\n> > the usual \"no one has implemented it yet\"?\n> \n> It actually is even more sketchy than that. A single file following\n> was done merely as a checkbox item that works majority of the time,\n> and any mergy history that renames the file on one side of the side\n> branch but not on the other may not truly follow it.\n> \n\nWell, in worst case, why not have something like --follow-dirs, then?\n\nThe case at hand is that we unfortunately named a directory based on the\ncodename of some software for the time.\n\nNow, we have improved that software and the codename is different\naccordingly. Now, instead of \"pastcodename\", I would change the directory\nname to \"src\" to be future proof, but here, I face these difficulties:\n\n1) The directory name is stuck with some ancient codename and it therefore\nwill be confusing for the rest of the life cycle for this project.\n\n2) We get unfollowable directories. At best, we could use some scripts to\nwork this around, but why not address this directly in git?\n\nI think renaming a directory without losing the history would be really cool\nto have, one way or another. If that requires a separate option, I am happy\nwith that, but what I would really like to avoid is not being able to rename\ndirectories without losing the history.\n\nNote that I am speaking from user point of view. I do not know the\nnitty-gritty technical details, but that is just implementation details as\nfar as I am concerned, anyway.\n"}]}