[RFC] (commit --interactive) CommitTemplate

[Michael Ellerman]

On 7/31/06, Erik Bågfors <zindar at gmail.com> wrote:
> On 7/31/06, Martin Pool <mbp at canonical.com> wrote:
> > On 28 Jul 2006, Aaron Bentley <aaron.bentley at utoronto.ca> wrote:
> > > >   (**) What I would like to see someday is `bzr commit --select-hunks`,
> > > >        a-la-darcs. Kinda like shelve-commit-unshelve. Do you think it'd
> > > >        be accepted if some day... an implementation appeared?
> > >
> > > commit --select-hunks is a way of committing untested code, and there is
> > > some sentiment against doing that.  Putting it in the mainline might
> > > give the impression that we thought it was a good idea.
> >
> > I think committing untested code is generally a bad idea, but I don't
> > think we should try to stop people doing it they really want to.  Anyhow
> > they can already commit selected files, so it's only a matter of degree.

Yep.

> > darcs (I think) has a pretty clever way to handle this: when the commit
> > is prepared, it builds a temporary directory containing a copy of the
> > tree just as it will be committed, and runs a test command in there.
> > (That is to say, the temporary directory is guaranteed to be the same as
> > if you did the commit and then exported the resulting revision.)  This
> > should give good protection against selective commits.

That's a good idea, and would be nice to have even if we only allow
selective file commit, it's just as easy to create a broken commit
with selective file commit.

> I think this is perfect for a plugin to provide if it's needed.  I do
> not think that bzr itself should provide it.  I think there is a big
> difference between commiting a file (that's part of a tree) and
> commiting part of a file.

I think it should certainly start in a plugin, but I don't see any
reason it shouldn't be in the core.

Anyway, if someone's keen it'd be only a few hours work to do a proof
of concept based on the shelf code, I just haven't had time to do it.

cheers