From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=3.0 tests=FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 36B96C2D0F4 for ; Wed, 8 Apr 2020 16:23:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 17F3520784 for ; Wed, 8 Apr 2020 16:23:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729903AbgDHQXI convert rfc822-to-8bit (ORCPT ); Wed, 8 Apr 2020 12:23:08 -0400 Received: from smtp5-g21.free.fr ([212.27.42.5]:23316 "EHLO smtp5-g21.free.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728473AbgDHQXH (ORCPT ); Wed, 8 Apr 2020 12:23:07 -0400 Received: from zimbra39-e7.priv.proxad.net (unknown [172.20.243.189]) by smtp5-g21.free.fr (Postfix) with ESMTP id 015C36001D; Wed, 8 Apr 2020 18:23:05 +0200 (CEST) Date: Wed, 8 Apr 2020 18:23:04 +0200 (CEST) From: ydirson@free.fr To: Elijah Newren Cc: git Message-ID: <907083995.810443848.1586362984955.JavaMail.root@zimbra39-e7> In-Reply-To: <1540391834.807942587.1586332379241.JavaMail.root@zimbra39-e7> Subject: Re: [BUG] submodule move badly handled by git-rebase MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-Originating-IP: [91.170.159.152] X-Mailer: Zimbra 7.2.0-GA2598 (ZimbraWebClient - FF3.0 (Linux)/7.2.0-GA2598) X-Authenticated-User: ydirson@free.fr Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org This may be related to another funky behaviour I just noticed, linked to moving submodules around: - when initially created, the $TOP/orig-name submodule's git-dir gets created in $TOP/.git/modules/orig-name, with $TOP/.git/modules/orig-name/config containing a core.worktree value pointing to $TOP/orig-name - when moving the submodule, only the submodule worktree is moved, the git-dir being the same $TOP/.git/modules/orig-name, where the core.worktree still points to the old location Other unwanted behaviour include "git clean" reporting (and possibly cleaning) files from the wrong work tree - it took me head-scratching to understand why "git clean -fdx" was ignoring all the cruft I had in this worktree... Why is it that we need a core.worktree setting at all in there ? Removing it allows "git clean" to do what's expected of it. OTOH it does not make the original problem go away... ----- Mail original ----- > De: ydirson@free.fr > À: "Elijah Newren" > Cc: "git" > Envoyé: Mercredi 8 Avril 2020 09:52:59 > Objet: Re: [BUG] submodule move badly handled by git-rebase > > Hi Elijah, > > > Hi Yann, > > > > On Tue, Apr 7, 2020 at 9:36 AM wrote: > > > > > > Hello all, > > > > > > When rebasing commits involving move of a submodule, git-rebase > > > fails to > > > record in index the "add" part of the rename. This leaves the > > > workdir > > > dirty and the rebase gets stopped. > > > > > > fast-export of a testcase is attached. To reproduce, just > > > "git rebase -i", add a "break" before the move commit, > > > use this to introduce some noise, and watch. > > > > > > Best regards, > > > -- > > > Yann > > > > > > > > > (master)$ git rebase -i HEAD^^ > > > hint: Waiting for your editor to close the file... Waiting for > > > Emacs... > > > Stopped at b0e1b00... add submodule > > > > > > (master|REBASE 2/3)$ echo >>README > > > > > > (master|REBASE 2/3)$ git commit -a -m noise > > > [detached HEAD d67c886] noise > > > 1 file changed, 1 insertion(+) > > > > > > (master|REBASE 2/3)$ git rebase --continue > > > Adding as subdir/gitlab-oe~08e230f... move submodule instead > > > error: could not apply 08e230f... move submodule > > > Resolve all conflicts manually, mark them as resolved with > > > "git add/rm ", then run "git rebase > > > --continue". > > > You can instead skip this commit: run "git rebase --skip". > > > To abort and get back to the state before "git rebase", run "git > > > rebase --abort". > > > Could not apply 08e230f... move submodule > > > > > > (master|REBASE 3/3)$ git st > > > interactive rebase in progress; onto c21ef8e > > > Last commands done (3 commands done): > > > break > > > pick 08e230f move submodule > > > (see more in file .git/rebase-merge/done) > > > No commands remaining. > > > You are currently rebasing branch 'master' on 'c21ef8e'. > > > (fix conflicts and then run "git rebase --continue") > > > (use "git rebase --skip" to skip this patch) > > > (use "git rebase --abort" to check out the original branch) > > > > > > Changes to be committed: > > > (use "git restore --staged ..." to unstage) > > > modified: .gitmodules > > > deleted: gitlab-oe > > > > > > Unmerged paths: > > > (use "git restore --staged ..." to unstage) > > > (use "git add ..." to mark resolution) > > > added by them: subdir/gitlab-oe > > > > > > (master|REBASE 3/3)$ > > > > I couldn't figure out how to duplicate. Maybe I did something > > wrong, > > but it was: > > # download your fast-export stream > > git init temp > > cd temp > > cat ~/Downloads/submodule-move.fexp | git fast-import --quiet > > git checkout master > > git rebase -i HEAD^^ > > # Insert a line with just 'b' between the two pick lines; save > > and > > exit and when it breaks: > > echo >>README > > git commit -a -m noise > > git rebase --continue > > > > After the rebase --continue, the rebase completes just fine > > applying > > the patch with the submodule move. git range-diff master@{1}... > > will > > show that I inserted a new commit in the middle. git log --raw > > looks > > good, showing all four commits including the moved submodule at the > > end. > > You're right, I missed crucial point: no problem appears unless the > submodule > is initialized. After checking out the master branch (and possibly > issuing > "git reset --hard" to make sure everything is clean), it is necessary > to > run "git submodule update --init". > > > > What git version did you use? Do you need special settings (what's > > in > > your ~/.gitconfig and your .git/config)? > > This is 2.26.0, but like my other report I had it with 2.25.1 > already. > Just tested with an clear config (HOME and GIT_CONFIG_NOSYSTEM set) > and > the problem triggers as well. > > Best regards, > -- > Yann > >