[Top][All Lists]

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

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

From: Aaron Bentley
Subject: [Gnu-arch-users] Re: "Newbie-ized help"
Date: Sun, 26 Sep 2004 23:58:27 -0400
User-agent: Mozilla Thunderbird 0.5 (X11/20040306)

Miles Bader wrote:
Aaron Bentley <address@hidden> writes:

It's _not the same_ as star-merge when used in the same context.

Right. star-merge does the right thing in every context that update does, plus some that update gets wrong. The fact that rejects go the other way seems relatively unimportant.

That's my big beef with your changes to fai -- you make these judgements
like "seems relatively unimportant, so I can change it as I wish"
without much apparent experience actually _using_ these features.

Damn right I've never used update for merging. Never seen a case when it was useful. The way it works in Fai is the way I always thought it worked, and is what I think people expect from a tree update command. But Fai's highly configurable, and this could be configurable too. Or it could be an alternate algorithm in merge, which actually makes more sense to me.

I have in the past undone a star-merge and used update because I got too
confused by the conflicts generated by the former -- you see, when
merging into my own branches, I understand _my_ changes better than I
understand the changes made by other people (which I am merging into my
branch).  So when I see a reject which is my own change, it's sometimes
easier for me to think about how to apply this to the merged code.

The undo/redo stuff that update does is window-dressing. It's trivial to layer that onto star-merge. That's why it's relatively unimportant.

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. 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.

Ideally, I'd like there to be _one_ command that does the job of both
star-merge and update, and takes _independent_ flags for

  (1) auto-duplicate-resolution (apparently we can't use patch -N though)

  (2) conflict style (.rej or inline)

  (3) for .rej-style conflicts, the direction of the merge

  (4) some way to turn off star-merge's "clever" choice of patch endpoints,
      and just use the simple algorithm update currently uses.

Probably such a command should be called "update", BTW...

I think such a command is a great idea, but I think it should be called "merge".


reply via email to

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