Re: [Monotone-devel] Command design and naming?

[Thomas Moschny]

On Friday 23 February 2007, William Uther wrote:
> C: For update:    mtn pull branch && mtn merge && mtn update

You may want to take into account that there might be users that don't have 
write access to the projects central server(s). So, 'automatic' merge might 
produce a revisions that will only exist locally, but never travel to the 
central repo. Not sure whether that is a real problem, though.

But you are of course right with your observation that one often has to type
'mtn pull && mtn update'. So what about having a --pull switch for update that 
uses the default arguments of the last pull?

The update will of course abort if there are multiple branch heads, leaving 
the user with two commands to type in that case: mtn merge && mtn update.

> B: For commit:    mtn commit && mtn pull branch && mtn merge 
>                   && mtn push branch

Here again, reservations against such an 'automatic' merge, albeit for an 
other reason: People might want to (or should I say: they *should*) review 
the result of a merge before pushing.

However, similar to the proposal above, I'd like to see a --push option for 
commit. Note that it can even push when we created divergence, so the current 
user is not bothered with the merge.

That's an important point anyway: Merging is simple (and thus automatic) in 
many cases, but it may not sometimes. And I don't want to be forced to do a 
merge when I don't know how. This might be a big project, and I worked on 
parts of it far away of the conflicting parts.

Regards,
Thomas

-- 
Thomas Moschny  <address@hidden>

pgpieXdHF8DT4.pgp
Description: PGP signature