{"thread":{"id":"51574","subject":"git-log on a file, and merges","startedAt":"2019-08-02T09:39:03Z","lastAt":"2019-08-03T08:33:20Z","messageCount":5,"participants":["Piotr Krukowiecki","Derrick Stolee","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"379805","messageId":"CAA01Csp=g08N4+S1HKAjV2a12VJNSJU0UYdAU6LW1jGWLD9SLQ@mail.gmail.com","threadId":"51574","inReplyTo":null,"subject":"git-log on a file, and merges","fromName":"Piotr Krukowiecki","fromEmail":"piotr.krukowiecki@gmail.com","sentAt":"2019-08-02T09:38:50Z","receivedAt":"2019-08-02T09:39:03Z","isPatch":false,"sender":{"key":"piotr.krukowiecki@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3259959?v=4"},"body":"Hi,\n\nI have merged a branch into master.\n\nWhen on master I do \"git log -- some/file\", it does not show commits\nfrom merged branch (which I know they changed the file).\nI have to add \"--full-history\" to see the commits.\nWhen I run \"git log\" (without \"-- some/file\") I can see the commits\nwithout using \"--full-history\".\n\nThis seems not logical, and contrary to user expectations. Harmful even ;)\n\nAm I missing something?\n\ngit version 2.22.0.rc1.windows.1\n\nThanks\n-- \nPiotr Krukowiecki\n"},{"id":"379825","messageId":"05c77291-48d1-a592-6296-d8a8bdb16b02@gmail.com","threadId":"51574","inReplyTo":"CAA01Csp=g08N4+S1HKAjV2a12VJNSJU0UYdAU6LW1jGWLD9SLQ@mail.gmail.com","subject":"Re: git-log on a file, and merges","fromName":"Derrick Stolee","fromEmail":"stolee@gmail.com","sentAt":"2019-08-02T14:22:18Z","receivedAt":"2019-08-02T14:22:22Z","isPatch":false,"sender":{"key":"stolee@gmail.com","avatar":"https://avatars.githubusercontent.com/u/570044?v=4"},"body":"On 8/2/2019 5:38 AM, Piotr Krukowiecki wrote:\n> Hi,\n> \n> I have merged a branch into master.\n> \n> When on master I do \"git log -- some/file\", it does not show commits\n> from merged branch (which I know they changed the file).\n> I have to add \"--full-history\" to see the commits.\n> When I run \"git log\" (without \"-- some/file\") I can see the commits\n> without using \"--full-history\".\n> \n> This seems not logical, and contrary to user expectations. Harmful even ;)\n> \n> Am I missing something?\n\nHi Piotr,\n\nYou are falling victim to an issue related to file history simplification [1]\nand a (probably) bad merge. You can read more about how this can happen at [2].\n\nWhen git log reaches a merge commit and one of the parents matches that path\nexactly, only that parent is walked. The other is ignored. In some sense, the\nother commit did not contribute changes to that file (because we only took\nchanges from the other parent). This makes the history look good and enables\nsome performance boosts.\n\nBasically, someone must have gotten a merge conflict and used \"-S ours\" to\nwipe away the changes from the other branch on that file. You can find that\nmerge by running\n\n\tgit log --full-history --simplify-merges -- some/file\n\nYou will see the merge commit that un-did the change somewhere above the\ncommit you are expecting to see in the history.\n\nThanks,\n-Stolee\n\n\n[1] https://git-scm.com/docs/git-log#_history_simplification\n[2] https://docs.microsoft.com/en-us/azure/devops/repos/git/git-log-history-simplification?view=azure-devops\n\n"},{"id":"379847","messageId":"CAA01CspHCKA3itmTxFO1NeNB6DpdFx3CTbXKtO=TvtznLn_zAg@mail.gmail.com","threadId":"51574","inReplyTo":"05c77291-48d1-a592-6296-d8a8bdb16b02@gmail.com","subject":"Re: git-log on a file, and merges","fromName":"Piotr Krukowiecki","fromEmail":"piotr.krukowiecki@gmail.com","sentAt":"2019-08-02T19:21:28Z","receivedAt":"2019-08-02T19:21:42Z","isPatch":false,"sender":{"key":"piotr.krukowiecki@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3259959?v=4"},"body":"On Fri, Aug 2, 2019 at 4:22 PM Derrick Stolee wrote:\n>\n> On 8/2/2019 5:38 AM, Piotr Krukowiecki wrote:\n> > Hi,\n> >\n> > I have merged a branch into master.\n> >\n> > When on master I do \"git log -- some/file\", it does not show commits\n> > from merged branch (which I know they changed the file).\n> > I have to add \"--full-history\" to see the commits.\n> > When I run \"git log\" (without \"-- some/file\") I can see the commits\n> > without using \"--full-history\".\n> >\n> > This seems not logical, and contrary to user expectations. Harmful even ;)\n> >\n> > Am I missing something?\n>\n> Hi Piotr,\n>\n> You are falling victim to an issue related to file history simplification [1]\n> and a (probably) bad merge. You can read more about how this can happen at [2].\n>\n> When git log reaches a merge commit and one of the parents matches that path\n> exactly, only that parent is walked. The other is ignored. In some sense, the\n> other commit did not contribute changes to that file (because we only took\n> changes from the other parent). This makes the history look good and enables\n> some performance boosts.\n>\n> Basically, someone must have gotten a merge conflict and used \"-S ours\" to\n> wipe away the changes from the other branch on that file. You can find that\n> merge by running\n>\n> git log --full-history --simplify-merges -- some/file\n>\n> You will see the merge commit that un-did the change somewhere above the\n> commit you are expecting to see in the history.\n>\n> Thanks,\n> -Stolee\n>\n>\n> [1] https://git-scm.com/docs/git-log#_history_simplification\n> [2] https://docs.microsoft.com/en-us/azure/devops/repos/git/git-log-history-simplification?view=azure-devops\n\nThanks for explaining.\n\nThere was no \"bad\" merge. The file was modified only on the branch\n(and previously in common history).\n\nThere were two commits to this file on the branch, older one did some\nchanges, later one reverted the changes (among other things).\n\nSo my understanding is that git looked at the merge commit, saw that\nthis file was the same as it was before the merge, and assumed that\nthere were no commits which modified this file in the branches being\nmerged, so it didn't bother looking at the branch history.\n\nAt this moment I'm not sure myself if I consider this a bug or not.\nMaybe if I look at merge commits as a special entity - not a diverging\nhistory, but rather a single commit which introduces some changes -\nthen maybe I could accept it.\nBut on the other hand I feel this generates wrong results. Falsifies\nhistory. If I was asking about \"diff\", I would understand if it showed\nnothing, as there was no difference. But I'm asking for \"log\".\nEspecially that I remembered/checked that there were some changes to\nthis file, and wanted to see them.\n\n\nAnyway, is there a way to disable this behavior (enable\n\"--full-history\"?) by default?\nI suspect that this behavior will bite me in future, and I guess the\n\"performance gains\" are not big enough to validate it...\n\n\n\n-- \nPiotr Krukowiecki\n"},{"id":"379848","messageId":"xmqqtvazjrcj.fsf@gitster-ct.c.googlers.com","threadId":"51574","inReplyTo":"CAA01CspHCKA3itmTxFO1NeNB6DpdFx3CTbXKtO=TvtznLn_zAg@mail.gmail.com","subject":"Re: git-log on a file, and merges","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-08-02T19:32:28Z","receivedAt":"2019-08-02T19:32:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Piotr Krukowiecki writes:\n\n> At this moment I'm not sure myself if I consider this a bug or not.\n\nThis definitely is not a bug but is a designed and intended\nbehaviour.\n\nThink of running \"git log\" without \"--full-history\" that is limited\nwith a pathspec as a tool to ask Git to show _one_ way (preferrably\nthe simplest one) to explain how the current contents in paths that\nmatch the pathspec came to be. The \"just explain to me one way\" is\nnot about machine performance but reducing the clutter in the output\nto help human reader(s) reading an otherwise complex history.\n\n"},{"id":"379877","messageId":"CAA01CspYgcBwGsJhD3n1u7kDUy+wtjoY7bimqg7C2P3DojhfhQ@mail.gmail.com","threadId":"51574","inReplyTo":"xmqqtvazjrcj.fsf@gitster-ct.c.googlers.com","subject":"Re: git-log on a file, and merges","fromName":"Piotr Krukowiecki","fromEmail":"piotr.krukowiecki@gmail.com","sentAt":"2019-08-03T08:31:28Z","receivedAt":"2019-08-03T08:33:20Z","isPatch":false,"sender":{"key":"piotr.krukowiecki@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3259959?v=4"},"body":"On Fri, Aug 2, 2019 at 9:32 PM Junio C Hamano wrote:\n>\n> Piotr Krukowiecki writes:\n>\n> > At this moment I'm not sure myself if I consider this a bug or not.\n>\n> This definitely is not a bug but is a designed and intended\n> behaviour.\n\n(generally speaking)\nBy \"bug\" I mean wrong behaviour. Designs can be buggy too.\n\n\n> Think of running \"git log\" without \"--full-history\" that is limited\n> with a pathspec as a tool to ask Git to show _one_ way (preferrably\n> the simplest one) to explain how the current contents in paths that\n> match the pathspec came to be. The \"just explain to me one way\" is\n> not about machine performance but reducing the clutter in the output\n> to help human reader(s) reading an otherwise complex history.\n\nFrom this point of view, the current behavior is good.\n\nAlthough it's inconsistent. It works only for merges. If I'm on one\nbranch and change a file and then revert the change, \"git log -- file\"\nwill still show the commits. From your explanation, I'd expect those\ncommits to be skipped, since they are \"no-op\".\n\n\nAlso, I did read git-log docs before posting here, but still could not\nfind clear explanation for this behavior. Is it possible to improve\ndocs?\n\nFor example:\n\n [--] …\n Show only commits that are enough to explain how the files that\nmatch the specified paths came to be. See History Simplification below\nfor details and other simplification modes.\n\nFor me, the commits which modify the file are relevant to \"how the\nfile come to be\". They show what was tried and that finally the\noriginal solution was choosen as the best. So not showing them is not\n\"enough to explain\".\nAlso \"History Simplification\" is not very clear.\n\nSo maybe something like this? (just a rfc)\n\n\ndiff --git a/Documentation/git-log.txt b/Documentation/git-log.txt\nindex b406bc4c48..bfb3d68b8b 100644\n--- a/Documentation/git-log.txt\n+++ b/Documentation/git-log.txt\n@@ -91,9 +91,10 @@ include::line-range-format.txt[]\n section of linkgit:gitrevisions[7].\n\n [--] ...::\n Show only commits that are enough to explain how the files\n- that match the specified paths came to be. See 'History\n+ that match the specified paths came to be. Some commits may be\n+ not shown even if they modify the specified paths. See 'History\n Simplification' below for details and other simplification\n modes.\n +\n Paths may need to be prefixed with `--` to separate them from\ndiff --git a/Documentation/rev-list-options.txt\nb/Documentation/rev-list-options.txt\nindex bb1251c036..d2de33b219 100644\n--- a/Documentation/rev-list-options.txt\n+++ b/Documentation/rev-list-options.txt\n@@ -317,13 +317,15 @@ endif::git-rev-list[]\n History Simplification\n ~~~~~~~~~~~~~~~~~~~~~~\n\n Sometimes you are only interested in parts of the history, for example the\n-commits modifying a particular . But there are two parts of\n-'History Simplification', one part is selecting the commits and the other\n-is how to do it, as there are various strategies to simplify the history.\n+commits modifying a particular . This is a two-step process:\n\n-The following options select the commits to be shown:\n+* initialial list of commits is selected\n+\n+* the list is simplified - some commits may be not shown\n+\n+The following options select the initial list of commits:\n\n ::\n Commits modifying the given are selected.\n\n@@ -337,9 +339,11 @@ The following options affect the way the\nsimplification is performed:\n Default mode::\n Simplifies the history to the simplest history explaining the\n final state of the tree. Simplest because it prunes some side\n branches if the end result is the same (i.e. merging branches\n- with the same content)\n+ with the same content). This may happen for example when there\n+ were commits which changed files, but then those changes were\n+ reverted. Such commits will not be shown.\n\n --full-history::\n Same as the default mode, but does not prune some history.\n\n\n-- \nPiotr Krukowiecki\n"}]}