Re: [RFD PATCH 00/32] subtree clone v2
- From
Elijah Newren <newren@gmail.com>
- Date
- Aug 25, 2010, 05:21 UTC
- Message-ID
- <AANLkTikv9zHGRdJRoFV6Pr0HMUbKPPz_1kUXC6DnoSXL@mail.gmail.com>
- In-Reply-To
- <AANLkTinsNvVup43B6nQtU6dvJy789n8kQm6N6na0J9oa@mail.gmail.com>
Replying to myself...
On Tue, Aug 24, 2010 at 10:37 PM, Elijah Newren <newren@gmail.com> wrote: <snip>
> outside the narrow tree. Because of that, I think you can handle > paths outside the narrow region using trivial-merge logic: From > Documentation/technical/trivial-merge.txt, I think the relevant cases > are 2, 3, 8, 10, 13, or 14. 13 & 14 already have a specified
<snip>
Show 8 quoted lines
> That only leaves cases 2 & 3 as being slightly tricky -- if a path on > one side of the merge started empty and ended empty, it would seem to > make sense that the non-empty path on the other side would be the > resolution. We can't do that in the non-narrow clone case because the > non-empty path may have been created due to a rename and we'd like to > have changes follow the rename appropriately. However, in the narrow > clone case, one can't rename from a path you don't have to a path you > do, so this possibility is eliminated.
I just realized I was assuming the path was empty in the merge base and in upstream, but non-empty on the side of the merge corresponding to the local sparse/narrow repository. My wording certainly reflected that assumption. If so, I still think what I said was correct. If not, it's slightly more subtle. If the non-empty side is upstream, then it may be a rename case that needs special handling. If it's a rename from a path outside our subtree (and we can somehow detect this case), then although we don't have the data to do any special handling, it wouldn't be necessary since we did not modify either the source or destination of the rename. The tricky case is if it's a rename from a path within our subtree to a file outside; we'd only be able to handle such situations if there was no modification other than the rename. Unfortunately, we can't distinguish between (1) renames from paths outside our subtree to outside our subtree and (2) renames plus changes from paths inside our subtree to outside our subtree.
That puts us in a bit of a pickle for the empty->empty vs. non-empty case. We can only resolve it if the non-empty side is in our subtree, or if we decide to just ignore renames in our merges.