[Monotone-devel] Re: Cherry-Picking, Renames, Etc.

[Bruce Stephens]

Oren Ben-Kiki <address@hidden> writes:

> On Monday 29 November 2004 19:53, Bruce Stephens wrote:
>> Why not just have the things independent of monotone?  So you run
>> monotone_guess before committing, or something?
>
> Because I'd need a separate "infrastructure" (config files, paths, 
> environment variables...).

What does it need to know?  You run it in the top level of a project,
and it looks at the files underneath.  Oh, I guess it might want to
know about ignorable files (which is configurable).  And it would need
to know the path of monotone, I suppose.  OK.  But for a prototype (to
see whether the idea actually makes a significant difference) you
could hack something that worked for you (and would work for other
people with minor modifications), I'd have thought.

[...]

>> More philosophically, it would return control to me.  Right now
>> commit drives everything: it decides what files it thinks need to be
>> committed, it throws me into an editor to construct the long log
>> message.  (It's no different to other systems in this respect as far
>> as I know, and normally this is what you want, but I'd like a
>> user-driven alternative sometimes.)
>
> Actually, most other systems allow you to specify that you only
> commit some of the files.

I know, and there's a monotone branch somewhere which allowed this,
too (I'm not sure whether the changes have been merged in yet).  But
they all seem a little awkward or limited to me: they let you commit
all changed files in a subtree, or let you list the files you want to
commit.  Both useful things, of course, and probably you want to make
those especially easy.  I'm just surprised that they don't separate
out the thing in the way I suggested, and then you can make the common
cases easy in a clean way.  However, I've never written a version
control system, so it's quite possible I'm missing some difficulty.