# Bug(let): status reports 'can fast-forward' when not true 4 messages from 2009-04-21 to 2009-04-22. Participants: Charles Bailey, Jeff King, Junio C Hamano, Kjetil Barvik. Thread: https://gitlist.dev/t/18989 ## Charles Bailey, 2009-04-21 20:53 Subject: Bug(let): status reports 'can fast-forward' when not true Message-ID: <20090421205352.GA29125@hashpling.org> URL: https://gitlist.dev/e/20090421205352.GA29125%40hashpling.org ``` I was not really thinking when I get fetched, and ran git status on my pu branch. I was told that pu was behind origin/pu by 104 commits and could be fast-forwarded, so I git merged origin/pu and was mildly surprised when git merge made a commit for me. A quick investigation revealed that pu had (of course) been rewound, but the only commits that it had that the new pu didn't, were merge commits. I think that the problem is that in remote.c, a list of non-merge commits is generated for the status report. If it's non-zero, then it's the correct number of 'useful' commits to report, however if it is zero then this is not sufficient for a merge to fast-forward. The total number of commits unique to the local branch, including merges, must also be zero. Is this a bug? -- Charles Bailey http://ccgi.hashpling.plus.com/blog/ ``` ## Jeff King, 2009-04-21 21:02 Subject: Re: Bug(let): status reports 'can fast-forward' when not true Message-ID: <20090421210233.GB13151@coredump.intra.peff.net> URL: https://gitlist.dev/e/20090421210233.GB13151%40coredump.intra.peff.net In-Reply-To: <20090421205352.GA29125@hashpling.org> ``` [cc'ing Kjetil, as this is a fallout of 19de5d6] On Tue, Apr 21, 2009 at 09:53:52PM +0100, Charles Bailey wrote: > I was not really thinking when I get fetched, and ran git status on my > pu branch. I was told that pu was behind origin/pu by 104 commits and > could be fast-forwarded, so I git merged origin/pu and was mildly > surprised when git merge made a commit for me. > > A quick investigation revealed that pu had (of course) been rewound, > but the only commits that it had that the new pu didn't, were merge > commits. I think this is an unintended consequence of 19de5d6 (stat_tracking_info(): only count real commits, 2009-03-04). It is perhaps more useful when seeing the actual numbers to see only the count of real commits, but it makes statements like "can be fast-forwarded" no longer true. So I think we need to either: 1. reword the "can be fast-forwarded" text to something else 2. revert 19de5d6, since merge commits _can_ be interesting 3. refactor stat_tracking_info to return "real" and "merge" counts, and change the text for the case of "real == 0 && merge > 0". -Peff ``` ## Junio C Hamano, 2009-04-21 23:28 Subject: Re: Bug(let): status reports 'can fast-forward' when not true Message-ID: <7veivl60yt.fsf@gitster.siamese.dyndns.org> URL: https://gitlist.dev/e/7veivl60yt.fsf%40gitster.siamese.dyndns.org In-Reply-To: <20090421210233.GB13151@coredump.intra.peff.net> ``` Jeff King writes: > [cc'ing Kjetil, as this is a fallout of 19de5d6] > > On Tue, Apr 21, 2009 at 09:53:52PM +0100, Charles Bailey wrote: > >> I was not really thinking when I get fetched, and ran git status on my >> pu branch. I was told that pu was behind origin/pu by 104 commits and >> could be fast-forwarded, so I git merged origin/pu and was mildly >> surprised when git merge made a commit for me. >> >> A quick investigation revealed that pu had (of course) been rewound, >> but the only commits that it had that the new pu didn't, were merge >> commits. > > I think this is an unintended consequence of 19de5d6 > (stat_tracking_info(): only count real commits, 2009-03-04). It is > perhaps more useful when seeing the actual numbers to see only the count > of real commits, but it makes statements like "can be fast-forwarded" no > longer true. > > So I think we need to either: > > 1. reword the "can be fast-forwarded" text to something else > > 2. revert 19de5d6, since merge commits _can_ be interesting > > 3. refactor stat_tracking_info to return "real" and "merge" counts, > and change the text for the case of "real == 0 && merge > 0". > > -Peff Let's revert it for now and then try #3 after 1.6.3 final. ``` ## Kjetil Barvik, 2009-04-22 08:07 Subject: Re: Bug(let): status reports 'can fast-forward' when not true Message-ID: <86d4b5i01d.fsf@broadpark.no> URL: https://gitlist.dev/e/86d4b5i01d.fsf%40broadpark.no In-Reply-To: <7veivl60yt.fsf@gitster.siamese.dyndns.org> ``` Junio C Hamano writes: > Jeff King writes: > >> [cc'ing Kjetil, as this is a fallout of 19de5d6] >> >> On Tue, Apr 21, 2009 at 09:53:52PM +0100, Charles Bailey wrote: >> >>> I was not really thinking when I get fetched, and ran git status on my >>> pu branch. I was told that pu was behind origin/pu by 104 commits and >>> could be fast-forwarded, so I git merged origin/pu and was mildly >>> surprised when git merge made a commit for me. >>> >>> A quick investigation revealed that pu had (of course) been rewound, >>> but the only commits that it had that the new pu didn't, were merge >>> commits. >> >> I think this is an unintended consequence of 19de5d6 >> (stat_tracking_info(): only count real commits, 2009-03-04). It is >> perhaps more useful when seeing the actual numbers to see only the count >> of real commits, but it makes statements like "can be fast-forwarded" no >> longer true. >> >> So I think we need to either: >> >> 1. reword the "can be fast-forwarded" text to something else >> >> 2. revert 19de5d6, since merge commits _can_ be interesting >> >> 3. refactor stat_tracking_info to return "real" and "merge" counts, >> and change the text for the case of "real == 0 && merge > 0". >> >> -Peff > > Let's revert it for now and then try #3 after 1.6.3 final. OK. Then I have some time thinking about a solution. Maybe: 4. Introduce an argument "--no-merges", and then only show real commits when used. -- kjetil ```