On Sat, 27 Aug 2005, Daniel Barkalow wrote:
>
> What I missed was that the effect of causes_df_conflict is to give "no
> merge" for the entry, rather than giving an error overall. So I do need an
> equivalent.
Daniel,
I'm not 100% sure what you're trying to do, but one thing that might work
out is to just having multiple "stage 3" entries with the same pathname.
We current use 4 stages:
- stage 0 is "resolved"
- stage 1 is "original"
- stage 2 is "one branch"
- stage 3 is "another branch"
But if we allowed duplicate entries per stage, I think we could easily
just fold stage 2/3 into one stage, and just have <n> entries in stage 2.
That would immediately mean that a three-way merge could be <n> way.
The only rule would be that when you add a entry to stage 2, you must
always add it after any previous entry that is already in stage 2. That
should be easy.
In fact, this extension might even allow us to solve the "multiple merge
base" problem: we could allow multiple entries in "stage 1" too, ie one
entry per merge base (and just collapse identical entries - there's no
ordering involved in stage 1 entries).
So you could merge "n" trees with "m" bases, and all without really
changing the current logic much at all.
Maybe I'm missing something (like what you're trying to do in the first
place), but this _seems_ doable.
Of course, "git-merge-one-file" gets more interesting as a result.
Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
