CODEWITHSUNDEEP
mercurialtortoisehgkiln
FeelsLikeANoob
FeelsLikeANoob

Reputation: 1

Mercurial merges of different files

We are using mercurial/tortoisehg with a central repository hosted on kiln.

We have narrowed down what we are doing to the simplest possible scenario. The scenario starts with Bob and Joe having cloned the kiln repository, so they both start with identical sets.

  1. Bob changes file a.txt, commits and pushes it to kiln.
  2. Joe changes file b.txt and commits.
  3. Joe tries to push to kiln, but gets these errors: remote has heads on branch 'default' that are not known locally: 503dc02bd36c abort: push creates new remote head dba053a5be68!
  4. This is obviously due to Bob's changes that need to be pulled from kiln first. So, Joe pulls the changes from kiln and succeeds
  5. Joe tries to push to kiln, but gets these errors: abort: push creates new remote head dba053a5be68!
  6. Joe merges his commits with local and it succeeds
  7. Joe now tries to push to kiln and succeeds

In this scenario, it seems like Mercurial should detect that both users updated different files and not force a merge, which is essentially Joe pulling Bob's changes and having to recommit and push the changes of both users.

Thanks everyone. To clarify my question: We are curious whether we have missed something or this is just how it works. In this scenario, even though there is no conflict during merge, hg still forces me to have to pull, merge, recommit and re-push my colleague's changes that he has already committed and pushed to the central repository.

Upvotes: 0

Views: 147

Answers (1)

J. Titus
J. Titus

Reputation: 9690

That's how Mercurial works.

If Joe did not have changes, there would be no need for a merge or merge commit and he could just use hg update tip or hg pull. However, since Joe had changes when making the pull request, even though they were not in the same file, a merge is required.

This information can be found in Mercurial's guide: https://www.mercurial-scm.org/guide

If you didn't do any changes in the project, while you were working on feature1, you can just update to tip (hg update tip), but it is more likely that you'll have done some other changes in between changes. In that case, it's time for merging.

Merge feature1 into the project code

$ hg merge

If there are conflicts use hg resolve - that's also what merge tells you to do in case of conflicts. After you merge, you have to commit explicitly to make your merge final

$ hg commit

Upvotes: 1

Related Questions