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

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

Re: [Gnu-arch-users] Re: fixing and extending "selected commit"


From: Miles Bader
Subject: Re: [Gnu-arch-users] Re: fixing and extending "selected commit"
Date: Sat, 4 Oct 2003 19:35:25 -0400
User-agent: Mutt/1.3.28i

On Sat, Oct 04, 2003 at 10:16:03AM -0700, Robert Anderson wrote:
> No, "you" is the user of tla.  Are you really missing this point
> wholesale?  I find that hard to believe.

Perhaps you're doing a very bad job of making it...

> In my opinion, there should be an invariant for commit/get pairs: that
> any tree that is created with "get" must be a tree that existed when a
> "commit" command was given.

OK, that's your opinion.  Personally, I think that's a reasonable way of
operating generally, but it would be silly and pedantic to use tla to try to
enforce the notion.  I am a good programmer.  I _know_ when it's appropriate
to do more or less testing.  tla is a tool; it should let _me_ make the
decisions.

[An obvious example: correct a spelling error in a README file.  Want to
commit it without other stuff in the tree.  Chance of commit causing
problems: 0.01% (it's never zero, of course).  Annoyance at having to use
roundabout methods to commit because tla is trying to enforce Robert's Rules
of Good Programming: High.]

> But what I am saying is that it is definitely a bad thing to have that
> be the ONLY option.

What on earth does _that_ mean?  You can always _not use_ restricted commits.
Whoo, simple!  If you don't trust yourself (or your co-workers) to do that,
you can use the theorized pre-commit hook to abort commits with a limit.

If there's a desire to add some automatic way of generating a coherent tree
for a (theoretical) pre-commit hook to use for test, several reasonably
efficient methods have been suggested, but my impression from your message is
that you want something more:

> And that would suck.  If we're going to have one way to do it, it ought to
> be the way that enables good habits, not the way that enables sloppy
> habits.

So basically you're saying you wish to not have restricted commits at all,
and force users who want the functionality to follow a more roundabout
method to achieve them?

OK, here's my opinion:  No, that's silly.  You're perfectly free to use a
pre-commit hook to enforce the notion for yourself of course (once they're
implemented).

Thanks,

-Miles 
-- 
Is it true that nothing can be known?  If so how do we know this?  -Woody Allen




reply via email to

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