Re: [Monotone-devel] Re: [PATCH] mtn commit without -b and mtn branch

[Zack Weinberg]

On 3/8/07, Nathaniel Smith <address@hidden> wrote:
> "commit -b" is problematic UI (and the source of numerous complaints)
> because it gives you exactly one moment in which you have the
> opportunity to switch branches; if your attention wanders while
> committing, then you lose.  A _lot_ of people have said in the past
> that in fact they never use 'commit -b', they just munge _MTN/options
> by hand (and actually, I do this too).  So the idea of 'mtn branch'
> would be that it lets everyone use this workflow, not just the overly
> clever people.

I'm another of these people who munges _MTN/options by hand, and I do
it precisely because I _have_ forgotten to give a -b option to commit
in the past.  It's much more natural (for me anyway) to set the
"eventual branch to which this will be committed" when I am setting up
a new checkout.

I just noticed (again) a related UI problem, so I thought I should
point it out in this thread.  If you have munged a nonexistent branch
name into _MTN/options and you run "update" in that workspace, you get
a long scary error message about how the branch selection doesn't
match any descendants of the current revision, in fact it doesn't even
match the current revision, perhaps you wanted -rh:foo?  (Where foo is
the nonexistent branch name.)  This is bad UI on three counts.  First
off, the well known nonequivalence between (implicit) -b foo and
-rh:foo, wtf?  The difference has been explained to me several times
and I just cannot retain it, which IMAO means there's a problem with
making them different.  Second off, it should not be advising -rh:foo
when it knows (or should know) that that won't do anything useful
either because there is no 'foo' branch cert in the database.

And third ... what I actually *want* update to do in that circumstance
is update to the head of the branch that *would* be in _MTN/options if
I hadn't gone and munged it.  I do this when I have set up a working
copy but then not had time to make any actual changes, so it's silly
not to be working off the latest revision in n.v.m.  I can force an
update with -rh:n.v.m but then I have to go munge _MTN/options again.

zw