From: David Turner <David.Turner@twosigma.com>
To: "git@vger.kernel.org" <git@vger.kernel.org>
Subject: Submodules: two confusing situations
Date: Tue, 1 Nov 2016 22:13:18 +0000 [thread overview]
Message-ID: <6533af94ebd74952b75e51c5609d8c20@exmbdft7.ad.twosigma.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1341 bytes --]
Consider the following two cases:
We have commit X and commit Y. X is an ancestor of Y.
We're at X and doing get checkout Y -- or we're at Y and we're doing
git checkout X.
Case 1: Between X and Y, we have deleted a submodule.
In order to move from X to Y, git removes the submodule
from the working tree.
Case 2: Between X and Y, we have instead added a submodule. In order
to move from Y to X (that is, the opposite direction), git *does not*
remove the submodule from the tree; instead, it gives a warning and
leaves the submodule behind.
I don't understand why these two cases are not symmetric.
--
Perhaps relatedly, consider the attached shell-script, which I have not yet made into a full git test because I'm not sure I understand the issues fully.
It creates three commits:
Commit 1 adds a submodule
Commit 2 removes that submodule and re-adds it into a subdirectory (sub1 to sub1/sub1).
Commit 3 adds an unrelated file.
Then it checks out commit 1 (first deinitializing the submodule to avoid case 2 above), and attempts to cherry-pick commit 3. This seems like it ought to work, based on my understanding of cherry-pick. But in fact it gives a conflict on the stuff from commit 2 (which is unrelated to commit 3).
This is confusing to me, and looks like a bug. What am I missing?
[-- Attachment #2: submodule-merge.sh --]
[-- Type: application/octet-stream, Size: 1021 bytes --]
#!/bin/bash
set -euo pipefail
mkdir demo
cd demo
git init main
(
git init sub1 &&
cd sub1 &&
dd if=/dev/urandom of=f bs=40 count=1 &&
git add f &&
git commit -m f
)
(
cd main &&
git submodule add ../sub1 sub1 &&
> sub2 && git add sub2 &&
git commit -m 'add both submodules' &&
git tag start
)
#make a commit that replaces sub1 in a l->d transition
(
cd main &&
git rm sub1 &&
mkdir sub1 &&
git submodule add ../sub1 sub1/sub1 &&
git commit -m 'f to d' &&
#And another commit that just adds a random file.
>foo &&
git add foo &&
git commit -m 'foo' &&
git tag l-to-d
# Now we want to get back to the start state
git submodule deinit sub1/sub1 &&
git checkout -b sub2 start &&
# Finally, we want to cherry-pick an innocuous-looking commit from a branch
# where we have previously made the l->d change
# This should not fail, but does.
git cherry-pick l-to-d
)
next reply other threads:[~2016-11-01 22:13 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-01 22:13 David Turner [this message]
2016-11-01 22:56 ` Submodules: two confusing situations 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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6533af94ebd74952b75e51c5609d8c20@exmbdft7.ad.twosigma.com \
--to=david.turner@twosigma.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
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).