accept generated default commit message without asking

[Barry Warsaw]

When I'm using bzr to do UDD, and I make a change to the debian/changelog file, say with dch, bzr commit will copy the changelog entry into the commit message. This is great, except that if I just want to use the changelog entry exactly as given, bzr will complain that I haven't changed the commit message. This is true, but it's already fine. It would be nice if bzr commit had a command line option to suppress this complaint, or better yet, if it knew the changelog entry was fine and didn't complain at all.

[Martin Pool (mbp)]

It seems to me the underlying thing here is not especially udd-specific: if the hook generates a suggested commit message, it's reasonable for the user to just accept it without modification. Generally speaking if they exit the editor without changing it, I think we should just accept it.

(That might mean changing the apis to distinguish between "a template the user can edit" and "a message the user can possibly edit or just accept", and I guess also "just use this without running the editor at all.")

I think the main question then is what the user will do if, once they get to the editor, they decide they don't want to commit after all. The options seem to be:

1- we request confirmation (maybe defaulting to yes) before committing
2- if you delete the whole contents of the file we check that's really what you mean before committing with an empty message

I guess we could later add options to control this.

I think 2 would probably be reasonable, though perhaps not super discoverable.

[Jelmer Vernooij (jelmer)]

On Wed, 2011-01-12 at 03:56 +0000, Martin Pool wrote:
> It seems to me the underlying thing here is not especially udd-specific:
> if the hook generates a suggested commit message, it's reasonable for
> the user to just accept it without modification. Generally speaking if
> they exit the editor without changing it, I think we should just accept
> it.
>
> (That might mean changing the apis to distinguish between "a template
> the user can edit" and "a message the user can possibly edit or just
> accept", and I guess also "just use this without running the editor at
> all.")
>
> I think the main question then is what the user will do if, once they
> get to the editor, they decide they don't want to commit after all. The
> options seem to be:
>
> 1- we request confirmation (maybe defaulting to yes) before committing
> 2- if you delete the whole contents of the file we check that's really what you mean before committing with an empty message
>
> I guess we could later add options to control this.
>
> I think 2 would probably be reasonable, though perhaps not super
> discoverable.
2 would indeed probably be nicer.

Perhaps we can include a line "If you delete all contents in this file
the commit will be cancelled. " below the line:

-------------- This line and the following will be ignored
--------------

Cheers,

Jelmer

[James Westby (james-w)]

On Wed, 12 Jan 2011 03:56:33 -0000, Martin Pool <email address hidden> wrote:
> It seems to me the underlying thing here is not especially udd-specific:
> if the hook generates a suggested commit message, it's reasonable for
> the user to just accept it without modification. Generally speaking if
> they exit the editor without changing it, I think we should just accept
> it.

ISTR that I requested the confirmation be added, because of the
bzr-builddeb hook.

Before the hook simply closing the editor without saving cancelled the
commit, and after it caused the commit to go ahead.

It may just be because I was familiar with the old method (and cancel a
lot of commits when I see what --show-diff says), and new users wouldn't
find this a problem.

Thanks,

James

[Jelmer Vernooij (jelmer)]

Closing the bzr-builddeb part of this bug, as it applies to any sort of hook that provides a sensible commit message users may want to use as-is.

[Eric Siegerman (eric97)]

Martin wrote:
> 2- if you delete the whole contents of the file we check that's really what you mean before committing with an empty message

That's worse than "not super discoverable"; it violates the user's expectations. bzr has just told me "This line and the following will be ignored", but now it's "... unless you delete them all, in which case that *won't* be ignored". I much prefer the current test: "has the message file changed?"

Barry wrote:
> if [bzr commit] knew the changelog entry was fine and didn't complain at all.

Perhaps what's needed here is another hook to validate the commit message (whether the message is provided via the editor, --message, or --file). That would also be useful for projects that want to enforce a commit-message policy, e.g. that a template is fully filled out (to the limited extent that such enforcement is possible in a DVCS).

Such a message-validation hook could also subsume the API change Martin refers to, by deciding what to do if the user hasn't changed the message in the editor: commit, abort, or the current policy of asking the user.

As well, maybe the user should be able to make that choice on the command line. But then there's the question: if the hook and the command line conflict, which one wins?

[Jelmer Vernooij (jelmer)]

It would be deleting the entire delete message contents, not the bit that says "-------------- This line and the following will be ignored
--------------" and below there.