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

[Robert Widhopf-Fenk]

On Sunday, May 23, 2004 at 17:01:39, James Blackwell wrote:
> (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 ;-/)

It was me.  The guy who initially started this thread.

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

It is a stupid mistake, e.g. choosing the wrong shell, but
mankind it faulty by design!  That's why I have the
following in my .tcshrc:

set rmstar      = true
alias   mv      mv -i

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

Well go ahead and teach them, probably you have time or the
maybe the question will not rise anymore.  But, whenever one
asks that dumb question again, we will refer to you as as
teacher :c)

Here is what I did, I use xtla.el now as I am using Emacs
anyway for editing!  Had no empty commit anymore since using
it, because I do not need to switch from my editor to a
shell anymore in order to run tla commands.  Thus, there is
no way to select the wrong shell/directory by accident anymore.

Regards, 
Robert