git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Philip Oakley" <philipoakley@iee.org>
To: "Stefan Beller" <sbeller@google.com>,
	"Orgad Shaneh" <orgads@gmail.com>,
	"Dakota Hawkins" <dakotahawkins@gmail.com>
Cc: "git" <git@vger.kernel.org>
Subject: Re: Submodule/contents conflict
Date: Tue, 25 Apr 2017 00:33:38 +0100	[thread overview]
Message-ID: <4BF0A1BFFFFD421EB8C5F7E6FEF14357@PhilipOakley> (raw)
In-Reply-To: CAGZ79kZ5440r1EHOVP3eXxe5u=u16y_jXTA0C4hLJA2kUkF-kg@mail.gmail.com

From: "Stefan Beller" <sbeller@google.com>
> On Mon, Apr 24, 2017 at 1:06 AM, Orgad Shaneh <orgads@gmail.com> wrote:
>> Hi,
>>
>> I've noticed a strange behavior with submodule/content conflict. My
>> current Git version is 2.12.2, but the problem exists since I
>> remember.
>>
>> Branch A has a submodule.
>> In branch B which diverged from A, I replaced the submodule with its 
>> contents.
>>
>> Now, every time I merge A into B, and A had changed the submodule
>> reference, all the files inside the ex-submodule directory in B are
>> being "re-added".
>>
>> Moreover, aborting the merge prints an error, but seems to work
>> nevertheless, and if I run git reset --hard all the files in that
>> directory are actually written to the disk, even though they haven't
>> changed at all.
>>

This is almost the same as just reported by 'vvs' [1] 
https://public-inbox.org/git/CAM1zWBtfgHT=pT0pidQo1HD=DfrXLG3gNaUvs0vZKvYfG1BHFw@mail.gmail.com/, 
originally on the 'git user' list 
https://groups.google.com/forum/?hl=en#!topic/git-users/9ziZ6yq-BfU

It also has a similarity to 
https://public-inbox.org/git/1492287435.14812.2.camel@gmail.com/  regarding 
how checkout operates.

It does feel as if there are two slightly different optimisations that could 
be used when the desired file pre-exists in the worktree, but isn't 
immediately known to the index.


>> When the submodule is small, it might be ok. But in my project we have
>> a huge submodule with ~16K files, and on each merge all the files are
>> listed, and even mixed reset takes several minutes.

That sounds like a wait that is not wanted!
>>
>
> A similar bug report
> https://public-inbox.org/git/CAG0BQX=wvpkJ=PQWV-NbmhuPV8yzvd_KYKzJmsfWq9xStZ2bnQ@mail.gmail.com/
>
> "checkout --recurse-submodules" (as mentioned in that report)
> made it into Git by now, but this bug goes unfixed, still.
>
>> The following script demonstrates this:
>> #!/bin/sh
>>
>> rm -rf super sub
>> mkdir sub
>> cd sub
>> git init
>> touch foo
>> git add foo
>> git commit -m 'Initial commit'
>> mkdir ../super; cd ../super
>> git init
>> git submodule add ../sub
>> touch foo; git add foo sub
>> git commit -m 'Initial commit'
>> git checkout -b update-sub
>> git update-index --cacheinfo 
>> 160000,aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,sub
>> git commit -m 'Update submodule'
>> git checkout -b remove-sub HEAD^
>> git rm sub
>> mkdir sub
>> touch sub/foo sub/bar
>> git add sub
>> git commit -m 'Replaced submodule with contents'
>> git checkout -b remove-2 HEAD^
>> git merge --no-ff remove-sub
>> git merge update-sub
>> # Adding sub/foo
>> # Adding sub/bar
>> # CONFLICT (modify/delete): sub deleted in HEAD and modified in
>> update-sub. Version update-sub of sub left in tree at sub~update-sub.
>> # Automatic merge failed; fix conflicts and then commit the result.
>> git merge --abort
>> # error: 'sub' appears as both a file and as a directory
>> # error: sub: cannot drop to stage #0
>>
>> - Orgad
>
--
Philip 


  reply	other threads:[~2017-04-24 23:33 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-24  8:06 Submodule/contents conflict Orgad Shaneh
2017-04-24 17:40 ` Stefan Beller
2017-04-24 23:33   ` Philip Oakley [this message]
2017-04-24 23:43     ` Stefan Beller
2017-04-25  3:22       ` Jeff King
2017-04-25  3:39         ` Jeff King
2017-04-27 22:52         ` Philip Oakley
2017-04-28  8:30           ` Jeff King
2017-05-01  0:15             ` Junio C Hamano
2017-04-25 11:10       ` Philip Oakley
2017-04-26  2:51         ` Junio C Hamano
2017-04-26 17:41           ` Stefan Beller
2017-04-27  0:25             ` Junio C Hamano
2017-04-27  0:29             ` Junio C Hamano
2017-04-27 22:07           ` Philip Oakley
2017-04-28  2:08             ` Junio C Hamano
2017-04-25  2:12   ` Junio C Hamano
2017-04-25 15:57     ` Stefan Beller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4BF0A1BFFFFD421EB8C5F7E6FEF14357@PhilipOakley \
    --to=philipoakley@iee.org \
    --cc=dakotahawkins@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=orgads@gmail.com \
    --cc=sbeller@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).