Hi,
On Wed, Aug 25, 2010 at 12:21 AM, Nguyen Thai Ngoc Duy
<pclouds@xxxxxxxxx> wrote:
> OK here is the story. And I could be wrong on this merge stuff.
>
> I was deep in merge-tree.c code (which was the base for my narrow
> merge) and was stuck at
>
> "If either "you" or "upstream" is as same as ancestor (all as dirs),
> then it's easy. What if neither of them is the same as ancestor? If we
> have more trees, we could just descend and figure out. But we don't
> because it's outside narrow area. It could be that "you" added a new
> file and "upstream" added another file, which is trivial at file
> level."
>
> I was deep in code and forgot that in narrow repo, I did not allow to
> change outside narrow area, so it "you" must be as same as ancestor.
> But the question was, what if user decides to branch from some commit
> in history? If he/she does, "you" might not be as same as ancestor. If
> it's non trivial merge, merge should fail (expected).
If you branch from some older commit, then naturally the common
ancestor between you and upstream changes as well (namely, to that
older commit). Since you don't/can't change anything outside your
subtree, that puts you in the following situation for paths outside
your subtree when you try to merge:
Merge-side: ancestor you upstream
-------- -------- --------------
Sha1sum: old-stuff old-stuff newest-stuff
> But the "it could be that "you" added ... at file level" above
> bothered me. I had a feeling that I could miss a trivial merge (at
> file level) because I could not make a judgement at (shallow) tree
> level. And I did not have all trees to do merge at file level.
>
> Still puzzling thinking about this.. Did I make wrong assumptions?
I'm not sure I understand why there would be any issue with you adding
one file in your subtree, and upstream adding (another/the same?) file
outside your subtree. The only problematic case I see is when files
are renamed upstream from within the subtree to outside the subtree
and subsequently changed. If on your side of history you modify one
of these files that were renamed from upstream, there's no way to
apply your changes to the new file. It'd look something like this:
Merge-side: ancestor you upstream
-------- -------- --------------
old-file: original modify1 (missing)
new-file: (missing) (missing) modify2
The correct resolution is a three-way merge between original, modify1,
and modify2, stored in new-file with old-file being deleted. However,
you don't have access to new-file/modify2 since it's outside your
subtree. All you'd see is a modify/delete conflict in old-file and
the 'trivial merge' logic I suggested above (which ignores renames)
would result in new-file still having contents of modify2.
Hopefully the modify/delete conflict would be enough to trigger the
user to ask rather than just randomly pick some resolution and
proceed, which makes me think it should be okay to have a renaming
ignoring 'trivial' merge algorithm for subtrees.
Elijah
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html