git@vger.kernel.org mailing list mirror (one of many)
 help / Atom feed
From: Stefan Beller <sbeller@google.com>
To: Christian.Zitzmann@continental-corporation.com
Cc: git <git@vger.kernel.org>
Subject: Re: Issue in switching branches with different submodules
Date: Fri, 23 Feb 2018 16:36:07 -0800
Message-ID: <CAGZ79kZPFF-htksHsnRSDpScWoCLap5Az+s=09htx_0Tz2_u8A@mail.gmail.com> (raw)
In-Reply-To: <OF65A78D43.F69630E3-ONC125823B.0057EE88-C125823C.0042D7B0@continental-corporation.com>

On Thu, Feb 22, 2018 at 4:10 AM,
<Christian.Zitzmann@continental-corporation.com> wrote:
> Hello,
> I've found an issue in git when working with submodules.
> My Project is set up using hundreds of components by submodules (and
> nested submodules), that are independent created in central development
> groups.
> Now it occurs that the structure of the submodules is changed over time.
>
> E.g.
> Project1(OldBranch)
>   - ComponentX/SubComp1 -> ssh://Server/ComponentX/SubComp1
>   - ComponentX/SubComp2 -> ssh://Server/ComponentX/SubComp2
>   - ComponentX/SubComp2 -> ssh://Server/ComponentX/SubComp2
>
> Project1(Masster)
>   - ComponentX-> ssh://Server/ComponentX
>
> There is both a repository for the old subcomponents, and for the new
> Component on the server.

ok, so you're saying this is all a client side problem?

> When trying to switch between the branches all git commands are failing.
> It seems like most git commands are not creating the SubComponent
> submodules because the .git file from the Component is not deleted
>
> A 'git submodule sync' fails with:
> fatal: Not a git repository:
> D:/Project1/ComponentX/../.git/modules/ComponentX
>
> Looking into the folders I see:
> D:/Project1/.git/modules/ComponentX/SubComp1
> D:/Project1/.git/modules/ComponentX/SubComp2
> D:/Project1/.git/modules/ComponentX/SubComp3
> D:/Project1/ComponentX/.git (file)

As a quick workaround to repair your current corrupted repo,
you can just delete the .git file, which presumably contains

  gitdir: ../.git/modules/ComponentX

I think this reveals (yet another) problem that we have with
with submodule names. Submodules used to have its git directory
inside its own working tree, but now they are encouraged to have
it in the superproject in .git/modules/<name>.

Considering your submodules
    "ComponentX/..."
    "ComponentX"
you may have a directory conflict, because there is already a
directory named "ComponentX" so we cannot store the later
submodules git directory.

> A 'git submodule update --init also fails with this folders
> Neither a forced checkout or a hard reset is working.

For this problem you could manually repair the superproject by
giving better names to submodules, such that you have unique
names, such that one is not the prefix directory of another.

> Similar errors can occur when switching between branches with a different
> number of components used as submodules vs. project specific content.
> As a result it happens that people are working with an incosistend state
> of the working directory.
>
> My expectation would be that, when switching between branches/commits with
> a git checkout --recurse-submodules the branche including all submodules
> is checked out fully to exactly the state of the desired branch/commit
> I.e the following usecases are an issue
> - Deleted submodule
> - Added submodule as replacement of local directory
> - Changed remote location of submodule (One component is available from
> different providers having individual repositories)
> - Restructured Component (see example)

I agree with this expectation and we'd need to discuss how to make this happen
as the submodule naming scheme doesn't allow for this to work flawlessly.

> Similar issues are existing when creating the new structure to commit it,
> but here the error is more obvious and people are manually deleting as
> much as required to get the new submodules correctly in.
>
> Best regards

Thanks for this bug report; I needed some time to ingest it and come up
with speculation on what might be the cause. (Not sure if it is the correct
root cause though)

Thanks,
Stefan

      reply index

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-22 12:10 Christian.Zitzmann
2018-02-24  0:36 ` Stefan Beller [this message]

Reply instructions:

You may reply publically 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='CAGZ79kZPFF-htksHsnRSDpScWoCLap5Az+s=09htx_0Tz2_u8A@mail.gmail.com' \
    --to=sbeller@google.com \
    --cc=Christian.Zitzmann@continental-corporation.com \
    --cc=git@vger.kernel.org \
    /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

git@vger.kernel.org mailing list mirror (one of many)

Archives are clonable:
	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.org/gmane.comp.version-control.git

 note: .onion URLs require Tor: https://www.torproject.org/
       or Tor2web: https://www.tor2web.org/

AGPL code for this site: git clone https://public-inbox.org/ public-inbox