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

[Bug Goo]

Created as bug 114

On Fri May 14 16:41:23 2004, Tom Lord wrote:
> 
> 
>     > 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
> 
> 
> 
> _______________________________________________
> Gnu-arch-users mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gnu-arch-users
> 
> GNU arch home page:
> http://savannah.gnu.org/projects/gnu-arch/
>