[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Re: [PATCH] mtn commit without -b and mtn branch
From: |
Zack Weinberg |
Subject: |
Re: [Monotone-devel] Re: [PATCH] mtn commit without -b and mtn branch |
Date: |
Fri, 9 Mar 2007 10:28:39 -0800 |
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
- Re: [Monotone-devel] [PATCH] mtn commit without -b and mtn branch, (continued)
- Re: [Monotone-devel] [PATCH] mtn commit without -b and mtn branch, Thomas Keller, 2007/03/08
- [Monotone-devel] Re: [PATCH] mtn commit without -b and mtn branch, Bruce Stephens, 2007/03/08
- [Monotone-devel] Re: [PATCH] mtn commit without -b and mtn branch, Steven E. Harris, 2007/03/08
- [Monotone-devel] Re: [PATCH] mtn commit without -b and mtn branch, Bruce Stephens, 2007/03/08
- Re: [Monotone-devel] Re: [PATCH] mtn commit without -b and mtn branch, Nathaniel Smith, 2007/03/08
- [Monotone-devel] Re: [PATCH] mtn commit without -b and mtn branch, Bruce Stephens, 2007/03/08
- [Monotone-devel] Re: [PATCH] mtn commit without -b and mtn branch, Steven E. Harris, 2007/03/09
- Re: [Monotone-devel] Re: [PATCH] mtn commit without -b and mtn branch,
Zack Weinberg <=
- Re: [Monotone-devel] Re: [PATCH] mtn commit without -b and mtn branch, Thomas Keller, 2007/03/10
- Re: [Monotone-devel] Re: [PATCH] mtn commit without -b and mtn branch, Thomas Keller, 2007/03/26