From: Jens Lehmann <Jens.Lehmann@web.de>
To: Semen Vadishev <semen.vadishev@tmatesoft.com>
Cc: git@vger.kernel.org
Subject: Re: Delete gitlink entry but keep .gitmodules file unmodified
Date: Wed, 18 Apr 2012 15:42:58 +0200 [thread overview]
Message-ID: <4F8EC4E2.6070507@web.de> (raw)
In-Reply-To: <4F8EBF5D.5070301@tmatesoft.com>
Am 18.04.2012 15:19, schrieb Semen Vadishev:
> Suppose one has a properly initialized submodule in a tree like this:
>
> $ git ls-tree HEAD
> 100644 blob d208248ba4ab1d1791dc27f451dcaedb87dc19e1 .gitmodules
> 160000 commit ec633ea81e3cf64c3735ef4acd5ff9a490ed54eb ext
> 100644 blob 597d6924118c00054efd526d9e48f68198f7da12 file.txt
>
> $ git show HEAD:.gitmodules
> [submodule "ext"]
> path = ext
> url = $URL
>
> Then one pulls a modification that replaces 'ext' gitlink by some blob or tree entry, but keeps '.gitmodules' the same:
>
> $ git ls-tree HEAD
> 100644 blob d208248ba4ab1d1791dc27f451dcaedb87dc19e1 .gitmodules
> 040000 tree 82e3a754b6a0fcb238b03c0e47d05219fbf9cf89 ext
> 100644 blob 597d6924118c00054efd526d9e48f68198f7da12 file.txt
>
> Are there any possible downsides of such modification we should be aware of?
Yes, unfortunately current git isn't able to do that (even though work
is ongoing to make future versions handle that just fine). Right now
the populated submodule "ext" won't be removed when you switch to a
branch where it doesn't exist. If the new branch has a tree there,
you'll almost certainly get an error when trying to switch to it as
that would overwrite files left over from the submodule (end even if
it doesn't, you'll might get lots of untracked files in the tree
after the checkout).
As a workaround you could use a symbolic link (assuming you FS supports
that) and switch that around between two different directories:
100644 .gitmodules
100644 ext -> ext_sub
160000 ext_sub
100644 .gitmodules
100644 ext -> ext_tree
160000 ext_tree
If you then add ext_sub and ext_tree to the .gitignore of each side it
isn't present in, everything should work just fine (and when git learns
to handle that case, you can get rid of that workaround for future
commits).
next prev parent reply other threads:[~2012-04-18 13:43 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-18 13:19 Delete gitlink entry but keep .gitmodules file unmodified Semen Vadishev
2012-04-18 13:42 ` Jens Lehmann [this message]
2012-04-18 14:34 ` Semen Vadishev
2012-04-19 9:10 ` Jens Lehmann
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F8EC4E2.6070507@web.de \
--to=jens.lehmann@web.de \
--cc=git@vger.kernel.org \
--cc=semen.vadishev@tmatesoft.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.
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 NNTP newsgroup(s).