RFC: supporting code review and partial commits better

[James Westby]

On Thu, 2008-07-17 at 19:26 +1000, Robert Collins wrote:
> This is about a feature we're missing; how to do it tastefully from the
> UI, and possibly some implementation thoughts. Jelmer, James Westby,
> Daniel Watkins and I are sprinting in London - we've sketched some very
> high level concepts - please read this and give us feedback!
> 

This is the result of a discussion yesterday that looked at the
git index, and the things that people want to do with it. There
are two main things that people use it for. The first is excluding
some parts of the current tree state from diff, so that they don't
have to keep reading them if they are happy with the changes. The
second is committing something that is different from the state
on disk, committing a quick bug fix that you noticed while working
on a feature. It also gives some nice things, such as the equivalent
of interactive commit.

We took these use cases and worked out if there was a way to get
them that fit in well with bzr, and didn't cause confusion in the
same way as the index. In particular Rob was very clear that he
thought that git has the defaults the wrong way around, and with
diff and commit showing different things by default it is too easy
for the user to make a mistake.

> revert and commit will clear marks back to
> the default ([selected]).

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?

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.

> A further feature some folk request is the ability to specify that only
> some files are being edited. By having a configuration option to toggle
> the default mark from [selected] to [], commit, diff, status etc would
> all ignore all changes in the tree and need explicit instruction to
> examine a file. We could add to tree building operations a check for
> 'selected' in the taglist - and if its not present make the files
> readonly.

This use didn't come up yesterday, so it's good to see that the system
is useful, and we can get some extra mileage out of it.

I'm interested in feedback from others, does anyone see any problems
with this? Would it work for what you want to get out of bzr? Any
other uses that it could be put to?

Idea #176 we had while talking about this: make a test runner that
uses coverage information to add a "fails-tests" mark on any modified
hunk that is exercised during the run of a failing test cases, so
that "bzr diff -M=fails-tests" shows those changes implicated in
the problem.

Thanks,

James