Trouble merging renamed but identical files - CONFLICT (rename/rename)

Trouble merging renamed but identical files - CONFLICT (rename/rename)

[Jason Pyeron]

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.

Steps to reproduce the issue:
git init
git fetch https://github.com/pdinc-oss/CipherShed.git
git fetch https://github.com/srguglielmo/CipherShed.git
git checkout -b test b60070f4d0879e277f44d174a163bbb292325fea
git merge a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68

CONFLICT (rename/rename): Rename "TrueCrypt.sln"->"src/TrueCrypt.sln" in branch
"HEAD" rename "TrueCrypt.sln"->"CipherShed.sln" in
"a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68"

git reset --hard b60070f4d0879e277f44d174a163bbb292325fea
git mv src/TrueCrypt.sln src/CipherShed.sln
git commit -m 'renamed to be congruent with a0c84ff'
git merge a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68

Sill get a CONFLICT (rename/rename): Rename
"TrueCrypt.sln"->"src/CipherShed.sln" in branch "HEAD" rename
"TrueCrypt.sln"->"CipherShed.sln" in "a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68"

I will have many more to come, any suggestions?

Repos:

https://github.com/srguglielmo/CipherShed/commit/1ca13ed2271d60ba93d40bcc8db17ce
d8545f172

https://github.com/pdinc-oss/CipherShed/commit/b60070f4d0879e277f44d174a163bbb29
2325fea



--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-                                                               -
- Jason Pyeron                      PD Inc. http://www.pdinc.us -
- Principal Consultant              10 West 24th Street #100    -
- +1 (443) 269-1555 x333            Baltimore, Maryland 21218   -
-                                                               -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.

Re: Trouble merging renamed but identical files - CONFLICT (rename/rename)

[Phil Hord]

On Fri, Jun 27, 2014 at 4:47 PM, Jason Pyeron <jpyeron@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.


I suppose you want Git to merge without conflict in the end, though,
based on your script.  Is that right?


> Steps to reproduce the issue:
> git init
> git fetch https://github.com/pdinc-oss/CipherShed.git
> git fetch https://github.com/srguglielmo/CipherShed.git
> git checkout -b test b60070f4d0879e277f44d174a163bbb292325fea
> git merge a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68
>
> CONFLICT (rename/rename): Rename "TrueCrypt.sln"->"src/TrueCrypt.sln" in branch
> "HEAD" rename "TrueCrypt.sln"->"CipherShed.sln" in
> "a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68"

Git seems to be doing the correct thing here.


> git reset --hard b60070f4d0879e277f44d174a163bbb292325fea
> git mv src/TrueCrypt.sln src/CipherShed.sln
> git commit -m 'renamed to be congruent with a0c84ff'
> git merge a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68
>
> Sill get a CONFLICT (rename/rename): Rename
> "TrueCrypt.sln"->"src/CipherShed.sln" in branch "HEAD" rename
> "TrueCrypt.sln"->"CipherShed.sln" in "a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68"

Git seems to be doing the correct thing here, too.

> I will have many more to come, any suggestions?

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.

   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).

Regards,
Phil

> This message is copyright PD Inc, subject to license 20080407P00.

p.s. Maybe you should remove this copyright threat in the future when
you are writing to an open source community seeking help.

RE: Trouble merging renamed but identical files - CONFLICT (rename/rename)

[Jason Pyeron]

> -----Original Message-----
> From: Phil Hord [mailto:phil.hord@gmail.com] 
> Sent: Friday, June 27, 2014 17:46
> To: Jason Pyeron
> Cc: git
> Subject: Re: Trouble merging renamed but identical files - 
> CONFLICT (rename/rename)
> 
> On Fri, Jun 27, 2014 at 4:47 PM, Jason Pyeron 
> <jpyeron@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 entry
is) such that the object is re-parented and renamed in that path.

How can this be done in git or if it cannot what are the chalenges to patching
git for this issue.

git cat-file -p b60070f4d0879e277f44d174a163bbb292325fea # tree
d8df83fc6714aab1fc1df061fcb03410e1dab1e5
git cat-file -p d8df83fc6714aab1fc1df061fcb03410e1dab1e5 # 040000 tree
68bb8a223284e0f5057421217a5965128bf1d51a    src
git cat-file -p 68bb8a223284e0f5057421217a5965128bf1d51a # 100644 blob
25c7d3b12bced67046359ba1e7945f82a2640147    TrueCrypt.sln

git cat-file -p a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68 # tree
7f82a6c46f19931c3c40d44dc196cbfab7feaa72
git cat-file -p 7f82a6c46f19931c3c40d44dc196cbfab7feaa72 # 100644 blob
25c7d3b12bced67046359ba1e7945f82a2640147    CipherShed.sln

> 
> 
> I suppose you want Git to merge without conflict in the end, though,
> based on your script.  Is that right?
> 
> 
> > Steps to reproduce the issue:
> > git init
> > git fetch https://github.com/pdinc-oss/CipherShed.git
> > git fetch https://github.com/srguglielmo/CipherShed.git
> > git checkout -b test b60070f4d0879e277f44d174a163bbb292325fea
> > git merge a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68
> >
> > CONFLICT (rename/rename): Rename 
> "TrueCrypt.sln"->"src/TrueCrypt.sln" in branch
> > "HEAD" rename "TrueCrypt.sln"->"CipherShed.sln" in
> > "a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68"
> 
> Git seems to be doing the correct thing here.
> 
> 
> > git reset --hard b60070f4d0879e277f44d174a163bbb292325fea
> > git mv src/TrueCrypt.sln src/CipherShed.sln
> > git commit -m 'renamed to be congruent with a0c84ff'
> > git merge a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68
> >
> > Sill get a CONFLICT (rename/rename): Rename
> > "TrueCrypt.sln"->"src/CipherShed.sln" in branch "HEAD" rename
> > "TrueCrypt.sln"->"CipherShed.sln" in 
> "a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68"
> 
> Git seems to be doing the correct thing here, too.
> 
> > I will have many more to come, any suggestions?
> 
> 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.

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-                                                               -
- Jason Pyeron                      PD Inc. http://www.pdinc.us -
- Principal Consultant              10 West 24th Street #100    -
- +1 (443) 269-1555 x333            Baltimore, Maryland 21218   -
-                                                               -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.

 

Re: Trouble merging renamed but identical files - CONFLICT (rename/rename)

[Phil Hord]

On Fri, Jun 27, 2014 at 6:39 PM, Jason Pyeron <jpyeron@pdinc.us> wrote:
>> On Fri, Jun 27, 2014 at 4:47 PM, Jason Pyeron
>> <jpyeron@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 entry
> 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.

Phil

RE: Trouble merging renamed but identical files - CONFLICT (rename/rename)

[Jason Pyeron]

> -----Original Message-----
> From: Jason Pyeron 
> Sent: Friday, June 27, 2014 18:39
> 
> > -----Original Message-----
> > From: Phil Hord [mailto:phil.hord@gmail.com] 
> > Sent: Friday, June 27, 2014 17:46
> > To: Jason Pyeron
> > Cc: git
> > Subject: Re: Trouble merging renamed but identical files - 
> > CONFLICT (rename/rename)
> > 
> > On Fri, Jun 27, 2014 at 4:47 PM, Jason Pyeron 
> > <jpyeron@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 entry is) such that the object is re-parented and renamed 
> in that path.
> 
> How can this be done in git or if it cannot what are the 
> chalenges to patching git for this issue.
> 
> git cat-file -p b60070f4d0879e277f44d174a163bbb292325fea # 
> tree d8df83fc6714aab1fc1df061fcb03410e1dab1e5
> git cat-file -p d8df83fc6714aab1fc1df061fcb03410e1dab1e5 # 
> 040000 tree 68bb8a223284e0f5057421217a5965128bf1d51a    src
> git cat-file -p 68bb8a223284e0f5057421217a5965128bf1d51a # 
> 100644 blob 25c7d3b12bced67046359ba1e7945f82a2640147    TrueCrypt.sln
> 
> git cat-file -p a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68 # 
> tree 7f82a6c46f19931c3c40d44dc196cbfab7feaa72
> git cat-file -p 7f82a6c46f19931c3c40d44dc196cbfab7feaa72 # 
> 100644 blob 25c7d3b12bced67046359ba1e7945f82a2640147    CipherShed.sln
> 
> > 
> > 
> > I suppose you want Git to merge without conflict in the end, though,
> > based on your script.  Is that right?
> > 
> > 
> > > Steps to reproduce the issue:
> > > git init
> > > git fetch https://github.com/pdinc-oss/CipherShed.git
> > > git fetch https://github.com/srguglielmo/CipherShed.git
> > > git checkout -b test b60070f4d0879e277f44d174a163bbb292325fea
> > > git merge a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68
> > >
> > > CONFLICT (rename/rename): Rename 
> > "TrueCrypt.sln"->"src/TrueCrypt.sln" in branch
> > > "HEAD" rename "TrueCrypt.sln"->"CipherShed.sln" in
> > > "a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68"
> > 
> > Git seems to be doing the correct thing here.
> > 
> > 
> > > git reset --hard b60070f4d0879e277f44d174a163bbb292325fea
> > > git mv src/TrueCrypt.sln src/CipherShed.sln
> > > git commit -m 'renamed to be congruent with a0c84ff'
> > > git merge a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68
> > >
> > > Sill get a CONFLICT (rename/rename): Rename
> > > "TrueCrypt.sln"->"src/CipherShed.sln" in branch "HEAD" rename
> > > "TrueCrypt.sln"->"CipherShed.sln" in 
> > "a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68"
> > 
> > Git seems to be doing the correct thing here, too.
> > 
> > > I will have many more to come, any suggestions?
> > 
> > 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.

Sorry for the http://pastebin.com/1R68v6jt (changes the merge to
1ca13ed2271d60ba93d40bcc8db17ced8545f172, and manually reconciles the merge),
but it was too long to be readable in the email.

git blame HEAD -- src/Main/Forms/CipherShed.fbp | cut -c 1-8 | sort -u 

Gives: 
ac812aa3
b50a2fb1

git blame b60070f4d0879e277f44d174a163bbb292325fea --
src/Main/Forms/TrueCrypt.fbp | cut -c 1-8 | sort -u

Gives: 
07b2176f
0eb8b4fa
12c94add
a17c95a3
a757b4d4
cac6cd14
d0a9dfa8
d94128a9
e6b1437a
f1bb489c

If I use cherry pick (vs merge), I can maintain the big history in b60070f, but
loose the small history in 1ca13ed

      [test]
      /     \
     /       \
[b60070f] [1ca13ed]
    |         |
    |         |
[65efd37]     |
    |    \    |
    |     \   |
[d8da778] [39ebb06]

How do I maintain all the history including the (line) changes in 1ca13ed?

-Jason

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-                                                               -
- Jason Pyeron                      PD Inc. http://www.pdinc.us -
- Principal Consultant              10 West 24th Street #100    -
- +1 (443) 269-1555 x333            Baltimore, Maryland 21218   -
-                                                               -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.

 

RE: Trouble merging renamed but identical files - CONFLICT (rename/rename)

[Jason Pyeron]

> -----Original Message-----
> From: Jason Pyeron
> Sent: Friday, June 27, 2014 20:42
> To: 'git'
> Cc: 'Phil Hord'
> Subject: RE: Trouble merging renamed but identical files - 
> CONFLICT (rename/rename)
> 
> > -----Original Message-----
> > From: Jason Pyeron 
> > Sent: Friday, June 27, 2014 18:39
> > 
> > > -----Original Message-----
> > > From: Phil Hord [mailto:phil.hord@gmail.com] 
> > > Sent: Friday, June 27, 2014 17:46
> > > To: Jason Pyeron
> > > Cc: git
> > > Subject: Re: Trouble merging renamed but identical files - 
> > > CONFLICT (rename/rename)
> > > 
> > > On Fri, Jun 27, 2014 at 4:47 PM, Jason Pyeron 
> > > <jpyeron@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 entry is) such that the object is re-parented and renamed 
> > in that path.
> > 
> > How can this be done in git or if it cannot what are the 
> > chalenges to patching git for this issue.
> > 
> > git cat-file -p b60070f4d0879e277f44d174a163bbb292325fea # 
> > tree d8df83fc6714aab1fc1df061fcb03410e1dab1e5
> > git cat-file -p d8df83fc6714aab1fc1df061fcb03410e1dab1e5 # 
> > 040000 tree 68bb8a223284e0f5057421217a5965128bf1d51a    src
> > git cat-file -p 68bb8a223284e0f5057421217a5965128bf1d51a # 
> > 100644 blob 25c7d3b12bced67046359ba1e7945f82a2640147    
> TrueCrypt.sln
> > 
> > git cat-file -p a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68 # 
> > tree 7f82a6c46f19931c3c40d44dc196cbfab7feaa72
> > git cat-file -p 7f82a6c46f19931c3c40d44dc196cbfab7feaa72 # 
> > 100644 blob 25c7d3b12bced67046359ba1e7945f82a2640147    
> CipherShed.sln
> > 
> > > 
> > > 
> > > I suppose you want Git to merge without conflict in the 
> end, though,
> > > based on your script.  Is that right?
> > > 
> > > 
> > > > Steps to reproduce the issue:
> > > > git init
> > > > git fetch https://github.com/pdinc-oss/CipherShed.git
> > > > git fetch https://github.com/srguglielmo/CipherShed.git
> > > > git checkout -b test b60070f4d0879e277f44d174a163bbb292325fea
> > > > git merge a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68
> > > >
> > > > CONFLICT (rename/rename): Rename 
> > > "TrueCrypt.sln"->"src/TrueCrypt.sln" in branch
> > > > "HEAD" rename "TrueCrypt.sln"->"CipherShed.sln" in
> > > > "a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68"
> > > 
> > > Git seems to be doing the correct thing here.
> > > 
> > > 
> > > > git reset --hard b60070f4d0879e277f44d174a163bbb292325fea
> > > > git mv src/TrueCrypt.sln src/CipherShed.sln
> > > > git commit -m 'renamed to be congruent with a0c84ff'
> > > > git merge a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68
> > > >
> > > > Sill get a CONFLICT (rename/rename): Rename
> > > > "TrueCrypt.sln"->"src/CipherShed.sln" in branch "HEAD" rename
> > > > "TrueCrypt.sln"->"CipherShed.sln" in 
> > > "a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68"
> > > 
> > > Git seems to be doing the correct thing here, too.
> > > 
> > > > I will have many more to come, any suggestions?
> > > 
> > > 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.
> 
> Sorry for the http://pastebin.com/1R68v6jt (changes the merge to
> 1ca13ed2271d60ba93d40bcc8db17ced8545f172, and manually 
> reconciles the merge),
> but it was too long to be readable in the email.
> 
> git blame HEAD -- src/Main/Forms/CipherShed.fbp | cut -c 1-8 
> | sort -u 
> 
> Gives: 
> ac812aa3
> b50a2fb1
> 
> git blame b60070f4d0879e277f44d174a163bbb292325fea --
> src/Main/Forms/TrueCrypt.fbp | cut -c 1-8 | sort -u
> 
> Gives: 
> 07b2176f
> 0eb8b4fa
> 12c94add
> a17c95a3
> a757b4d4
> cac6cd14
> d0a9dfa8
> d94128a9
> e6b1437a
> f1bb489c
> 
> If I use cherry pick (vs merge), I can maintain the big 
> history in b60070f, but
> loose the small history in 1ca13ed
> 
>       [test]
>       /     \
>      /       \
> [b60070f] [1ca13ed]
>     |         |
>     |         |
> [65efd37]     |
>     |    \    |
>     |     \   |
> [d8da778] [39ebb06]
> 
> How do I maintain all the history including the (line) 
> changes in 1ca13ed?

# http://pastebin.com/TuqhYubH 

# do the cerry picks, then...

git merge $(echo 'Merge of 1ca13ed2271d60ba93d40bcc8db17ced8545f172 branch -
rebranding' |\
   git commit-tree -p HEAD -p rebranding \
     $(git cat-file -p HEAD | grep ^tree | sed -e 's/^tree //') )

Perfect results. This does not seem like this should be the "right" way to do
it.


Instead of git merge rebranding, which gives CONFLICT (rename/rename)....
Automatic merge failed; fix conflicts and then commit the result. Followed by
bad blame lines.

-Jason

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-                                                               -
- Jason Pyeron                      PD Inc. http://www.pdinc.us -
- Principal Consultant              10 West 24th Street #100    -
- +1 (443) 269-1555 x333            Baltimore, Maryland 21218   -
-                                                               -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.

 

Re: Trouble merging renamed but identical files - CONFLICT (rename/rename)

[Phil Hord]

On Fri, Jun 27, 2014 at 8:42 PM, Jason Pyeron <jpyeron@pdinc.us> wrote:
> Sorry for the http://pastebin.com/1R68v6jt (changes the merge to
> 1ca13ed2271d60ba93d40bcc8db17ced8545f172, and manually reconciles the merge),
> but it was too long to be readable in the email.
>
> git blame HEAD -- src/Main/Forms/CipherShed.fbp | cut -c 1-8 | sort -u
>
> Gives:
> ac812aa3
> b50a2fb1
>
> git blame b60070f4d0879e277f44d174a163bbb292325fea --
> src/Main/Forms/TrueCrypt.fbp | cut -c 1-8 | sort -u
>
> Gives:
> 07b2176f
> 0eb8b4fa
> 12c94add
> a17c95a3
> a757b4d4
> cac6cd14
> d0a9dfa8
> d94128a9
> e6b1437a
> f1bb489c
>
> If I use cherry pick (vs merge), I can maintain the big history in b60070f, but
> loose the small history in 1ca13ed
>
>       [test]
>       /     \
>      /       \
> [b60070f] [1ca13ed]
>     |         |
>     |         |
> [65efd37]     |
>     |    \    |
>     |     \   |
> [d8da778] [39ebb06]
>
> How do I maintain all the history including the (line) changes in 1ca13ed?

I see the results, but my brain is not able to make sense of your goal
yet.  I'll try again later when I've had my coffee.

Re: Trouble merging renamed but identical files - CONFLICT (rename/rename)

[Phil Hord]

On Sun, Jun 29, 2014 at 11:31 AM, Phil Hord <phil.hord@gmail.com> wrote:
> On Fri, Jun 27, 2014 at 8:42 PM, Jason Pyeron <jpyeron@pdinc.us> wrote:
>> Sorry for the http://pastebin.com/1R68v6jt (changes the merge to
>> 1ca13ed2271d60ba93d40bcc8db17ced8545f172, and manually reconciles the merge),
>> but it was too long to be readable in the email.

Ok, I think I understand the issue you are trying to solve now.

Git (rather famously[1]) does not record renames or copies.  It is
expected instead that renames and copies will be detected when it is
important after the fact. This allows us to ignore rename detection
and resolution when creating project history; in the future, better
rename/copy detection will "just work" on existing repositories and
the repos themselves will not need to be adjusted.

What you are encountering now seems to be a shortcoming of Git's
current rename/copy detection.  But you are trying to overcome today's
shortcoming by adjusting your project history to accommodate it.
Instead you should just do the merge like you normally would without
regard to how 'git blame' shows the result.

Maybe there is a bug here still, but it is probably in git-blame.

[1] https://git.wiki.kernel.org/index.php/GitFaq#Why_does_Git_not_.22track.22_renames.3F

RE: Trouble merging renamed but identical files - CONFLICT (rename/rename)

[Jason Pyeron]

[-- Attachment #1: Type: text/plain, Size: 2341 bytes --]

> -----Original Message-----
> From: Phil Hord 
> Sent: Sunday, June 29, 2014 16:09
> 
> On Sun, Jun 29, 2014 at 11:31 AM, Phil Hord 
> <phil.hord@gmail.com> wrote:
> > On Fri, Jun 27, 2014 at 8:42 PM, Jason Pyeron 
> <jpyeron@pdinc.us> wrote:
> >> Sorry for the http://pastebin.com/1R68v6jt (changes the merge to
> >> 1ca13ed2271d60ba93d40bcc8db17ced8545f172, and manually 
> reconciles the merge),
> >> but it was too long to be readable in the email.
> 
> Ok, I think I understand the issue you are trying to solve now.
> 
> Git (rather famously[1]) does not record renames or copies.  It is
> expected instead that renames and copies will be detected when it is
> important after the fact. This allows us to ignore rename detection
> and resolution when creating project history; in the future, better
> rename/copy detection will "just work" on existing repositories and
> the repos themselves will not need to be adjusted.

Looking at http://pastebin.com/1R68v6jt , I have a work around.

In summary, 7.git cherry-pick -x HEAD..rebranding , then

git merge $(echo 'Merge of 1ca13ed2271d60ba93d40bcc8db17ced8545f172 branch -
rebranding' |\
    git commit-tree -p HEAD -p rebranding \
         $(git cat-file -p HEAD | grep ^tree | sed -e 's/^tree //') )

Now it is perfect in the blame and log --graph.

> 
> What you are encountering now seems to be a shortcoming of Git's
> current rename/copy detection.  But you are trying to overcome today's
> shortcoming by adjusting your project history to accommodate it.
> Instead you should just do the merge like you normally would without
> regard to how 'git blame' shows the result.
> 
> Maybe there is a bug here still, but it is probably in git-blame.
> 
> [1] 
> https://git.wiki.kernel.org/index.php/GitFaq#Why_does_Git_not_
> .22track.22_renames.3F
> 
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-                                                               -
- Jason Pyeron                      PD Inc. http://www.pdinc.us -
- Principal Consultant              10 West 24th Street #100    -
- +1 (443) 269-1555 x333            Baltimore, Maryland 21218   -
-                                                               -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6748 bytes --]

Re: Trouble merging renamed but identical files - CONFLICT (rename/rename)

[Phil Hord]

On Sun, Jun 29, 2014 at 4:20 PM, Jason Pyeron <jpyeron@pdinc.us> wrote:
>> -----Original Message-----
>> From: Phil Hord
>> Sent: Sunday, June 29, 2014 16:09
>>
>> On Sun, Jun 29, 2014 at 11:31 AM, Phil Hord
>> <phil.hord@gmail.com> wrote:
>> > On Fri, Jun 27, 2014 at 8:42 PM, Jason Pyeron
>> <jpyeron@pdinc.us> wrote:
>> >> Sorry for the http://pastebin.com/1R68v6jt (changes the merge to
>> >> 1ca13ed2271d60ba93d40bcc8db17ced8545f172, and manually
>> reconciles the merge),
>> >> but it was too long to be readable in the email.
>>
>> Ok, I think I understand the issue you are trying to solve now.
>>
>> Git (rather famously[1]) does not record renames or copies.  It is
>> expected instead that renames and copies will be detected when it is
>> important after the fact. This allows us to ignore rename detection
>> and resolution when creating project history; in the future, better
>> rename/copy detection will "just work" on existing repositories and
>> the repos themselves will not need to be adjusted.
>
> Looking at http://pastebin.com/1R68v6jt , I have a work around.
>
> In summary, 7.git cherry-pick -x HEAD..rebranding , then
>
> git merge $(echo 'Merge of 1ca13ed2271d60ba93d40bcc8db17ced8545f172 branch -
> rebranding' |\
>     git commit-tree -p HEAD -p rebranding \
>          $(git cat-file -p HEAD | grep ^tree | sed -e 's/^tree //') )
>
> Now it is perfect in the blame and log --graph.

Yes, but your workaround unnecessarily duplicates commits and
complicates the history of your project. You are munging your project
to compensate for git's current shortcomings.

But it's your project.  Your choice.

RE: Trouble merging renamed but identical files - CONFLICT (rename/rename)

[Jason Pyeron]

> -----Original Message-----
> From: Phil Hord
> Sent: Sunday, June 29, 2014 16:27
> 
> On Sun, Jun 29, 2014 at 4:20 PM, Jason Pyeron 
> <jpyeron@pdinc.us> wrote:
> >> -----Original Message-----
> >> From: Phil Hord
> >> Sent: Sunday, June 29, 2014 16:09
> >>
> >> On Sun, Jun 29, 2014 at 11:31 AM, Phil Hord
> >> <phil.hord@gmail.com> wrote:
> >> > On Fri, Jun 27, 2014 at 8:42 PM, Jason Pyeron
> >> <jpyeron@pdinc.us> wrote:
> >> >> Sorry for the http://pastebin.com/1R68v6jt (changes the merge to
> >> >> 1ca13ed2271d60ba93d40bcc8db17ced8545f172, and manually
> >> reconciles the merge),
> >> >> but it was too long to be readable in the email.
> >>
> >> Ok, I think I understand the issue you are trying to solve now.
> >>
> >> Git (rather famously[1]) does not record renames or copies.  It is
> >> expected instead that renames and copies will be detected 
> when it is
> >> important after the fact. This allows us to ignore rename detection
> >> and resolution when creating project history; in the future, better
> >> rename/copy detection will "just work" on existing repositories and
> >> the repos themselves will not need to be adjusted.
> >
> > Looking at http://pastebin.com/1R68v6jt , I have a work around.
> >
> > In summary, 7.git cherry-pick -x HEAD..rebranding , then
> >
> > git merge $(echo 'Merge of 
> 1ca13ed2271d60ba93d40bcc8db17ced8545f172 branch -
> > rebranding' |\
> >     git commit-tree -p HEAD -p rebranding \
> >          $(git cat-file -p HEAD | grep ^tree | sed -e 
> 's/^tree //') )
> >
> > Now it is perfect in the blame and log --graph.
> 
> Yes, but your workaround unnecessarily duplicates commits and
> complicates the history of your project. You are munging your project

But I want to avoid thet complicating, while still showing that line 42 was
modified by X. Should this be possible with a merge, without using cherry-pick?

> to compensate for git's current shortcomings.

Btw I am not able to pull up https://git.wiki.kernel.org/ or
http://git.wiki.kernel.org/ 

-Jason 

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-                                                               -
- Jason Pyeron                      PD Inc. http://www.pdinc.us -
- Principal Consultant              10 West 24th Street #100    -
- +1 (443) 269-1555 x333            Baltimore, Maryland 21218   -
-                                                               -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.

Re: Trouble merging renamed but identical files - CONFLICT (rename/rename)

[Phil Hord]

On Sun, Jun 29, 2014 at 5:13 PM, Jason Pyeron <jpyeron@pdinc.us> wrote:
>> -----Original Message-----
>> From: Phil Hord
>> Sent: Sunday, June 29, 2014 16:27
>>
>> On Sun, Jun 29, 2014 at 4:20 PM, Jason Pyeron
>> <jpyeron@pdinc.us> wrote:
>> >> -----Original Message-----
>> >> From: Phil Hord
>> >> Sent: Sunday, June 29, 2014 16:09
>> >>
>> >> On Sun, Jun 29, 2014 at 11:31 AM, Phil Hord
>> >> <phil.hord@gmail.com> wrote:
>> >> > On Fri, Jun 27, 2014 at 8:42 PM, Jason Pyeron
>> >> <jpyeron@pdinc.us> wrote:
>> >> >> Sorry for the http://pastebin.com/1R68v6jt (changes the merge to
>> >> >> 1ca13ed2271d60ba93d40bcc8db17ced8545f172, and manually
>> >> reconciles the merge),
>> >> >> but it was too long to be readable in the email.
>> >>
>> >> Ok, I think I understand the issue you are trying to solve now.
>> >>
>> >> Git (rather famously[1]) does not record renames or copies.  It is
>> >> expected instead that renames and copies will be detected
>> when it is
>> >> important after the fact. This allows us to ignore rename detection
>> >> and resolution when creating project history; in the future, better
>> >> rename/copy detection will "just work" on existing repositories and
>> >> the repos themselves will not need to be adjusted.
>> >
>> > Looking at http://pastebin.com/1R68v6jt , I have a work around.
>> >
>> > In summary, 7.git cherry-pick -x HEAD..rebranding , then
>> >
>> > git merge $(echo 'Merge of
>> 1ca13ed2271d60ba93d40bcc8db17ced8545f172 branch -
>> > rebranding' |\
>> >     git commit-tree -p HEAD -p rebranding \
>> >          $(git cat-file -p HEAD | grep ^tree | sed -e
>> 's/^tree //') )
>> >
>> > Now it is perfect in the blame and log --graph.
>>
>> Yes, but your workaround unnecessarily duplicates commits and
>> complicates the history of your project. You are munging your project
>
> But I want to avoid thet complicating, while still showing that line 42 was
> modified by X. Should this be possible with a merge, without using cherry-pick?

I think it should.  But there are other complications in your project
which may be getting in the way. You are merging two branches with no
common ancestor.  When git walks down either path looking for the
source commit for each line, it finds two sources for it.  For
example, it reaches commit 39ebb06 which appears to be the origin of
all lines in that file since it has no parent. I imagine this could
act as a short-circuit to further searching.  Furthermore, I'm not
sure how git should know any better.

It seems you already have a merge point for these two branches, but I
haven't looked deeply into how that merge was done.  But I think the
multiple disconnected branch histories may be the cause of the
confusion.

> Btw I am not able to pull up https://git.wiki.kernel.org/ or
> http://git.wiki.kernel.org/


That is strange.  It works for me here, and I am just a user like you.

Phil