Bazaar

How to uncommit a local commit ?

Asked by Alexandre Garnier

The problem is with uncommit after update (uncommit should be avoided on shared branch but it's not easy to educate some developers...)
Here is an example :

user-1$ bzr co branch checkout
<hack>
user-1$ bzr ci -m "my nice work"

user-2$ bzr co branch checkout
<hack>
user-2$ bzr ci -m "my bad work"

user-1$ bzr up
<hack>

user-2$ bzr uncommit

user-1$ bzr up
Your local commits will now show as pending merges with 'bzr status', and can be committed with 'bzr commit'.

At this point, user-1 have his work mixed with the uncommited work.

Is there a way to revert the uncommited revision without reverting current work ?
When using global revert, it revert everything.
When using revert with the revid of the uncommited revision, it just remove the pending merge but not the changes.

A solution would be to shelve current work before each update with extra revision from missing, but it can be painful and there is not always a check of missing before updating.

The problem is not there with lightweight checkouts : when updating after a uncommit, the uncommited changes are reverted but not the local changes (and you get conflicts if needed).

Question information

Language:
English Edit question
Status:
Solved
For:
Bazaar Edit question
Assignee:
No assignee Edit question
Solved by:
John A Meinel
Solved:
Last query:
Last reply:
Revision history for this message
John A Meinel (jameinel) said : 		#1

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

Alexandre Garnier wrote:
> Question #118191 on Bazaar changed:
> https://answers.edge.launchpad.net/bzr/+question/118191
>
> Description changed to:
> The problem is with uncommit after update (uncommit should be avoided on shared branch but it's not easy to educate some developers...)
> Here is an example :
>
> user-1$ bzr co branch checkout
> <hack>
> user-1$ bzr ci -m "my nice work"

...

> A solution would be to shelve current work before each update with extra
> revision from missing, but it can be painful and there is not always a
> check of missing before updating.
>
> The problem is not there with lightweight checkouts : when updating
> after a uncommit, the uncommited changes are reverted but not the local
> changes (and you get conflicts if needed).
>

bzr merge . -r -1..-2 --force

Will also apply the reverse of the last patch. You could use:

bzr merge . -r XXX..before:XXX --force

And take the "XXX" from the message given by uncommit. (revid:....).

It is a bit clumsy, but it should work.

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

iEYEARECAAYFAkxEJCYACgkQJdeBCYSNAAOIBQCeOYEGsG8slLnDWzOyv3877Uq8
n98AoKqh3cYw0uz8pooZKbiO8JynV1dr
=f6tx
-----END PGP SIGNATURE-----

Revision history for this message
John A Meinel (jameinel) said : 		#2

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

> The problem is not there with lightweight checkouts : when updating
> after a uncommit, the uncommited changes are reverted but not the local
> changes (and you get conflicts if needed).
>

Well, the problem is not there because lightweight checkouts *cannot*
have locall commits.

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

iEYEARECAAYFAkxEJF0ACgkQJdeBCYSNAAPcZQCeJsXu4omQUn81q5ebv1OPTJp+
nS4AoLsbgCuXykNTPBJ88UMqOn8u1yAG
=52IX
-----END PGP SIGNATURE-----

Revision history for this message
Alexandre Garnier (zigarn) said : 		#3

OK, I haven't think about reverse cherrypicking, just revert

2 other questions, then :
* how to get the uncommited revision revid from user-1 side (without asking to user-2) ? I don't find how to get it from 'log' (but have it in 'qlog') and it is not visible in 'status'
* why saving the uncommited revision in local commit ?

Revision history for this message
Best John A Meinel (jameinel) said : 		#4

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

Alexandre Garnier wrote:
> Question #118191 on Bazaar changed:
> https://answers.edge.launchpad.net/bzr/+question/118191
>
> Status: Answered => Open
>
> Alexandre Garnier is still having a problem:
> OK, I haven't think about reverse cherrypicking, just revert
>
> 2 other questions, then :
> * how to get the uncommited revision revid from user-1 side (without asking to user-2) ? I don't find how to get it from 'log' (but have it in 'qlog') and it is not visible in 'status'
> * why saving the uncommited revision in local commit ?
>

If this is a continuation on the discussion about uncommitting public
revisions, this sort of fallout is why uncommitting public revs is
highly discouraged.

If you just want the changes backed out, doing:

 cd $public_checkout
 bzr revert -r -2
 bzr commit -m "back out the last revs changes"

is going to work much better with everyone than doing:

 bzr uncommit

Obviously the changes *have* been made available to others, otherwise
they wouldn't have a seeming "local" change when they update.

If you want to propagate uncommits, then doing:
 bzr pull --overwrite :bound

will do equivalent to 'bzr up' but will always throw away divergence
(should leave uncommitted changes alone).

John
=:->

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

iEYEARECAAYFAkxELe4ACgkQJdeBCYSNAAPnqQCgtemNeu576WgEACCfIeKGxfhE
K8cAnjml4M8BWCWrZ5ZC9hH1C4ACrM49
=rACm
-----END PGP SIGNATURE-----

Revision history for this message
Alexandre Garnier (zigarn) said : 		#5

I know it's better to commit reverse than uncommit on shared branches.
But some developers think it's to complicated (2 commands, ...). I'll find a way to deactivate the uncommit.

We work with a centralized workflow and I'm trying to migrate from lightweight checkout to normal checkout to minimize network traffic and improve performances. So I found this difference between the 2 checkout modes (with also #606327, for wich I haven't think of ':bound')

The pull method is good but need to know when to use it and not just a 'bzr up'

Revision history for this message
Alexandre Garnier (zigarn) said : 		#6

Thanks John A Meinel, that solved my question.

Revision history for this message
John A Meinel (jameinel) said : 		#7

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

Alexandre Garnier wrote:
> Question #118191 on Bazaar changed:
> https://answers.edge.launchpad.net/bzr/+question/118191
>
> Alexandre Garnier confirmed that the question is solved:
> Thanks John A Meinel, that solved my question.
>

If you set 'append_revisions_only = True' on your trunk branch, then you
can effectively prevent them from uncommitting something on the branch
that has already been made public.

John
=:->

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

iEYEARECAAYFAkxETocACgkQJdeBCYSNAANP3wCgmd+gwMu2ETsC0LAcHBnw/o2V
cGAAoJ9kGZ9pCFx2oJmjrpVzNaBca0/D
=99F8
-----END PGP SIGNATURE-----

Revision history for this message
Alexandre Garnier (zigarn) said : 		#8

Thank you for this trick.

Too bad that this option is not propagated to sub branches of shared repository