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 <[EMAIL PROTECTED]>
pgpoKhBs7CP3y.pgp
Description: PGP signature
_______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
