Are squashed commits and discarded branches possible in bzr?

Todd A. Jacobs nospam at codegnome.org
Wed May 12 00:33:53 BST 2010


On Mon, May 10, 2010 at 02:27:43PM -0500, John Arbash Meinel wrote:

> I should note that "squashed commits" aren't really "first class"
> citizens in git either. Doing the above with "git merge --squash" will
> give you the same conflicts as doing it with "bzr merge; bzr revert -
> --forget-merges".

Well, they are a first-class feature from a UI point of view, but after
doing a bit of testing it certainly seems like the results are the same
either way.

If I have a file "foo," and make incremental changes, do a squash
commit, and then re-merge the branches, history looks about the same in
both DVCSes:

Git thinks:

    *   82e0a02 Merge branches 'HEAD' and 'feature-bar'
    |\  
    | * 49425e0 Added baz.
    | * 4796481 Added bar.
    * | 711d06c Squashed commit.
    |/  
    * 78eca55 Foo.

while bzr thinks:

    3: Todd A. Jacobs 2010-05-10 [merge] Merges.
      1.1.2: Todd A. Jacobs 2010-05-10 Added baz.
      1.1.1: Todd A. Jacobs 2010-05-10 Added bar.
    2: Todd A. Jacobs 2010-05-10 Added bar and baz.
    1: Todd A. Jacobs 2010-05-10 Foo.

which groks about the same to me. Neither DVCS gave me any drama about
re-merging, and both basically treated the re-merge as a linking of a
common ancestor and therefore cluttered the history with a series of
unsquashed commits *after* the squashed commit.

In other words, other than being able to discard the feature-bar branch
(which is easy in git, but seems impossible *within* a shared
respository in bzr) the two provide equivalent functionality.

Thanks to everyone who chimed in on this, and got me pointed in the
right direction.

-- 
"Oh, look: rocks!"
	-- Doctor Who, "Destiny of the Daleks"




More information about the bazaar mailing list