resent, forgot to reply to all...
I guess a bigger concern of this issue is the mess up of history. That
is, even if not doing an merge/update, just doing the 'git mv' will
messed up the file history, as shown in following:
// Add a new resources/qa/content.txt files with a new commit message:
> mkdir gitmvtest/resources/qa
> cp gitmvtest/resources/demo/content.txt gitmvtest/resources/qa/.
> git add .
>git commit -m "Add a new QA context.txt"
[master caba387] Add a new QA context.txt
1 file changed, 2 insertions(+)
// Do the git mv
> git checkout -b branch5
> git mv gitmvtest/resources gitmvtest/src/main/.
> git commit -m "Move resources to src/main/resources"
[branch5 dd44309] Move resources to src/main/resources
4 files changed, 0 insertions(+), 0 deletions(-)
rename gitmvtest/{resources/qa =>
src/main/resources/demo}/content.txt (100%) <-- WRONG
rename gitmvtest/{resources/prod =>
src/main/resources/dev}/content.txt (100%) <-- WRONG
rename gitmvtest/{resources/dev =>
src/main/resources/prod}/content.txt (100%) <-- WRONG
rename gitmvtest/{resources/demo =>
src/main/resources/qa}/content.txt (100%) <-- WRONG
// WRONG HISTORY
> git log --follow --oneline gitmvtest/src/main/resources/demo/content.txt <== demo/content.txt points to the new QA history
dd44309 Move resources to src/main/resources
caba387 Add a new QA context.txt <== WRONG HISTORY
thanks,
Bill
On Thu, Feb 25, 2016 at 6:56 AM, Stefan Beller <sbeller@xxxxxxxxxx> wrote:
> On Thu, Feb 25, 2016 at 3:49 AM, Kevin Daudt <me@xxxxxxxxx> wrote:
>> On Wed, Feb 24, 2016 at 04:38:11PM -0700, Bill Okara wrote:
>>> Hi,
>>>
>>> I noticed the following 'git mv' issue with:
>>> git version 2.6.4
>>>
>>>
>>> If there are identical files in different subfolders, 'git mv' the
>>> root folder (and/or each file individually) will mess up the file path
>>> mapping. that is, if having identical 'content.txt' file under
>>> gitmvtest
>>> |--demo/content.txt
>>> |--dev/content.txt
>>> |--prod/content.txt
>>>
>>> after doing the "git mv gitmvtest/resources
>>> gitmvtest/src/main/resources", the 'git status' will show:
>>>
>>> renamed: gitmvtest/resources/demo/content.txt ->
>>> gitmvtest/src/main/resources/demo/content.txt
>>> renamed: gitmvtest/resources/prod/content.txt ->
>>> gitmvtest/src/main/resources/dev/content.txt <== NOTE:
>>> wrongly mapped the prod/content.txt to dev/content.txt
>>> renamed: gitmvtest/resources/dev/content.txt ->
>>> gitmvtest/src/main/resources/prod/content.txt <== NOTE:
>>> wrongly mapped the dev/content.txt to prod/content.txt
>>>
>>> I tried running 'git mv' on each file individually, got the same problem:
>>> > git mv gitmvtest/resources/demo/content.txt gitmvtest/src/main/resources/demo/content.txt
>>> > git mv gitmvtest/resources/dev/content.txt gitmvtest/src/main/resources/dev/content.txt
>>> > git mv gitmvtest/resources/prod/content.txt gitmvtest/src/main/resources/prod/content.txt
>>>
>>> > git status
>>> renamed: gitmvtest/resources/demo/content.txt ->
>>> gitmvtest/src/main/resources/demo/content.txt
>>> renamed: gitmvtest/resources/prod/content.txt ->
>>> gitmvtest/src/main/resources/dev/content.txt <== WRONG
>>> renamed: gitmvtest/resources/dev/content.txt ->
>>> gitmvtest/src/main/resources/prod/content.txt <== WRONG
>>>
>>>
>>> NOTE:
>>> =======
>>> if modified the content.txt in the 3 folders to contain different
>>> data, then repeating the above 'git mv' will produce correct result,
>>>
>>> renamed: gitmvtest/resources/demo/content.txt ->
>>> gitmvtest/src/main/resources/demo/content.txt <== CORRECT
>>> renamed: gitmvtest/resources/dev/content.txt ->
>>> gitmvtest/src/main/resources/dev/content.txt <== CORRECT
>>> renamed: gitmvtest/resources/prod/content.txt ->
>>> gitmvtest/src/main/resources/prod/content.txt <== CORRECT
>>>
>>>
>>>
>>> just want to see if this is a bug, user error (on my end), or??
>>>
>>
>> This looks like the same issue as submodule--helper list has:
>> http://article.gmane.org/gmane.comp.version-control.git/287227
>
> The submodule--helper is not called from within git-mv, so it may be
> a similar but not the same issue. ;)
>
> Looking through the code, the pathspec is not treated according to the newest
> style convention, I think it is one of the last places where the
> pathspec internals
> are poked with, instead of using parse_parsespec && match_parsespec.
> (That said it is very old hence often tested code in the wild. old
> code != bad code)
>
> Stefan
--
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