RFC: supporting code review and partial commits better

[James Westby]

On Thu, 2008-07-17 at 20:53 +1000, Robert Collins wrote:
> On Thu, 2008-07-17 at 11:26 +0100, James Westby wrote:
> > 
> > For the case you mention at the end of the desire to have locally
> > modified files that will not be committed resetting the marks
> > on commit will be annoying. Is there a way we can improve this?
> 
> I don't understand - the use case I mentioned was to have no files be
> selected by default, so you need to explicitly select files to edit. Do
> you mean 'after committing something I had selected I probably still
> want it tagged' ?  In which case, if commit always resets to [selected],
> rather than to an abitrary default, this would be satisfied.

I was thinking of the case where I mark a file "do-not-commit" as it's
a local config change. However, I don't think it's a problem, as commit
would reset the marks it commits, not all marks. I was worried you
would have to mark that file after every commit.

> 
> > My immediate thought would be a way to say "the default mark
> > of these files is do-not-commit", so it seems like a file property,
> > this seems to fit in with some of the work Ian has been doing.
> 
> Ian's work gets committed to history, which does not fit with the needs
> of this at all. Its also in the working tree, which would cause special
> cases in the code. Finally its geared for files and directories - I want
> something much more granular; and hooked deep into iteration and
> selection logic of dirstate, so that filtering directories recursively
> by marks etc works well. But thats implementation :)
> 

I think it would be useful to have that though, for the "do-not-commit"
case, so that I as project maintainer can mark that file such
and it affects all users, rather than to have to tell each of them
how to do it for themselves after making the modifications. It's
certainly not an issue to block on however.

Thanks,

James