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

[Adrian Irving-Beer]

On Fri, May 21, 2004 at 03:09:02PM -0400, James Blackwell wrote:

> This is kind of where arch is today. Arch has a solid foundation. But
> the interface isn't as consistant and intuitive as it could be. If we
> were to cast our interface in concrete today, we would end up with all
> sorts of problems with our 'interface sidewalk'. Our sidewalk wouldn't
> be quite straight, would have cracks in it, and would be a trip hazard
> where the sidewalk tiles had buckled and risen up.

I agree with most (probably all) of what you say.  Of course, it should
be weighted on a case-by-case basis, lest we end up spending more time
digging up the street than actually walking on it.  I can cite several
local roads that fit that description! :)

I don't realistically see that happening, though.

Thankfully, in contrast to make and cvs and whatnot, arch's repository
format tends to be forwards- *and* backwards-compatible, by virtue of
additional metadata (e.g. signing) being an optional part of the format.
This makes room for improvements to the UI (or complete rewrites)
without breaking back-end stuff.

I'm not sure how realistic it is that we'll be looking at future
generations of arch clients to fully replace tla . . . but if we
eventually do, all the interface-concrete reverts to liquid form and can
be reshaped as we desire.  We may also have a better idea of what people
want by then.

Personally, I'm for the no-empty-commits default, but only marginally.
Doesn't bug me a great deal, but it seems more sensible.  I'd be happy
enough if there were an option to prevent empty changesets, because I
could stick that in an aba wrapper.

Also IMO, --force sounds a little too generic (as if it ignores
tree-lint errors, etc.), and I'd prefer --empty, myself.  But that has
the downside of suggesting it will ALWAYS be empty . . . and
--allow-empty is too long. :(

signature.asc
Description: Digital signature