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

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

[Gnu-arch-users] Re: "Newbie-ized help"


From: Miles Bader
Subject: [Gnu-arch-users] Re: "Newbie-ized help"
Date: Mon, 27 Sep 2004 13:46:18 +0900

Aaron Bentley <address@hidden> writes:
>> Also, because it uses a simpler method to choose how to do the merge,
>> update is sometimes a better choice than star-merge (which just fucks
>> things up with its "cleverness"); with some of my common merges, I
>> _always_ want update's nice simple algorithm
>
> I'd be interested to look at some of those cases, if they're publicly 
> available.

An example is with my synchronization of Emacs and Gnus -- I star-merge
between them, but they are _different_ source trees, so I _only_ want
deltas to get applied:  If I do "cd A; tla star-merge -t B", I want it
to do what update does:  apply the delta between B.in-tree and
B.in-archive; star-merge _sometimes_ does this, but other times, it
chooses to delete the entire source tree of B and replace it with A,
which is of course completely wrong.

I still use star-merge, because I want the duplicate resolution of
--three-way (luckily using --reference usually forces star-merge to do
something reasonable, but I recall situations where seemingly nothing
worked -- but the simple algorithm of update would have).

You can say "But that's a weird and wacky merge situation"; maybe you'd
be right -- but (1) it's a credit to the tla's command set that many
such merges are actually very easy, and I think you should be wary of
ad-hoc tampering with things just because you personally never had to
use a particular merge style -- such changes often make groking the
overall operation of the merge operators _harder_ even if they seem to
make sense in isolated instances; (2) it's one that I do very frequently.

> The only time I'd expect star-merge to pick differently from 
> update is when FROM has merged from you.  In that case, I can't see why 
> you'd want apply those changes, since you'll just get conflicts. 
> Admittedly, star-merge doesn't handle cherrypicking at all well, but I'd 
> see this as a job for replay --skip-present.

No -- "replay --skip-present" is only viable in a small number of
situations in which you have fairly strict control over the changes
taking place.  I do not, and so I can't use it.

Some sort of source-based duplicate resolution is necessary (and
currently provided by star-merge --three-way, albeit with various
downsides).

Really what I'm complaining about is this:  tla/arch has its problems,
but it's an impressively general and expressive tool.  It's good to make
it more usable for newbies, but _not at the expensive of making it a
lesser, more ad-hoc, and confusing (in the general case) tool._

Maybe you could say "oh, fai is for newbies only" but do you really want
to restrict yourself to that?  [and of course, reality rarely respects
such declarations :-]

-Miles
-- 
o The existentialist, not having a pillow, goes everywhere with the book by
  Sullivan, _I am going to spit on your graves_.




reply via email to

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