All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Beller <sbeller@google.com>
To: "Billy O'Neal (VC LIBS)" <bion@microsoft.com>
Cc: "git@vger.kernel.org" <git@vger.kernel.org>,
	"Stephan T. Lavavej" <stl@exchange.microsoft.com>,
	Cody Miller <codym@microsoft.com>
Subject: Re: Bug report: git reset --hard does not fix submodule worktree
Date: Mon, 6 Nov 2017 12:50:42 -0800	[thread overview]
Message-ID: <CAGZ79kZRa6=PNtRoVMzM89ek+9uv9_+C+3-hNAaJ_W=YoeWj-w@mail.gmail.com> (raw)
In-Reply-To: <BN6PR21MB0114B8ECD6E8A158FB4A6FBFCB520@BN6PR21MB0114.namprd21.prod.outlook.com>

On Fri, Nov 3, 2017 at 5:46 PM, Billy O'Neal (VC LIBS)
<bion@microsoft.com> wrote:
> Hello, Git folks. I managed to accidentally break the our test lab by attempting to git mv a directory with a submodule inside. It seems like if a reset does an undo on a mv, the workfold entry should be fixed to put the submodule in its old location. Consider the following sequence of commands:
>
> Setup a git repo with a submodule:
> mkdir metaproject
> mkdir upstream
> cd metaproject
> git init
> cd ..\upstream
> git init
> echo hello > test.txt
> git add -A
> git commit -m "an example commit"
> cd ..\metapoject
> mkdir start
> git submodule add ../upstream start/upstream
> git add -A
> git commit -m "Add submodule in start/upstream."
>
> Move the directory containing the submodule:
> git mv start target
> git add -A
> git commit -m "Moved submodule parent directory."
>
> Check that the worktree got correctly fixed by git mv; this output is as expected:
> type .git\modules\start\upstream\config
> [core]
>         repositoryformatversion = 0
>         filemode = false
>         bare = false
>         logallrefupdates = true
>         symlinks = false
>         ignorecase = true
>         worktree = ../../../../target/upstream
> [remote "origin"]
>         url = C:/Users/bion/Desktop/upstream
>         fetch = +refs/heads/*:refs/remotes/origin/*
> [branch "master"]
>         remote = origin
>         merge = refs/heads/master
>
> Now try to go back to the previous commit using git reset --hard:
> git log --oneline
>  1f560be (HEAD -> master) Moved submodule parent directory.
>  a5977ce Add submodule in start/upstream.
> git reset --hard a5977ce
>  warning: unable to rmdir target/upstream: Directory not empty
>  HEAD is now at a5977ce Add submodule in start/upstream.
>
> Check that the worktree got fixed correctly; it did not:
> type .git\modules\start\upstream\config
> [core]
>         repositoryformatversion = 0
>         filemode = false
>         bare = false
>         logallrefupdates = true
>         symlinks = false
>         ignorecase = true
>         worktree = ../../../../target/upstream
> [remote "origin"]
>         url = C:/Users/bion/Desktop/upstream
>         fetch = +refs/heads/*:refs/remotes/origin/*
> [branch "master"]
>         remote = origin
>         merge = refs/heads/master
>
> Is git reset intended to put the submodule in the right place?
>
> Thanks folks!

git-reset sounds like it ought to put submodules back into another directory.
Historically git-reset did not touch submodules at all; a recent
release introduced
the --recurse-submodules flag for git-reset, which would cover this situation.
However that particular situation (with moving the submodules) seems to be
not covered yet,

./t7112-reset-submodule.sh
...
not ok 69 - git reset --hard: replace submodule with a directory must
fail # TODO known breakage



> If not, is there a command we can run before/after reset to restore consistency?

The submodule "fix-it-all" command would be

    git submodule update --init --recursive

IMHO.

      reply	other threads:[~2017-11-06 20:50 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-04  0:46 Bug report: git reset --hard does not fix submodule worktree Billy O'Neal (VC LIBS)
2017-11-06 20:50 ` Stefan Beller [this message]

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='CAGZ79kZRa6=PNtRoVMzM89ek+9uv9_+C+3-hNAaJ_W=YoeWj-w@mail.gmail.com' \
    --to=sbeller@google.com \
    --cc=bion@microsoft.com \
    --cc=codym@microsoft.com \
    --cc=git@vger.kernel.org \
    --cc=stl@exchange.microsoft.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.