96

Let's say I have a local and a remote Mercurial repository. Now, I start working on a feature. I work on it, and when I think it's done, I commit the changeset. Testing it a bit more, I find that I could further improve this feature by tweaking something in the code. I make the change and commit. 20 minutes later, I find there's a bug in this new feature, so I fix it and commit that too.

I now have 3 changesets that I would really like to push to the remote repository as one changeset with message "Implementing feature X", for instance.

How can I do this without much hassle? I believe I could do it with patches, but it seems like a lot of work.

Lucas
  • 6,328
  • 8
  • 37
  • 49
  • 40
    Clearly it's not my place to talk you out of trying to compress your changesets, but you might want to consider that half the value of version control is answering "why" not just "what" months and years later. An accurate representation of how a feature came about, and in what stages, might be of future value. Discarding it seems so... unversioncontrolly. – Ry4an Brase Jul 31 '09 at 03:59
  • This does lead to another question...What's the difference between 'histedit' and 'collapse' – sylvanaar Oct 13 '09 at 15:01
  • 1
    collapse provides a subset of the features of histedit, and histedit has a much more intuative UX. – Stefan Rusek Oct 13 '09 at 20:10
  • 1
    It also provides a mechanism to edit the merged changeset message. – Stefan Rusek Oct 13 '09 at 20:21
  • @Ry4an People disagree about whether history should be a like a journal of a possibly circuitous adventure versus optimized for readability and testability. Most projects with a workflow based on pull requests or patch review on mailing lists will thanks you for the latter (and often insist on it). – Jed Feb 18 '13 at 22:45
  • 1
    @Ry4an: Actually, squashing/collapsing adds relevance to version control in some cases. Without squashing, I would have two commits every day that have nothing to do with features or bug fixes, but are for moving code from the laptop to the desktop and vice versa. They just add noise to the version history. – John Reynolds Jan 24 '14 at 18:05
  • @JohnReynolds your "noise" is my data. Maybe some day you want to run an analysis to see if you wrote more bugs at home or at the office. One never knows what data will be valuable in the future, and I prefer to discard as little as possible. Certainly to each their own. – Ry4an Brase Jan 24 '14 at 21:50
  • See also [this answer](http://stackoverflow.com/a/1725638/1132250) to "Can I squash commits in Mercurial?" – fbmd Aug 01 '14 at 07:47

11 Answers11

52

The histedit extension is exactly what you are looking for.

hg histedit -o

or

hg histedit --outgoing

will bring up a list of the outgoing changesets. From the list you can

  • Fold 2 or more changesets creating one single changeset
  • Drop changesets removing them from the history
  • Reorder changesets however you like.

histedit will prompt you for the new commit message of the folded changesets which it defaults to the two messages with "\n***\n" separating them.

You can also get similar results using the mq extension, but it is a lot more difficult.

You can also use the collapse extension to just do folding, but it doesn't provide as nice a UI and doesn't provide a way to edit the resulting commit message. Editing the resulting commit message also allows for cleaning up the final message, which is something I always end up utilizing.

Stefan Rusek
  • 4,737
  • 2
  • 28
  • 25
  • thanks, thats exactly what i needed. It'd be nice if you could do it from within TortoiseHg - but the command line is simple enough. – sylvanaar Oct 13 '09 at 12:45
39

How about the Collapse Extension?

Pulkit Goyal
  • 780
  • 4
  • 20
Steve Losh
  • 19,642
  • 2
  • 51
  • 44
  • 22
    Greetings from the future! I just googled for the same functionality and apparently nowadays hg supports this out of the box with `hg rebase --collapse`. [Check out the hg wiki on the rebase command.](https://www.mercurial-scm.org/wiki/RebaseExtension#Collapsing) Since this question is the 3rd overall search result and the first on stackoverflow I thought that info might be useful. – a.peganz Oct 02 '15 at 13:33
  • 1
    Greeting from even further in the future!! The rebase extension appears to be solely targeted at moving changesets from one branch to another. Yes, there is a --collapse option, but still appears to be only applicable when moving a set of changesets across branches. See – Brad Oestreicher Jan 22 '16 at 19:52
  • 3
    You can use `hg rebase` with `--collapse` within a single branch. – StayOnTarget Jul 29 '16 at 11:44
21

Yes, you can do it with patches: Let's assume your work is in changesets 100 through 110, inclusive

  1. Create a patch:

    % hg export -o mypatch 100:110 --git

  2. Update to 99:

    % hg update 99

  3. Apply the patch with --no-commit (otherwise you'll get all your changesets back):

    % hg import --no-commit mypatch

  4. Commit all changes at once:

    % hg commit

  5. You now have two heads (110 and 111) which should be equivalent in terms of files they produce in your working directory -- maybe diff them for sanity before stripping the old ones out:

    % hg strip 100

OK, now that I have spelled it all out, it does seem lengthy, but having done it a bunch of times myself, I don't find it to be too much of a chore...

Kharlos Dominguez
  • 2,207
  • 8
  • 31
  • 43
Arkady
  • 14,305
  • 8
  • 42
  • 46
  • 1
    Great answer, but there is a prerequisite: the [MQ extension must be enabled](http://mercurial.selenic.com/wiki/MqExtension#line-17). – Chris Kelly Jun 13 '12 at 14:04
  • To include changes in binary files as well, make sure to use the --git option: for example: "hg export -o mypatch 100:110 --git" For more information, please see: http://stackoverflow.com/a/12537738/367663 I have taken the liberty to amend the answer. – Kharlos Dominguez May 08 '14 at 11:21
  • 1
    Seems overcomplicated, why not `hg strip --keep` and then commits everything in a one commit? – G. Demecki May 23 '14 at 06:35
  • @G.Demecki Because it's a potentially very lossy operation..? Although MQ is overkill (and even oft not recommended), except when desiring such a workflow. – user2864740 Nov 20 '15 at 19:42
  • @user2864740 You may be right, cause I'm not a Mercurial expert. But by default, `hg strip` will place a backup in the `.hg/strip-backup/` directory. I guess it's not that safe as `git reflog` but still provides some kind of rescue. – G. Demecki Nov 23 '15 at 09:22
  • @G.Demecki Yeah (my previous comment was incorrect!), newer Hg even says that it is doing so - was this [message] added by the Evolve extension or is it now default? Also, I just found out with the new Evolution extensions the other 'history rewrite' changes are also written as strip backups. Not nearly as clean to navigate to as a 'headless' branch .. but just as safe. – user2864740 Nov 23 '15 at 17:16
19

If you are using TortoiseHg, use can just select two revisions (use CTRL to select non-subsequent ones), right click and select "Compress History".

After that you'll get a new change list in new head starting from the first change you selected before, it will contain all descendant change lists between the ones you selected.

You can simply strip out old change lists if you don't need them anymore: use MQ extensions for it. Again, in TortoiseHg: right click on the first change list that needs to be stripped with all it's descendants, "Modify History -> Strip".

George Marian
  • 2,680
  • 20
  • 21
18

My preferred method of using mq for this folding is using TortoiseHg as described here. However, it can easily be done from the command line like so:

hg qimport -r <first>:<last> 
    -- where <first> and <last> are the first and last changesets 
    -- in the range of revisions you want to collapse

hg qpop <first>.diff
    -- remove all except for the first patch from the queue
    -- note: mq names patches <#>.diff when it imports them, so we're using that here

hg qfold <next>.diff
    -- where <next> is <first>+1, then <first>+2, until you've reached <last>

hg qfinish -a
    -- apply the folded changeset back into the repository

(There may be a better way to do the qfold step, but I'm not aware of it, as I usually use TortoiseHg for that operation.)

It seems a little complicated at first, but once you've started using mq, it's pretty straightforward and natural -- plus you can do all kinds of other things with mq that can be pretty handy!

tshepang
  • 12,111
  • 21
  • 91
  • 136
Chris Phillips
  • 11,607
  • 3
  • 34
  • 45
4

hg collapse and hg histedit are the best ways. Or, rather, would be the best ways, if they worked reliably... I got histedit to crash with a stack dump within three minutes. Collapse is not that much better.

Thought I might share two other BKMs:

  1. hg rebase --collapse

    This extension is distributed with Mercurial. I haven't had problems with it yet. You may have to play some games to work around hg rebase limitations -- basically, it doesn't like rebasing to an ancestor on the same branch, named or default, although it does allow it if rebasing between (named) branches.

  2. Move the repository (foo/.hg) to the working directory (bar) and its files. Not the other way around.

Some people have talked about creating two clone trees, and copying files between them. Or patching between them. Instead, its easier to move the .hg directories.

hg clone project work
... lots of edits
... hg pull, merge, resolve
hg clone project, clean
mv work/.hg .hg.work
mv clean/.hg work/.hg
cd work
... if necessary, pull, nerge, reconcile - but that would only happen because of a race
hg push

This works as long as the true repositories, the .hg trees, are independent of the working directory and its files.

If they are not independent...

tshepang
  • 12,111
  • 21
  • 91
  • 136
Krazy Glew
  • 7,210
  • 2
  • 49
  • 62
  • In 2015, `histedit` is a very good option for this task. I still don't trust it as I do a git rebase -i, but it doesn't crash.. at least newer versions will leave you on a temp branch if something goes horribly wrong so the only time that the changesets will be stripped is after the new branch is committed. – user2864740 Nov 20 '15 at 19:44
2

I've never used Mercurial, but this sounds a lot like what Martin Fowler was talking about on his blog not too long ago:

http://martinfowler.com/bliki/MercurialSquashCommit.html

Joseph
  • 383
  • 2
  • 7
  • That looks more than a bit complicated, but thanks for the link. Honestly I'm hoping for some magical extension that will do just what I want, like fetch and transplant did with pulling and cherry-picking changsets. – Lucas Jul 29 '09 at 14:43
0

HistEdit will do what you want, but it's probably overkill. If the only thing you need is to fold some changesets together the Collapse Extension will do the job.

Pulkit Goyal
  • 780
  • 4
  • 20
Steve Losh
  • 19,642
  • 2
  • 51
  • 44
  • 1
    though it does provide a much easier to use and understand UI, which is more than enough of a reason to use it, but it also provides a mechanism to edit the merged changeset message, which is another thing that I always want to do when I merge changesets. – Stefan Rusek Oct 13 '09 at 20:21
  • And the problem of only understanding the UI is one really doesn't understand.. Anyway, for the past while histedit allows changing 'mess'ages, as well as changing messages when 'fold'ing. The histedit is perfect; if anything, the collapse extension is underuseful. – user2864740 Nov 20 '15 at 19:45
0

Why not just hg strip --keep command?

Then you can commit all changes as a one commit.

G. Demecki
  • 10,145
  • 3
  • 58
  • 58
  • @Strawberry doesn't provide an answer?? It think it perfectly answers the author question. Can you elaborate your point? – G. Demecki Nov 23 '15 at 09:09
  • It's ancient history, so I'll retract the remark - but the Approved answer seems like a more authoritative reference. – Strawberry Nov 23 '15 at 09:57
  • 1
    @Strawberry Indeed it's ancient thread. But the accepted answer is outdated, because Mercurial no longer needs a separate 3rd party extension to this job. – G. Demecki Nov 23 '15 at 10:08
0

Suppose you have two unpublished THIS and THAT commits in Mercurial and like them to join into single commit at THIS point::

... --> THIS --> ... --> THAT --> ... --> LAST

Check that your commits are not published::

$ hg glog -r "draft() & ($THIS | $THAT)"

Update to LAST commit::

$ hg up

and import commits up to THIS into MQ::

$ hg qimport $THIS::.

Un-apply all patches and apply only first THIS::

$ hg qpop -a
$ hg qpush
$ hg qapplied
... THIS ...

Join with THAT::

$ hg qfold $THATNAME

NOTE To find name THATNAME use::

$ hg qseries

Apply all patches and move them to repository history::

$ hg qpush -a
$ hg qfinish -a

My blog post on subject is Joining two commits in Mercurial.

gavenkoa
  • 45,285
  • 19
  • 251
  • 303
0

Yes, strip --keep works for Author's question. But it was slightly different from others, for example, if you have version from 1 to 30 but only want to collapse version 12-15. Other solutions work but not strip --keep.

Stephen Rauch
  • 47,830
  • 31
  • 106
  • 135
Frank Tao
  • 1
  • 1