Are squashed commits and discarded branches possible in bzr?

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Todd A. Jacobs wrote:
> On Mon, May 10, 2010 at 12:24:08AM +0200, Jelmer Vernooij wrote:
> 
>> $ bzr merge ../feature-branch
>> $ bzr revert --forget-merges
>> $ bzr commit -m "New commit message for squashed commit"
>>
>> Does that address your use case?
> 
> Mostly, although now that I know where to look in the docs, I'm
> concerned about the warning that says:
> 
>     Because this technique forgets where these changes originated, it
>     may cause additional conflicts on later merges involving the same
>     source and target branches.
> 
> This has never been a problem for me in git, and may never be a problem
> for me in bzr, but I'm trying to understand *why* the help says this is
> dangerous.

git merge --no-squash

is equivalent to

bzr merge
bzr revert --forget-merges

At least, reading these docs:
http://kernel.org/pub/software/scm/git/docs/git-merge.html


  "but do not actually make a commit or move the HEAD, nor record
$GIT_DIR/MERGE_HEAD to cause the next git commit command to create a
merge commit."

Is the same as what --forget-merges does. (Consider it as removing the
MERGE_HEAD information.)

As such, you should have the same chance of conflicts, etc, as you would
in git.


The warning is that if you did:

<hack on feature1>
bzr commit -m "feature one is finally good"
cd ..
bzr branch feature1 feature2
<hack>
bzr commit -m "feature two is good, but modifies some of feature one"

cd ../trunk
bzr merge ../feature1
bzr revert --forget-merges
bzr commit -m "land feature one without history"

bzr merge ../feature2
# Probably get conflicts because the changes in trunk will not be
# superseded by the changes in feature2, even though they superseded the
# changes from feature1

However, if the plan is that you are completely getting rid of the
feature1 history anyway (and aren't basing anything else on top of it),
then you shouldn't expect problems.

The main difference is that we are being explicit that if you get rid of
the merge information, we can't use it later, and thus setting
expectations as such.

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".

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkvoXi8ACgkQJdeBCYSNAANSYACfXztG+AzSDo1cijdeG86tY27k
1YUAnjbyYtu4QdEqOUvomI4cto6otqsv
=Ljz+
-----END PGP SIGNATURE-----