[Extension] Dirty hack of 'shelve' and 'unshelve' command

[Aaron Bentley]

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

Erik Bågfors wrote:
| On 5/19/05, Aaron Bentley <aaron.bentley at utoronto.ca> wrote:
|>Erik Bågfors wrote:
|>| I think this is very useful. But I'd love to also see a "bzr commit
|>| --interactive" or something like that, that would let the user select
|>| the hunks he likes to commit.
|>
|>This idea really bothers me, and has since I heard about per-hunk commit
|>in Darcs.  Committing selected hunks that may make no sense out of
|>context, with no opportunity for review, and only one chance to get it
|>right?  How is that better than typing one extra command?
|
|
| What do you mean with "no opportunity for review" and "only one chance
| to get it right"?

By "no opportunity for review", I meant that you have a fairly limited
interactive session (accepting or rejecting each hunk) that can end
either by committing, or by aborting.

If you reduce the limitations, it becomes more and more like a shell
session.  And once there's a chance to review what's being committed,
and once you're prompted to commit, you've got all the disadvantages of
the shelve/commit model, but not all the advantages.  (e.g. you can't
run your editor to tweak something.)

| You can always back out. Either by doing it the
| darcs way and having a unrecord/uncommit command or simple reverting
| what you did.

That's true.  Old Arch thinking there.  It is safe to delete revisions
in the bzr model, but not in Arch.

|> So what am I missing?
|
|
| Lot's of time you
| do many small changes and they do make sense individualy.  Basically,
| I have been working on this thing for one hour, so I have lot's of
| things to check in. Then a collegue comes in and says "can you change
| this default value to 10 instead of 15".  That's a one line change.
| You can then do that change in the code you are in, and commit that
| change.  Then get on with what you are doing. The other way to do
| that, would be to create a new checkout/branch, do the change there,
| get back to what you were doing.

I'm not advocating that approach, just a two-step "shelve/commit".

I can appreciate that doing one-liners and just committing those is
good.  It's the doing it in one step that bothers me.  But
checkout/branch isn't the only alternative.  With tla, you can do

$ tla undo
$ $EDITOR 'default-val-file'
$ tla commit -s "changed default value to 10"
$ tla redo

With fai, you can do
$ $EDITOR 'default-val-file'
$ fai revert --hunks
$ fai commit
$ fai redo

With shelve and a shelf-aware commit, you have
$ $EDITOR 'default-val-file'
$ bzr shelve
$ bzr commit -m "changed default value to 10"

But what's nice about shelve is you can do anything you want between
shelve and commit, including 'bzr diff' and '$EDITOR'.

| The next this is that going trough each hunk is acctually itself a
| VERY good way to review what you did

Yes, I've found that, too.

| What I noticed was that I often
| did more than one thing. So I should really do more than one checkin.
| Darcs makes that easy for me.

Sure, but if you're going to follow that principle, it's good to make
sure that the first change really is independent of the second.

| ps. Anyway, this is what's so great about plugins, even if you and
| martin don't want it, someone else might want it and create a plugin.

I do want plugins.  I want to have plugins that are native Python
extensions, and if other people want to develop non-native plugins in
bash/Perl/C, I won't try to stop them.

Anyhow, thanks for sharing your POV.  I do understand it better now.

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

iD8DBQFCjQHs0F+nu1YWqI0RArZeAJ9EeNVsuRP1Yv1qw1aCwvZXTjoD6wCfdq9k
aKi4k5Znd3G0MJ/bv3oofDY=
=BqhI
-----END PGP SIGNATURE-----