commit in checkout should push existing --local commits if possible

[Dato Simó]

 affects /products/bzr

Hello.

After a discussion on the mailing list, seems that running commit in a
checkout could use the following improvement. Consider this sequence of
commands:

  % bzr init master
  % bzr checkout master slave

  % cd slave
  % echo hi >g; bzr add g; bzr commit --local -m rev1
  added g
  added g
  Committed revision 1.

  % echo hi >h; bzr add h; bzr commit -m rev2
  added h
  bzr: ERROR: Bound branch BzrBranch5('file:///tmp/b/slave/') is out of date with master branch BzrBranch5('file:///tmp/b/master/'). Either unbind, update, or pass --local to commit.

Since when running the second, non-local, commit, the current checkout
is up to date with respect its master branch, commiting revision 2 could
have been successful by previously pushing revision 1.

Thanks.

[John A Meinel (jameinel)]

I believe the reason it doesn't, is because someone else may have uncommitted some changes.

Specifically, this use case:

user-1$ bzr checkout sftp://shared/master local
user-1$ cd local
 <hack hack>
user-1$ bzr commit -m "fix bug 54321"
 <hack hack>
user-1$ bzr commit -m "remove test scripts"

user-2$ bzr checkout sftp://shared/master local-2
user-2$ cd local-2
 <hack hack>

user-1$ #What was I thinking???
user-1$ bzr uncommit

user-2$ bzr commit -m "my little fix"

At this point if we auto-pushed the changes, it would re-introduce the uncommitted revisions. Part of the problem is that there is no uncommit log, so we can't tell the difference between an uncommitted revision from user-1, and a commit --local from user 2.

Uncommit on a shared branch is a little bit risky, and if user-1 had committed a different fix right away, it would cause the branches to diverge, so auto-push wouldn't work anyway.

So I think it is reasonable to optimize for the common case of 'commit --local', and have commit push the changes if it can, rather than for uncommit, which is uncommon, and has a workaround.

It does mean we silently succeed in restoring something that was uncommitted. But a plain 'bzr push' would restore it anyway.

And optimizing for 'commit --local' also helps people who *aren't* using a shared branch, and are just publishing their changes by using checkouts.

[Robert Collins (lifeless)]

On Fri, 2006-07-21 at 15:39 +0000, John A Meinel wrote:
> I believe the reason it doesn't, is because someone else may have
> uncommitted some changes.
>
> Specifically, this use case:
>
> user-1$ bzr checkout sftp://shared/master local
> user-1$ cd local
> <hack hack>
> user-1$ bzr commit -m "fix bug 54321"
> <hack hack>
> user-1$ bzr commit -m "remove test scripts"
>
> user-2$ bzr checkout sftp://shared/master local-2
> user-2$ cd local-2
> <hack hack>
>
> user-1$ #What was I thinking???
> user-1$ bzr uncommit
>
> user-2$ bzr commit -m "my little fix"
>
> At this point if we auto-pushed the changes, it would re-introduce the
> uncommitted revisions. Part of the problem is that there is no uncommit
> log, so we can't tell the difference between an uncommitted revision
> from user-1, and a commit --local from user 2.
>
> Uncommit on a shared branch is a little bit risky, and if user-1 had
> committed a different fix right away, it would cause the branches to
> diverge, so auto-push wouldn't work anyway.
>
> So I think it is reasonable to optimize for the common case of 'commit
> --local', and have commit push the changes if it can, rather than for
> uncommit, which is uncommon, and has a workaround.
>
> It does mean we silently succeed in restoring something that was
> uncommitted. But a plain 'bzr push' would restore it anyway.
>
> And optimizing for 'commit --local' also helps people who *aren't* using
> a shared branch, and are just publishing their changes by using
> checkouts.

I dont think the uncommit interaction described here is at all bad -
uncommit is defined as 'pretend that commit didn't happen *on this
branch*', not as 'pretend it never happened'. An as long as we
articulate this clearly in user documentation, the implications should
be clear to users.

Rob
--
GPG key available at: <http://www.robertcollins.net/keys.txt>.