CODEWITHSUNDEEP
gitgithubgit-fork
Beth
Beth

Reputation: 181

git fork master always ahead of origin/master, on local and remote

Both my local repository and my fork are always ahead of origin/master. I'm currently just pushing to my master without making a separate branch. This is my workflow, which is the same workflow I've always used for other projects, without issue: 

git pull origin master

make changes to code

git commit -m "made change"
git push remote master

where remote is my personal fork. Then I submit a pull request to origin/master from github, which always gets merged without issue.

Using this workflow, somehow my local repository is always ahead by all commits I've made to the repo. Even after my pull requests are merged into origin/master, both my fork on github and my local repo say that they are x commits ahead of origin/master (even though the commits show up in the commit history of origin master). Another annoying side effect of this is that every time I pull from origin master, I have to do a merge commit because my local repo thinks it's ahead.

Does anyone know what could be going on? I've always used this workflow, but I've never encountered these problems before.

Upvotes: 0

Views: 1119

Answers (1)

torek
torek

Reputation: 488213

The maintainers of the upstream repository are probably using the "rebase and merge" button on GitHub. This copies your commits to new (and supposedly improved, but perhaps not actually improved at all—perhaps just different) commits in their repository. The copied commits have different hash IDs and therefore are different commits.

The end result of this action is that they will be ahead of your branch by N commits and you will be ahead of their branch by the same N commits. (N here is the number of commits that were in your pull request.) That's just a simple matter of counting, after all: when you started the pull request, you had:

...--o--o--*   <-- their-branch
            \
             1--2--3   <-- your-branch

in your repository, where the numbered commits are your new ones. They then copied those commits so that once you obtain them, you have:

...--o--o--*--A--B--C   <-- their-branch
            \
             1--2--3   <-- your-branch

where A-B-C are their copies of your 1-2-3. Since * is the last commit that's on both branches, they are now ahead 3, while you are also ahead 3.

You can tell that this has happened by obtaining any commits from them, into a real, actual, local Git repository (not some distant GitHub one where you have to guess at things) and inspecting the commit hash IDs and commits. If your commits have been copied to new ones, the hash IDs will not match, even if everything else about the commits does match.

If this is the case, they expect you to, like them, throw out your commits in favor of their new and (supposedly) improved commits. You can choose whether to do this or not. If you choose not to do it, you make your future work more difficult for yourself. If you choose to do it, you make your current work more difficult for yourself (though this may be a very low / small level of difficulty). That's your choice, which is forced upon you because they used "rebase and merge".

Upvotes: 1

Related Questions