Bug(let): status reports 'can fast-forward' when not true

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]