Lapo Luchini <[EMAIL PROTECTED]> writes:
[...]
> Of course, those are problems that can (and probably should) be solved
> by a GUI with colored diff and a mouse interface to "click to deselect
> chunks" or something like that ;-)
That's the kind of thing git-gui offers, yes.
> But well... not strictly related, but if I continue that "colored diff"
> branch of mine... stretching the idea (MUCH) further... in an ideal
> world we could:
> a) mtn commit --interactive
> b) an index like "mtn status" is shown
> c) you can move around with arrows and hit enter to see the (colored)
> diff of the specific file
> d) move around with arrows and select/deselect chunks
> e) press ESC to return to the index, seeing now the list decorated with
> something like ("filename changed [2/6 chunks selected]")
> f) confirm the commit, write the commit log, actually commit it
I must admit this is the kind of thing that sold me on git.
Part of it is this staging area (called "the index", presumably for
histerical raisins). So you ordinarily construct the tree you want to
commit incrementally, and while you're doing that you can add and
remove changes from it.
Further, in git it's normal to discard stuff, so revising work is
natural: you just record a variant of what's already committed,
discarding the original. So probably a difference in philosophy as
much as in technology.
No reason monotone couldn't get some kind of a staging area, I'd have
thought. Indeed, maybe _MTN/revision is almost such a thing?
Couldn't one have a "mtn add-change ..." which added stuff to the
database, created an updated manifest, and modified _MTN/revision, and
then garbage collect at some point (or just not bother, since netsync
can get rid of it)?
_______________________________________________
Monotone-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/monotone-devel
