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

[Bruce Stephens]

Oren Ben-Kiki <address@hidden> writes:

[...]

> For a prototype, sure; the best way to go about this would be to write a 
> "my-monotone-guess" script, debug & test it thoroughly as a standalone 
> tool, and then consider if/how to integrate it with monotone. Of course 
> my first choice would be to write in in Perl, not C++. Hmmm... doing it 
> in C++... Suddenly, having separate config files etc. doesn't look much 
> more attractive :-)

My point is just that for testing there doesn't seem to me to need to
be much configuration: just make it work for your projects (presumably
the files to be ignored wouldn't need to be configurable, and you know
where the monotone command is).

[...]

> Well, what happens if I create a "prepare" file, then I do something
> to the file system that invalidates it?

Well, I'd make sure that the human-written section (the log) was
separate from the automatically generated section.  Then "monotone
prepare" or whatever could just update that part of the file, and
"monotone commit" could do some kind of sanity checking.  I take your
point that if I actually wanted to omit some files, then that's more
complex.  I'm sure something could be worked out, but maybe it just
turns out to be too horrible.

[...]

> Besides, I never did believe much in the need for partial commits
> :-)

Well, no, I agree.  There are cases where one's working tree contains
unrelated changes, so some way of conveniently splitting them might
make sense.  I guess cp -r followed by a collection of "monotone
revert"s probably suffices.