Re: [Gnu-arch-users] [BUG] "tla commit" vs. changes

[James Blackwell]

(I have no idea who wrote this, but it wasn't me)
>     > > > IMHO it should complain that there are no changes and
>     > > > exit(-1), what it it good for generating an empty
>     > > > patch-set.  (o.k. there is a log in the patch-set but
>     > > > nothing else ;-/)
 
Miles Bader:
>     > I agree with the original poster, commit should by default err
>     > on the side of not committing (in general!).

>

Tom Lord:
> I myself sometimes make the "empty commit mistake" -- but only as an
> instance of a larger class of mistake.  The larger class of mistake is
> running `commit' in the wrong directory.  You'll see, for example,
> occaisional commits in "package-framework" with log messages that make
> it clear they were intended for "package-framework/tla" or
> "package-framework/hackerlab".
>
...

Still Tom Lord:

> So, rather than a "--force" option to commit, how about:
>
> 1) make-log should add an Archive: and Revision: header to the empty
>    log message it creates.
>
> 2) make-log should have an option which takes an argument to let you
>    set those headers.  Otherwise, it should have --seal and --fix
>    options and take those headers from the tree version.
>
> 3) commit (and other commands that want a log message) should make 
>    sure that those headers have correct values.
>
> 4) commit and friends that support a -L option (log message on the
>    command line) should also accept a -I option:
>
>       tla commit -I hackerlab -L 'fix str_cpy_n documentation'
>
>    where:
>
>       -I package      only commit if PACKAGE matches the 
>                         target package of the commit
>

I suppose this would work in many cases, particularly for projects like
tla that are using configs. 

It may not solve the problem quite as well as you may think. I suspect
that people that are commonly performing these "wrong commits" have
multiple working copies of the same version (or even revision), and
they're commiting in the wrong dir.

Isn't it obvious? If these guys are performing empty commits on
accident, then logic dictates that they don't know what they're
committing. This time it's empty, next time its debugging code, the time
after that, the permissions on their home dir were hosed and somebody
slipped in code. These sorts mistakes actually happen.

I suppose I'm being unusually cruel here, but I personally think we
should tell them to rethink. The tool isn't screwing up; *they are*.
And if we do something about this, we can only protect against the 
relatively harmless cases, and thus rob them of the learning opportunity
to learn from their mistakes before it becomes serious.

Yeah, I say we take a step back, and instead of covering the trivial
mistakes up, we go back to square one and teach them the purpose of
"what-changed"

-- 
James Blackwell
Smile more!

GnuPG (ID 06357400) AAE4 8C76 58DA 5902 761D  247A 8A55 DA73 0635 7400