Prevent accidents with commit messages

[Jeroen T. Vermeulen]

Sometimes with bzr (and other revision control systems) I have little accidents:

$ bzr commit -m src/foo.c -m "Dobnialicate the shingle."
modified:
  doc/README.txt
  include/bar.h
  src/foo.c

Argh! I committed stuff I didn't mean to, and probably with a nonsensical message.

The fault is mine, and it'd be hard (though probably not impossible) to catch all mistakes of this type. Still, wouldn't it make more sense to error out when -m is specified more than once on one command line?

[John A Meinel (jameinel)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jeroen T. Vermeulen wrote:
> Public bug reported:
>
> Sometimes with bzr (and other revision control systems) I have little
> accidents:
>
> $ bzr commit -m src/foo.c -m "Dobnialicate the shingle."
> modified:
> doc/README.txt
> include/bar.h
> src/foo.c
>
> Argh! I committed stuff I didn't mean to, and probably with a
> nonsensical message.
>
> The fault is mine, and it'd be hard (though probably not impossible) to
> catch all mistakes of this type. Still, wouldn't it make more sense to
> error out when -m is specified more than once on one command line?
>
> ** Affects: bzr
> Importance: Undecided
> Status: New
>

You can always "bzr uncommit" right after...

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxg/osACgkQJdeBCYSNAAPlqwCfe+s+MFyNXUf2EazQiWyzxIdD
sPUAoIfOSkEzTWs22JhULbLDblRlkswb
=iDES
-----END PGP SIGNATURE-----

[Robert Collins (lifeless)]

We could catch that yes.

Are you aware that you can just 'bzr uncommit' to undo it too ?

[Jeroen T. Vermeulen (jtv)]

I can "bzr uncommit" the commit if I notice it it in time. What worries me is: if I notice it from time to time, how often does it happen without my noticing? I would normally expect insane command-line parameters to error out.

[Jelmer Vernooij (jelmer)]

On Tue, 2010-08-10 at 07:13 +0000, Jeroen T. Vermeulen wrote:
> Public bug reported:
>
> Sometimes with bzr (and other revision control systems) I have little
> accidents:
>
> $ bzr commit -m src/foo.c -m "Dobnialicate the shingle."
> modified:
> doc/README.txt
> include/bar.h
> src/foo.c
>
> Argh! I committed stuff I didn't mean to, and probably with a
> nonsensical message.
>
> The fault is mine, and it'd be hard (though probably not impossible) to
> catch all mistakes of this type. Still, wouldn't it make more sense to
> error out when -m is specified more than once on one command line?
FWIW Subversion disallows commits that have a commit message that
matches an existing file path, and it really annoys me.

("svn add foo; svn ci -m foo")

Detecting duplicate -m arguments seems reasonable, though.

Cheers,

Jelmer

[John A Meinel (jameinel)]

In general, I don't think we want to detect duplicate arguments, mostly because of the aliasing system. (For example I have log=log --short -r-10..-1, but it is nice to override that with a new -r option).

We could, I suppose, determine whether the duplication comes from an alias or not, though if someone uses a different scripting method we wouldn't detect that.

Helping people from making mistakes is nice to do if we can do it tastefully.

[Martin Pool (mbp)]

We do actually give you a warning if the message is the name of a
file. Perhaps we should have a general warning->silence,warning,error
map for users to set...