2

With Mercurial I often see a scenario where I need to gradually commit an push, but if another person commits in the middle of this then I get into a problem.

Example: Assume the HG repo has four files a.txt, b.txt, c.txt, d.txt and we have two users Mickey and Goofy:

Mickey does:  $ echo "change1" >> a.txt
Mickey does:  $ echo "change2" >> b.txt
Mickey does:  $ echo "change3" >> c.txt
Mickey does:  $ hg commit -m "I am good" a.txt
Goofy does:   $ hg pull -u; echo "change4" >> d.txt; hg commit -m "The Donald change" 

Mickey gets ready to commit and push, but has has to merge: Mickey does: $ hg pull -u

Now Mickey has two changes - in b.txt and c.txt. Lets assume that his changes in c.txt are complex and cannot be released just now. How can Mickey get his changes in a.txt and b.txt committed and pushed without committing c.txt yet?

Gangnus
  • 24,044
  • 16
  • 90
  • 149
Peter Toft
  • 565
  • 7
  • 19

2 Answers2

2

Just issue the filenames you're interested in committing:

hg commit a.txt b.txt -m'partial commit'

Then push as usual.

EDIT: Iyou could try saving the local changes as a patch, revert and pull the remote changes, then apply the patch:

hg diff > local.patch
hg revert
hg pull -u
patch -p1 < local.patch
piwi
  • 5,136
  • 2
  • 24
  • 48
  • Not ok - Mickey needs to merge before he can commit, and there the problem is that c.txt cannot be committed yet.... – Peter Toft Jun 04 '12 at 13:13
  • My bad, I did not read the question thoroughly enough... Then what about putting the changes in a separate branch (or even cloning the repo)? – piwi Jun 04 '12 at 13:36
  • I think you need a "hg revert ." after the first hg diff – Peter Toft Jun 04 '12 at 14:06
  • The [shelve extension](http://mercurial.selenic.com/wiki/ShelveExtension) can be a simpler alternative to the patch approach. – brandizzi Sep 17 '12 at 15:14
1

Your question is not entirely clear to me, please correct me if I got you wrong.

What Mickey has in his repo is this (A — Mickey's changeset with a changed, D — Goofy's changeset with d changed, w — Mickey's working copy with b and c changed):

-- o --- A --- w
    \
     D

Now Mickey has a plenty of options. b is ready to be released, so he commits it immediately:

$ hg ci b.txt -m "Finished working on b.txt"

-- o --- A --- B --- w
    \
     D

Now only c changes are left in the working copy. Mickey does an intermediate commit:

$ hg ci -m "working on c"

-- o --- A --- B --- C' --- w
    \
     D

The working copy is clean. To make sure C' is not included in the merge, Mickey updates to the previous changeset, then merges:

$ hg up B
$ hg merge D
$ hg ci -m "Merged with Goofy"

-- o --- A --- B --- C
    \           \
     D --------- M --- w

Now Mickey can continue working on C, and amend the commit when it's ready:

$ hg up C
$ echo "final change" >> c.txt
$ hg ci --amend -m "Finished working on c.txt"

From here, Mickey can either merge, or rebase (by the way, merge with Goofy could be a rebase as well).

Helgi
  • 5,428
  • 1
  • 31
  • 48
  • The option "--amend" I have never seen - and HG 2.1.2 does not recognize it. Is this a new option? – Peter Toft Jun 06 '12 at 08:04
  • @PeterToft: `--amend` was introduced in [Mercurial 2.2](http://mercurial.selenic.com/wiki/WhatsNew#Mercurial_2.2_.282012-05-01.29), about a month ago. Not that the effect can't be achieved by other means, but it's very handy. In absence of this option, you can use MQ (`qimport`, `qrefresh`, then `qfinish`). – Helgi Jun 06 '12 at 17:47