git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Sam Kuper <sam.kuper@uclmail.net>
To: git@vger.kernel.org
Cc: Stefan Beller <sbeller@google.com>,
	Thomas Braun <thomas.braun@virtuell-zuhause.de>
Subject: Re: Branch switching with submodules where the submodule replaces a folder aborts unexpectedly
Date: Tue, 19 Jun 2018 17:03:25 +0100	[thread overview]
Message-ID: <CAD-JurKx76FjVhk6QvmZ-BH=3RfmuA998KF+GRe8Kb+oB6pm8A@mail.gmail.com> (raw)

On 12 Oct 2017 at 11:48 Thomas Braun wrote:
> On 9 Oct 2017 at 23:59, Stefan Beller wrote:
>> On 9 Oct 2017 at 14:29, Thomas Braun wrote:
>>> I'm currently in the progress of pulling some subprojects in a git repository of mine into their
>>> own repositories and adding these subprojects back as submodules.
>>>
>>> While doing this I enountered a potential bug as checkout complains on branch switching that a
>>> file already exists. [...]
>>>
>>> `error: The following untracked working tree files would be overwritten by checkout:`

I am currently attempting the same thing, and experiencing the same
bug, using Git 2.17.1.


>> (And I presume you know about --recurse-submodules as a flag for git-checkout)

The behaviour seems to be the same regardless of whether I use the
--recurse-submodules flag with git-checkout.


>> This is consistent with our tests, unfortunately. [...]
>>
>>> If I'm misusing git here I'm glad for any advice.
>>
>> You are not.
>
> Glad to know that.

I was also glad to see this reassurance :)

It might have been nice if the reassurance came at an earlier stage,
however: at the CLI, rather than only after searching the mailing
list. A user who does not think to do the latter might well labour
under the misapprehension that they have done something wrong, rather
than encountered a bug. Perhaps, if the bug is not going to be fixed
terribly soon, a sentence or two could be added to the error message
explaining the situation and advising the user of a workaround?

Speaking of which, what is a good workaround in this case?

`git checkout --force <branch>`?


>> Apart from this bug report, would you think that such filtering of
>> trees into submodules (and back again) might be an interesting feature
>> of Git or are these cases rare and special?
>
> For me not particularly. In my case it is a one time thing going from an embedded project folder to a submodule.

The option to convert an existing directory into a submodule is
something that I think developers like to have available. It seems
intuitive: "Oh, I see now that what this directory holds is
effectively a separate project. Let me check out a new branch, and
replace the directory with a submodule on that branch. Assuming it
goes well, then I will afterwards merge this new branch into master."

Regardless, the bug has clearly been giving people headaches for
several years (forgive me if you were already aware of these data
points):

- https://ryansechrest.com/2014/03/git-error-switching-branch-replacing-directory-submodule/

- http://blog.dcycle.com/blog/105/gitsubmodulizing-and-gitflow/

- https://stackoverflow.com/q/9299063

- https://stackoverflow.com/a/48402543

- https://stackoverflow.com/q/24091246

- https://stackoverflow.com/q/29372450

- https://github.com/supercollider/supercollider/issues/2001

- https://github.com/supercollider/supercollider/issues/2221

Thank you to Thomas for reporting this issue to the mailing list, and
to Stefan for the helpful reply. Thanks as always to the Git
maintainers, and good luck with fixing this bug :)

             reply	other threads:[~2018-06-19 16:03 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-19 16:03 Sam Kuper [this message]
  -- strict thread matches above, loose matches on Subject: below --
2017-10-09 21:29 Branch switching with submodules where the submodule replaces a folder aborts unexpectedly Thomas Braun
2017-10-09 21:59 ` Stefan Beller
2017-10-12 11:48   ` Thomas Braun

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAD-JurKx76FjVhk6QvmZ-BH=3RfmuA998KF+GRe8Kb+oB6pm8A@mail.gmail.com' \
    --to=sam.kuper@uclmail.net \
    --cc=git@vger.kernel.org \
    --cc=sbeller@google.com \
    --cc=thomas.braun@virtuell-zuhause.de \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).