how to revert update operation

[Adeodato Simó]

* Robert Collins [Thu, 20 Jul 2006 12:09:39 +1000]:

> > > But the goal statement is still identical:
> > >  - set your basis to be the tip of the master
> > >  - turn all your local changes into a merge into the master
> >                                  ^^^^^^^^^^^^

> > Maybe this sounds stupid, but why that? Is just it can't be implemented
> > in other way, or don't you agree that users would expect/like just
> > having their commits "pushed" (instead of merged) after upgrading to the
> > tip of master? (Though I don't know how/when would one handle
> > conflicts.)

> > Just curious.

> It would be *extremely* surprising to users if 'update' were to change
> the master branch.

Oops, seems I failed to make myself understood. Just to be clear, I
didn't mean that update pushed anything to the master branch, no, but
that it'd left the checkout in a state where changes can be pushed into
the master branch, instead of _merged into_ the master branch.

That is, person Joe does:

  % bzr co something
  (updated to version 1)

  (hack)
  % bzr ci --local -m 'changing file X' # rev. 2

  (hack)
  % bzr ci --local -m 'changing file Y' # rev. 3

  % bzr push                      <-- Point A
  E: branches have diverged

  % bzr update
  (gets from master rev. 2 by person John, that changes file Z)

  % bzr push
  (pushes changes to files X and Y as rev. 3 and 4, respectively)

My guess was that it isn't implemented that way because it isn't
possible to, but I wanted to be sure, hence my "just curious" above.

                                 * * *

Now for some different issue: it is my impression that many users would
instinctively try 'bzr commit' instead of 'bzr push' in the line marked with
"Point A" above. Currently, "bzr commit" in that situation gives a "branches
have diverged error". I think it'd be good to improve the error. However, I
guess it's difficult to change that until this gets fixed
(builtins/cmd_commit):

    except PointlessCommit:
        # FIXME: This should really happen before the file is read in;
        # perhaps prepare the commit; get the message; then actually commit
        raise BzrCommandError("no changes to commit."
                              " use --unchanged to commit anyhow")

I can open a bug about this issue if you think it'd get eventually changed.

Cheers,

-- 
Adeodato Simó                                     dato at net.com.org.es
Debian Developer                                  adeodato at debian.org
 
«Ara que ets la meva dona, te la fotré fins a la melsa, bacona!»
                -- Terenci Moix, “Chulas y famosas”