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