On Mon, 29 Aug 2005, Junio C Hamano wrote:
>
> > But if we allowed duplicate entries per stage, I think we could easily
> > just fold stage 2/3 into one stage, and just have entries in stage 2.
> > That would immediately mean that a three-way merge could be way.
>
> I suspect you are solvin
Linus Torvalds <[EMAIL PROTECTED]> writes:
> 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.
My understanding is that he is enhancing the current three-way
merge 'read-tree -m O A B' "
Daniel Barkalow <[EMAIL PROTECTED]> writes:
> I'd actually like to introduce Documentation/technical/trivial-merge for
> this stuff; I think it would be good to have documentation for people who
> need to know how the stuff works, rather than just how to use it, so we
> get a balance between reams
Daniel Barkalow <[EMAIL PROTECTED]> writes:
> 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.
Correct.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of
On Sat, 27 Aug 2005, Daniel Barkalow wrote:
>
> It looks like stage 2 is currently special as the stage that's similar to
> the index/HEAD/working tree.
Ahh, yes. We do actually want that. So yes, we should make only stage 3
have the multiple entries.
> I'd be afraid of confusing everything b
On Sat, 27 Aug 2005, Linus Torvalds wrote:
> 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 wh
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
On Sat, 27 Aug 2005, Daniel Barkalow wrote:
> Okay, so it looks to me like the only cases that care about the contents
> of the index, other than in stage 0 (which is effectively another tree,
> but already in index-form rather than tree-form), are 2 and 3, and these
> only care because read-tree
On Sat, 27 Aug 2005, Junio C Hamano wrote:
> Daniel Barkalow <[EMAIL PROTECTED]> writes:
>
> > Part of threeway_merge, however, wants to search the rest of the cache for
> > interfering entries in some cases, which would have to happen differently,
> > because I won't have the cache completely fil
Junio C Hamano <[EMAIL PROTECTED]> writes:
> Daniel Barkalow <[EMAIL PROTECTED]> writes:
>
>> Part of threeway_merge, however, wants to search the rest of the cache for
>> interfering entries in some cases, which would have to happen differently,
>> because I won't have the cache completely filled
Daniel Barkalow <[EMAIL PROTECTED]> writes:
> Part of threeway_merge, however, wants to search the rest of the cache for
> interfering entries in some cases, which would have to happen differently,
> because I won't have the cache completely filled out beforehand. I'm
> trying to figure out what t
I've gotten to the point of having all of the entries for a given path
ready to put into the cache at the same, and now I want to convert the
merge functions to take their data directly, rather than in the cache, so
that they can take extra entries for extra ancestors.
Part of threeway_merge, howe
12 matches
Mail list logo
