On Fri, Jun 27, 2014 at 6:39 PM, Jason Pyeron <jpye...@pdinc.us> wrote:
>> On Fri, Jun 27, 2014 at 4:47 PM, Jason Pyeron
>> <jpye...@pdinc.us> wrote:
>> > There are two identical files from the same original
>> parent, but both were
>> > renamed in their own branches. One branch moved the file to
>> a new folder, the
>> > other renamed the file in the same folder.
>> You have not stated what you think the issue is. You have only stated
>> the setup.
> Thanks, I could have said it better.
> I think that git should understand that I have moved a file in path only (the
> tree object containing the file's entry change, but not the entry it self) and
> that the branch from which I want to merge back (with common ancestry) has
> renamed the file in the same path ( the tree object is unchanged, but the
> is) such that the object is re-parented and renamed in that path.
I think Git's perspective is that you have moved the file in both
contexts. The name of the file includes the path and filename. The
fact is that you renamed the file in both branches. If you had
renamed the file in only one branch, Git would have had a better
chance of figuring out the "right" thing to do. Git tries not to do
something potentially dangerous without getting your involvement.
That said, Git's rename handling is stupid sometimes and could stand
to be improved.
> How can this be done in git or if it cannot what are the chalenges to patching
> git for this issue.
I do not know a better thing for git to do here. I can imagine cases
where either choice is the wrong one. If git silently makes the
choice and continues, say, during a rebase, you might not notice until
things have horribly awry.
>> Maybe you meant to move the renamed file to the same folder where it
>> exists in the merge target. I do not get a conflict when I do that.
> Are you saying I should git mv src/TrueCrypt.sln CipherShed.sln ?
> Then it will be in the wrong path as intended.
>> git reset --hard b60070f4d0879e277f44d174a163bbb292325fea
>> git mv src/TrueCrypt.sln CipherShed.sln
>> git commit -m 'renamed to be congruent with a0c84ff'
>> git merge a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68
>> No conflict (on that file, anyway).
> Agreed, but not the desired end state.
Git's magic still has limits.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html