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