1

When working with a Mercurial repository ("outer") that has a subrepository ("inner"), often you can end up with the problem whereby you're trying to do a merge on the outer but it fails due to "uncommitted changes" when no changes are apparent (hg st for the outer shows no changes).

The problem is down to the subrepository state: the .hgsubstate file contains a changeset ID for the subrepo which is actually different to the subrepo working copy changeset (or, trivially, there is an uncommitted change in the subrepo).

I can fix it when it occurs but can anyone recommend a Mercurial workflow for pull and merging which always avoids this problem? I can work it out by playing with test repos etc., but maybe someone can save me and others some time if they already know.

The simpler the workflow the better, as this is for a small team rather than just one person.

Examples of the issue:

Update - notes on the workings of .hgsubstate

The only two actions that update the .hgsubstate file (when using command line) are as follows:

  1. If you pull a version of the outer project, you get whatever .hgsubstate was checked in (obviously)

  2. If you commit the outer project, the .hgsubstate is updated to the current parent changeset for the inner project

If you update the subrepo but make no changes to the outer project, the outer will show no changes if you do hg status. However, if you run hg status -S, you will get file status for the subrepo (as well as the outer project). The file statuses of the subrepo shown are a mixture of:

a) any uncomitted working copy changes to files in subrepo

b) any committed changes to subrepo that are newer than the changeset id in .hgsubstate

If you attempt to commit the outer project, even if hg st shows no changes, it will allow you to commit an udpated version of the .hgsubstate file if the subrepo does indeed have a newer tip changeset. So a crucial strategy is to use hg st -S which will show if there's anything pending in your subrepo, such as work copy changes or changesets newer than the id named in .hgsubstate.

occulus
  • 16,959
  • 6
  • 53
  • 76
  • I usually have another repo cloned on my machine that's clean. I can pull from my local repo, then merge, then push without dealing with uncommitted changes. – nlucaroni Feb 08 '13 at 15:42
  • @nlucaroni I don't understand how that helps; can you explain more please? Are you referring to a way of stopping inner repository works-in-progress from preventing you committing changes to the outer repo? I'm familiar with that strategy, but it doesn't address my issue. – occulus Feb 08 '13 at 15:48
  • @occulus: you say that you can fix it when it occurs. How do you fix it? – m4l490n Aug 12 '15 at 02:25

0 Answers0