uncommit and bound branches

[Aaron Bentley]

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

Robert Collins wrote:
| On Thu, 2006-03-30 at 11:53 -0500, Aaron Bentley wrote:

|>Even in the shared-branch case, there should
|>be a better way of handling it.
|
|
| Thats what I was suggesting uncommit --local for.

Uncommit --local sounds like the opposite of what I consider ideal.
Really, I want an uncommit that uncommits it from the other developers'
branches, too.  I don't want it being accidentally resurrected.

Note that "want" here != "consider feasible"

But it probably *is* feasible to distinguish between these scenarios:

Scenario 1
==========
Alice does commit --local.  Alice's branch is now newer than the master.

Scenario 2
==========
Alice is up-to-date with the master.  Bob uncommits some revisions from
the master.  Alice's branch is now newer than the master.

In Scenario 1, the tool should help Alice get her commits into the
master.  In Scenario 2, it should help Alice pull --overwrite to get in
sync with the master.

| There are several states and action combinations:
|  A tip of the local branch == tip of master branch, uncommit locally
|    useful to allow committing a working-in-progress but continuing to
|    work on it in more detail locally. Not -very- useful, but useful.
|  B tip of the local branch == tip of master branch, uncommit both.
|  C tip of the local branch == tip of master branch, uncommit master
| only. (makes the local tip something that a full commit, or a push, will
| push into the master)
|  D tip of the local branch is on the master branch history, but not the
| tip of the master, uncommit locally
|    same basic case as A
|  E tip of the local branch is on the master branch history, but not the
| tip of the master, uncommit both
|    this appears to be hard to control
|  F tip of the local branch is on the master branch history, but not the
| tip of the master, uncommit master only
|    this could be useful, if only to back out something someone else did
| to a shared branch without pulling it down locally first.
|  G tip of the local branch is not on the master branch history, uncommit
| locally
|    definately useful when using 'commit --local'.
|  H tip of the local branch is not on the master branch history, uncommit
| both
|    seems hard to control again,
|  I tip of the local branch is not on the master branch history, uncommit
| master only
|    looks like case F again.
|
| So - what cases should we support, and how should the user specify which
| one they want?

I can see B & F being useful, dunno about A/D, but I wouldn't fight it.
~ Anything where the local branch is newer than the master is
questionable, because uncommit works best on freshly-committed
revisions.  Anything that makes the local branch newer than the master
is questionable, because it's odd to uncommit something that you plan to
continue working on.

I can't see using C, E, H, I.  The uses for G can probably be solved
with pull --overwrite.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFELJJl0F+nu1YWqI0RAoQbAJ9CwZXWV/QdNUTHaT0TrHz2lxSi0ACeOYSh
wZBTW2WONymih5Wz6XXu7Ug=
=zKgu
-----END PGP SIGNATURE-----