git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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
)

             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).