[Top][All Lists]

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

Re: [Gnu-arch-users] Re: BUG: extra diff arguments for "tla changes --di

From: Aaron Bentley
Subject: Re: [Gnu-arch-users] Re: BUG: extra diff arguments for "tla changes --diffs"]
Date: Fri, 27 Aug 2004 18:19:35 -0400
User-agent: Mozilla Thunderbird 0.5 (X11/20040309)

Stefan Monnier wrote:
The main reason people want options
in `tla changes' is for viewing.

Well, if it's just for viewing, I don't care.  You've been arguing that it's
useful to be able to apply non-standard changesets, though.  If that's true,
people might push to be able to commit non-standard changesets also.

Here's how things went, AFAIR:
- someone asked for diff options in `tla changes' (not the first such
  request, by far).
- someone else said "omygod, no way, this will mean changesets with
  non-standard diff content, all hell will break lose".

What I said was "this would require producing a changeset with non-standard contents. I'm not entirely opposed to this, but it would need to be done carefully." James reacted more strongly.

- Miles and I said "no biggie, it's harmless and might even be useful".

And I said "yes, biggie. There are clear advantages to maintaining a single changeset format, so allowing such changesets to be applied is not harmless. While they're valuable for viewing diffs, you need stronger reasons than 'might even be useful' to convince me that Arch should apply non-standard changesets."

Nowhere did anyone request non-standard difs in archive changesets.

No, be we talked a lot about inexact patching, and the way I use Arch, that's mostly done with archive changesets.

Of course, maybe at some point someone will ask for it, but I see evidence
that it will happen, and no good reason why accepting diff-options for
`changes' should lead to accepting diff options for `commit'

Well, I think it could, and I don't want it to. Now that I see some options that would actually answer that desire *better* than customizing archive changesets, I'm less concerned. I feel that the person applying the changeset is better qualified to judge the appropriate inexact-patching options.

I think we could allow any arguments for non-applyable changesets, but should be more strict about what's considered a standard (and therefore applyable) changeset. But even there, there's room for useful variations.


Aaron Bentley
Director of Technology
Panometrics, Inc.

reply via email to

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