cherrypick or merge - the undo
> will propogate."
>
> I.e. how does a commit of the results of "bzr revert -r X" differ from a
> commit of the results of "bzr merge -r -1..X"?
In current bzr, not at all.
I
k, but bzr does not consider this a cherrypick or merge - the undo
will propogate."
I.e. how does a commit of the results of "bzr revert -r X" differ from a
commit of the results of "bzr merge -r -1..X"?
Regards
Henrik
On Tue, 2008-03-25 at 13:04 +0100, Henrik Nordstrom wrote:
> On Tue, 2008-03-25 at 12:04 +1100, Robert Collins wrote:
>
> > 'bzr revert' changes the working tree to be the same as a given revision
> > [with optional file list].
> > If you then do a commit - e.g:
On Tue, 2008-03-25 at 12:04 +1100, Robert Collins wrote:
> 'bzr revert' changes the working tree to be the same as a given revision
> [with optional file list].
> If you then do a commit - e.g:
> bzr revert -r X
> bzr commit
> you are committing a changeset that happ
On Tue, 2008-03-25 at 10:34 +1300, Amos Jeffries wrote:
> Robert & Henrik,
>
> Some of us have found a knowledge-hole in the bzr revert process.
>
> We can easily reverse a patch using for example:
> bzr revert -r 8902
I prefer using merge.
bzr merge -r 8903..8902
On Tue, 2008-03-25 at 10:34 +1300, Amos Jeffries wrote:
> Robert & Henrik,
>
> Some of us have found a knowledge-hole in the bzr revert process.
>
> We can easily reverse a patch using for example:
> bzr revert -r 8902
>
> But then when its fixed we don
Robert & Henrik,
Some of us have found a knowledge-hole in the bzr revert process.
We can easily reverse a patch using for example:
bzr revert -r 8902
But then when its fixed we don't know how to undo the undo.
The local branch is left with code apparently up-to-date but is
