gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] "tla commit" generates a patch-set even if there ar


From: Tom Lord
Subject: Re: [Gnu-arch-users] "tla commit" generates a patch-set even if there are no changes
Date: Fri, 14 May 2004 09:48:56 -0700 (PDT)


    > From: address@hidden (Julian T. J. Midgley)

    > Aaron Bentley  <address@hidden> wrote:
    > >The harm comes from changing the default behavior.  I have scripts that 
    > >I run from cron that would be broken by that change.  tla isn't very 
    > >user-friendly.  Scripts can make it smoother.  Let's not make tla 
    > >script-unfriendly too.

    > A little disingenuity is in danger of creeping in here.  

No, a little wisdon.

    > tla with a "--force" option to commit would be no more or less
    > "script-unfriendly" than it is now.

It would, actually.  Scripts would have unchanged behavior only if
they add the "--force" option everywhere.  That has two drawbacks:

1) the script is harder to maintain -- people have to remember not to
   forget to add --force when writing or revising commit commands.

2) What does "--force" mean, exactly?  Today it would mean "permit
   log-only commits" but tomorrow it might also mean "permit empty log
   commits" and the day after that it might also mean "permit commits
   even if unrecognized files are present" and the day after that it
   might mean "automatically break the revision lock, if necessary",
   etc.

   We could try to solve this by getting all GCC-like and adding
   sub-options:

        '--force-condition=(empty-logs,no-changes)'

   but, geeze, really?

Keep it simple and consistent.

Meanwhile, I think most of the underlying problem of spurious commits
would be solved by the new log-file features I mentioned a few
messages ago in this thread.


    > In arguing against the proposed change, you appear to be putting some
    > inconvenience to yourself (and others with similar scripts) now ahead
    > of the annoyance caused by a poorly chosen default to the thousands of
    > developers who start to use tla in the future.

I'll raise a yellow card there on the rhetoric:  unsubstantiated
(i.e., made-up) statistics combined with an ad hominem attack.


    > Sometimes, I admit, network effects can be so great that an otherwise
    > sensible change cannot be made for the difficulty it would cause
    > elsewhere

Depending on what exactly you mean by "network effects" -- yes, i
think that's about right.

You have to analyze the costs of changes like this with imperfect
knowledge --- future impacts are hard to consider.  That's one of the
larger reasons we K.I.S.S. and aim for simple consistency whenever we
can.




    >  - it seems, this early in tla's life, however, that that point
    > hasn't yet been reached, and it would be a pity to avoid
    > smoothing off the odd rough edge before tla achieves the
    > ubiquity of CVS for the sake of avoiding inconvenience to the
    > early adopters.

Have you stopped beating your wife?

(And, btw, it's no longer "early" in tla's life.)


-t





reply via email to

[Prev in Thread] Current Thread [Next in Thread]