Avoid pushing unwanted local history to main repository in Bazaar or Mercurial

Question

I'm new to DVCS so I'm probably misunderstanding some concepts and terminology, but this is the idea of what I'm trying to achieve, and I'm trying to find out if either Bazaar or Mercurial supports this in a straightforward manner:

There is main repository with well-tested code. Say I clone (or pull or branch or whatever the terminology is) from that into a local repository, then every day as I work on the code I commit changes locally, sometimes multiple times a day.

After I'm done with all my changes and testing, I want to get only the latest (locally) committed version of every file put into the main repository, without the dozens of intermediate versions that I committed locally during debugging and unit testing.

From what I've been reading, apparently the entire history of those half-baked versions would get reflected in the main repository if I push to it. Some internet articles seem to suggest that rebase might address that issue if it's handled right, but it's not so clear if/how that can be done, as it seems like rebase is more for avoiding a bifurcated branch/merge history than for avoiding the committing of a large set of intermediate versions.

Answer 1

Some bazaar options.

1. If you want to get rid of the dozens of local commits, you are actually throwing away history. One way of doing it is with the bzr uncommit command. eg.

   bzr uncommit -rbranch:https://url_to_mainrepo
   

   (Throw away rivisions until you get to the revision of the main repo. Don't worry it will show you what will be done and confirm with you before doing it)

   Then you can do a new commit with all the others collapsed into one.

2. Bazaar normally hides merged revisions. One way for you to roll up your tiny commits into a merged revision is to keep a local branch/checkout of the main repo. Then when you are ready, bzr merge in your changes into your local main-repo-clone and then commit a merged revision.

   This way you still keep all your history but all the little revisions are neatly rolled up into a merge revision. You can then still see that history when you want.

Here is examples of how to not see merged revisions:

$ bzr log
------------------------------------------------------------
revno: 2 [merge]
message:
  summary of the things I did
------------------------------------------------------------
revno: 1
message:
  some change on the mainline
------------------------------------------------------------
Use --include-merged or -n0 to see merged revisions.

Here is examples of how to see merged revisions:

$ bzr log -n0
------------------------------------------------------------
revno: 2 [merge]
message:
  summary of the things I did
    ------------------------------------------------------------
    revno: 1.1.2
    message:
      my first step
    ------------------------------------------------------------
    revno: 1.1.1
    message:
      my second step
------------------------------------------------------------
revno: 1
message:
  some change on the mainline

Answer 2

The keywords you're looking for are collapse or fold (Mercurial) or squash (Git). I'm afraid I don't know what the usual term is for this in Bazaar.

In Mercurial you can use the histedit extension (a bundled extension since Mercurial 2.3) to fold a series of changesets into a single changeset. It provides a superset of the functionality in the third-party collapse extension.

The rebase extension (another standard extension) has the same functionality with the --collapse flag. You're completely right that rebasing is normally done to avoid unnecessary merges, but it somehow also got to be used for collapsing (and editing) changesets in Git. The histedit extension for Mercurial is modeled after the interactive rebase commmand in Git.

Answer 3

In Bazaar, this is handled by having a separate "clone" (i.e. bzr branch URL) of the main repo locally and then you create local feature branches from that in which you do your work with multiple commits. When you're ready to move that work into the main repo, you bzr merge the feature branch into the main branch. That leaves you with a modified working tree in the main branch which you then commit and push to your official main repo. This commit includes the revision history from your feature branch but it's normally hidden in bzr log or other log history views.