Did a commit before I did a pull

[psykojello]

I'm new to mercurial/git/sourcetree - I come from a perforce world, so the terminology is all alien to me. I'm hoping someone can help me with this problem.

I have a project hosted on a bitbucket mercurial repository. I'm using sourcetree as my client on my PC and on my Mac. A friend of mine is also working remotely on the same project.

I always first pull and then do a push and commit together so that the hosted repository is always current.

Here's the problem I run into. Sometimes I unwittingly press commit before remembering to do a pull. It turns out that my friend has submitted a change in that time and I have a new change to pull. So I end up with a branched changelist. Now I'm unable to push my changes anymore - it says: abort: "push creates new remote head (did you forget to merge? use push -f to force)"

What exactly am I supposed to merge? my changelist? My friend's changelist that got pulled?

Either way, I'm not able to merge my changes.

I can't reverse commit my changes either. None of those options work for me.

My question probably makes no sense to anyone else, so please let me know if I can explain myself better :)

[Seth · Accepted solution]

This is a typical situation during any type of collaborative development. Before I explain the way forward, I want to point out that your typical workflow (make changes, pull, commit+push) is going to cause a different set of problems if the pull contains changes to a file you've modified locally. The best solution in that case is to do what you're doing now (make changes, commit, pull+merge, push).

So, You've made changes and committed those changes. This is good. Once your changes are committed in the repository, they are much harder to lose. In any case, you are halfway there.

Before you can push your changes to your branch in Bitbucket (remote, central repository), you need to make sure your local repository has alal changes that have been made to Bitbucket. The correct next step IS to pull. This can work one of two ways:

1) Traditional pull: A merge command will combine the remote changes with your local changes. This will add a new commit, and the changelist should depict that the separate lines of development have come back together.

2) Pull+rebase: If you check the rebase option, Hg/Git will temporarily undo ("rewind") any changes from new local commits, fast-forward so the local branch is identical to the remote, then redo ("replay") the local changes/commits to the new HEAD of the branch. This will change the timestamps of your local commits, but the changelist should depict that all changes happened linearly.

In either case, there is a chance you will need to resolve conflicts if you and your friend happenned to change any overlapping pieces of code in your latest commits.

A nice discussion on merge vs rebase.

[psykojello]

Thanks for the clear an concise explanation! Now that I understand the workflow, I can figure out how to work with Sourcetree to achieve this.

[Soldier]

Hi @psykojello ,

I also meet the same situation with you, would you mind to share you idea & solution with us? Believe it very useful for us. 

BR,

Soldier

[psykojello]

Hi @Soldier , sorry that was so long ago I don't remember what I did :)
Seth's explanation seems pretty clear so that must have helped me understand what I was doing wrong. 

Good luck - if I could figure it out, so can you! 

Sorry I wasn't much help :)