Re: [Gnu-arch-users] Re: reminder: winning smallish project

[Jason McCarty]

Miles Bader wrote:
> Jason McCarty <address@hidden> writes:
> > Anyway, I completely agree with you here, but how about instead of
> > --opposite, use --source (with --reverse). It would be more intuitive
> > since it operates precisely on the files listed by inventory --source.
> > It would also have the advantage of being able to apply patches in the
> > normal direction without touching patch-logs.
> 
> Both --opposite and --source seem wrong to me -- the former, because as
> Robert pointed out, it's a synonym for --reverse; the latter because it
> seems too low-level (even if people know about how arch uses patch-logs
> to do things, I think it's often easier to think in higher-level terms).

Hmm, I tend to think of everything _but_ patch-logs as source, which is
why --source works for me on a high level. On a low level, it's actually
wrong (patch-logs, =tagging-method, and .arch-ids are all source).

> I'd rather have two semantically identical, but differently named,
> options for replay and dopatch, with the former emphasizing the
> high-level operation of `undo the changes in this patch, but don't
> delete the patch from the history', and the latter more directly saying
> what's going on at a low-level.  If it's later discovered that there's
> some odd little wrinkle that makes it desirable to change the behavior
> of replay in this case, then it might make sense to in fact add a new
> option corresponding to that wrinkle to dopatch, and change replay to
> use it without changing replay's higher-level interface.

Maybe...but I think I would want every dopatch option to also be a
replay option. The additional user-friendly replay options might not
necessarily be synonyms, either; they could represent a combination of
dopatch options. Having them both present would be beneficial.

> Some ideas for replay:
> 
>   --omit     `omit this patch from the patch-stream'
>   --suppress `forcibly prevent this patch from being part of the patch-stream'

I don't quite understand the meaning of these, or their differences.

> For dopatch, variants on either of the two previous suggestions seems
> reasonable:  --no-patch-logs, --source-only.  I rather like
> --no-patch-logs better because it makes it clear _exactly_ what's being
> done; --source-only seems a little unclear in the case where there are
> changes that aren't really to the `source code,' but are not changes in
> the patch-logs either (e.g., a change to =tagging-method, or a change in
> an .arch-ids file).

It's true that patch-logs and .arch-ids are technically source, but I
was thinking of replay --source more intuitively as just what inventory
lists by default, rather than a one-to-one mapping of all source files.
Renames etc. (ie .arch-ids changes) would be considered changes to
source. I hadn't considered =tagging-method...in light of that, perhaps
--no-patch-logs is clearer, although annoyingly long.

There may be many choices for what you want to patch, so maybe a simple
(possibly regex?) limit argument to dopatch would be appropriate (with
your more declarative frontend in replay). Gets more complicated all the
time, eh?

Jason