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

[Tom Lord]

    > From: Miles Bader <address@hidden>

    > On Thu, May 13, 2004 at 02:51:52PM -0400, James Blackwell wrote:
    > > > 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 ;-/)

    > > Not so. :) 
    > > Here's two reasons: 

    > Those are easily handled with an option to force a commit even when there
    > are no changes (ala CVS), e.g., --force.

    > I agree with the original poster, commit should by default err
    > on the side of not committing (in general!).

It's just a rule of thumb (with definate exceptions) but I have an
aversion to "--force" options.

Consider, for example, what they do to scripts:  a script must either
always use "--force" or test for the condition under which --force is
needed.  

If it always uses "--force" then the protections supposedly offered by
the flag are negated.

If it tests for whether "--force" is needed, then the protections
supposedly offered by the flag are redundent.

So this is an area in which the needs of interactive and scripting use
are seemingly in conflict.

I live with "--force" options for things like "register-archive" or
"my-id".  My feeling is that nearly all interactive uses _and_
scripting uses will want to use these commands _without_ "--force".
Any resulting errors are likely to indicate a bug in the script or in
the user's command.

But commit is different and becoming more different.  I think that
"empty" (i.e., log-message-only) commits are not going to be that rare
in the long run, especially as things like pqm and bug goo become more
established.  "--force" is going to just get in the way of both
scripting _and_ interactive use.

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".

The empty changeset test isn't sufficient to fix that mistake.
Sometimes the particular wrong-directory I'm in _has_ been modified.

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

   E.g., the above command line will commit happily to these:

         hackerlab--devo--1.0
         hackerlab--unicode--1.0

   and this command:

      tla commit -I hackerlab--unicode -L 'fix str_cpy_n documentation'

   will commit to 

         hackerlab--unicode--1.0

   but not 

         hackerlab--devo--1.0

   and neither of those commands will commit to

         package-framework--devo--1.0


-t