:: [DNG] The figure of commits behind …
Top Page
Delete this message
Reply to this message
Author: Anto
Date:  
To: dng
Subject: [DNG] The figure of commits behind the upstream on github
Hello everybody,

I forked a project on github and added some commits on top of the ones
on upstream repository. The figure of commits behind on github web
interface is quite important for me as that indicates whether there are
new commits on upstream that I need to merge or not.

There are 33 new commits being added into the upstream repository
recently. I merged only 29 of them into mine. Before I merged those 29
commits, it had 11,534 total commits, 849 commits ahead and 33 commits
behind the upstream repository. After the merged, it has 11,564 total
commits, 854 commits ahead and 8 commits behind the upstream repository.
The difference on the total commits looks alright, i.e. 30 commits (29
from the upstream and 1 merge commit that I added). The commits ahead
figure looks alright as well because I did "git rebase -i" of the last 8
commits and deleted the 4 commits that I don't want, so the commits
ahead difference is 5 commits (4 from the upstream and 1 merge commit
that I added).

However, I cannot figure out why I got 8 commits behind the upstream. I
am afraid that I missed to merge 4 more commits. But several times I
checked the changes on each file affected by all 29 commits and they
look alright. Is it because of I deleted 4 commits so another 4 commits
related to the ones I deleted also got deleted? If so, how to find that
out which ones also got deleted? But in any case, the difference on the
total commits is correct. Is this an obvious problem on github, that if
we deleted some commits, the figure of commits behind becomes double? Or
perhaps was that because I wrongly did the merge?

I tried to use "git cherry-pick" before, but the figure of commit behind
remains 33 commits even though the total commits became 29 commits more.
I think that is because "git cherry-pick" does not preserve the original
history, so original commits are considered as new commits on my fork
repository.

If the figure of commits behind on github web interface is not reliable,
does anybody have any suggestion how to easily find out that our fork
repositories need updating without keep checking the upstream repositories?

Thanks a lot in advance.

Kind regards,

Anto