{"thread":{"id":"18989","subject":"Bug(let): status reports 'can fast-forward' when not true","startedAt":"2009-04-21T20:53:52Z","lastAt":"2009-04-22T08:07:42Z","messageCount":4,"participants":["Charles Bailey","Jeff King","Junio C Hamano","Kjetil Barvik"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"111904","messageId":"20090421205352.GA29125@hashpling.org","threadId":"18989","inReplyTo":null,"subject":"Bug(let): status reports 'can fast-forward' when not true","fromName":"Charles Bailey","fromEmail":"charles@hashpling.org","sentAt":"2009-04-21T20:53:52Z","receivedAt":"2009-04-21T20:53:52Z","isPatch":false,"sender":{"key":"charles@hashpling.org","avatar":"https://avatars.githubusercontent.com/u/1668475?v=4"},"body":"I was not really thinking when I get fetched, and ran git status on my\npu branch. I was told that pu was behind origin/pu by 104 commits and\ncould be fast-forwarded, so I git merged origin/pu and was mildly\nsurprised when git merge made a commit for me.\n\nA quick investigation revealed that pu had (of course) been rewound,\nbut the only commits that it had that the new pu didn't, were merge\ncommits.\n\nI think that the problem is that in remote.c, a list of non-merge\ncommits is generated for the status report. If it's non-zero, then\nit's the correct number of 'useful' commits to report, however if it\nis zero then this is not sufficient for a merge to fast-forward. The\ntotal number of commits unique to the local branch, including merges,\nmust also be zero.\n\nIs this a bug?\n\n-- \nCharles Bailey\nhttp://ccgi.hashpling.plus.com/blog/\n"},{"id":"111905","messageId":"20090421210233.GB13151@coredump.intra.peff.net","threadId":"18989","inReplyTo":"20090421205352.GA29125@hashpling.org","subject":"Re: Bug(let): status reports 'can fast-forward' when not true","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-04-21T21:02:33Z","receivedAt":"2009-04-21T21:02:33Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"[cc'ing Kjetil, as this is a fallout of 19de5d6]\n\nOn Tue, Apr 21, 2009 at 09:53:52PM +0100, Charles Bailey wrote:\n\n> I was not really thinking when I get fetched, and ran git status on my\n> pu branch. I was told that pu was behind origin/pu by 104 commits and\n> could be fast-forwarded, so I git merged origin/pu and was mildly\n> surprised when git merge made a commit for me.\n> \n> A quick investigation revealed that pu had (of course) been rewound,\n> but the only commits that it had that the new pu didn't, were merge\n> commits.\n\nI think this is an unintended consequence of 19de5d6\n(stat_tracking_info(): only count real commits, 2009-03-04). It is\nperhaps more useful when seeing the actual numbers to see only the count\nof real commits, but it makes statements like \"can be fast-forwarded\" no\nlonger true.\n\nSo I think we need to either:\n\n 1. reword the \"can be fast-forwarded\" text to something else\n\n 2. revert 19de5d6, since merge commits _can_ be interesting\n\n 3. refactor stat_tracking_info to return \"real\" and \"merge\" counts,\n and change the text for the case of \"real == 0 && merge > 0\".\n\n-Peff\n"},{"id":"111911","messageId":"7veivl60yt.fsf@gitster.siamese.dyndns.org","threadId":"18989","inReplyTo":"20090421210233.GB13151@coredump.intra.peff.net","subject":"Re: Bug(let): status reports 'can fast-forward' when not true","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-04-21T23:28:26Z","receivedAt":"2009-04-21T23:28:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> [cc'ing Kjetil, as this is a fallout of 19de5d6]\n>\n> On Tue, Apr 21, 2009 at 09:53:52PM +0100, Charles Bailey wrote:\n>\n>> I was not really thinking when I get fetched, and ran git status on my\n>> pu branch. I was told that pu was behind origin/pu by 104 commits and\n>> could be fast-forwarded, so I git merged origin/pu and was mildly\n>> surprised when git merge made a commit for me.\n>> \n>> A quick investigation revealed that pu had (of course) been rewound,\n>> but the only commits that it had that the new pu didn't, were merge\n>> commits.\n>\n> I think this is an unintended consequence of 19de5d6\n> (stat_tracking_info(): only count real commits, 2009-03-04). It is\n> perhaps more useful when seeing the actual numbers to see only the count\n> of real commits, but it makes statements like \"can be fast-forwarded\" no\n> longer true.\n>\n> So I think we need to either:\n>\n> 1. reword the \"can be fast-forwarded\" text to something else\n>\n> 2. revert 19de5d6, since merge commits _can_ be interesting\n>\n> 3. refactor stat_tracking_info to return \"real\" and \"merge\" counts,\n> and change the text for the case of \"real == 0 && merge > 0\".\n>\n> -Peff\n\nLet's revert it for now and then try #3 after 1.6.3 final.\n"},{"id":"111928","messageId":"86d4b5i01d.fsf@broadpark.no","threadId":"18989","inReplyTo":"7veivl60yt.fsf@gitster.siamese.dyndns.org","subject":"Re: Bug(let): status reports 'can fast-forward' when not true","fromName":"Kjetil Barvik","fromEmail":"barvik@broadpark.no","sentAt":"2009-04-22T08:07:42Z","receivedAt":"2009-04-22T08:07:42Z","isPatch":false,"sender":{"key":"barvik@broadpark.no","avatar":null},"body":"Junio C Hamano writes:\n\n> Jeff King writes:\n>\n>> [cc'ing Kjetil, as this is a fallout of 19de5d6]\n>>\n>> On Tue, Apr 21, 2009 at 09:53:52PM +0100, Charles Bailey wrote:\n>>\n>>> I was not really thinking when I get fetched, and ran git status on my\n>>> pu branch. I was told that pu was behind origin/pu by 104 commits and\n>>> could be fast-forwarded, so I git merged origin/pu and was mildly\n>>> surprised when git merge made a commit for me.\n>>> \n>>> A quick investigation revealed that pu had (of course) been rewound,\n>>> but the only commits that it had that the new pu didn't, were merge\n>>> commits.\n>>\n>> I think this is an unintended consequence of 19de5d6\n>> (stat_tracking_info(): only count real commits, 2009-03-04). It is\n>> perhaps more useful when seeing the actual numbers to see only the count\n>> of real commits, but it makes statements like \"can be fast-forwarded\" no\n>> longer true.\n>>\n>> So I think we need to either:\n>>\n>> 1. reword the \"can be fast-forwarded\" text to something else\n>>\n>> 2. revert 19de5d6, since merge commits _can_ be interesting\n>>\n>> 3. refactor stat_tracking_info to return \"real\" and \"merge\" counts,\n>> and change the text for the case of \"real == 0 && merge > 0\".\n>>\n>> -Peff\n>\n> Let's revert it for now and then try #3 after 1.6.3 final.\n\n OK. \n\n Then I have some time thinking about a solution. Maybe:\n\n 4. Introduce an argument \"--no-merges\", and then only show real\n commits when used.\n\n -- kjetil\n"}]}