git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Brandon Williams <bmwill@google.com>,
	Stefan Beller <sbeller@google.com>,
	"git\@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: [BUG?] gitlink without .gitmodules no longer fails recursive clone
Date: Sat, 10 Jun 2017 20:12:25 +0900	[thread overview]
Message-ID: <xmqqr2ys14h2.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <20170610071342.gdmpgjqlho2xfvdt@sigill.intra.peff.net> (Jeff King's message of "Sat, 10 Jun 2017 03:13:43 -0400")

Jeff King <peff@peff.net> writes:

> Certainly I think it _could_ be a valid state. But traditionally it
> caused "clone --recursive" to barf. And from what Stefan and Brandon
> have said, we are moving in the opposite direction entirely, with
> .gitmodules becoming the source of truth.
> 
> I could see arguments for going in either direction (gitlinks versus
> .gitmodules as source of truth for submodules). But it bothers me that
> it's so easy to create a state that will behave in a confusing manner.
> ...
> Allowing both is not in itself wrong.  But because we provide no
> guidance for the expert route, it's easy to shoot yourself in the foot
> and not even realize it. Which is why I suggested a warning and not
> forbidding the operation. Or better still, an advise() block that tells
> you how to recover (probably "git submodule add", though it might need
> to learn to handle already-present gitlinks). And which can be disabled
> if you really are an expert user.

Yeah, the current situation is bad in that having both .gitmodules
file and gitlinks in a tree allows for redundant pieces of
information to go out of sync and result in contradiction.  A gitlink
without an entry in the .gitmodules file is an obvious example.  An
entry in .gitmodules file whose path does not have a gitlink in the
tree would also be a broken case.  

While "git submodule" was the only/primary interface to the
submodule, it was rather easy to explain that ".gitmodules need to
be consistent with the index and the tree iff you do 'git submodule'
thing" (implying "if you only use gitlinks to bind two or more
projects locally without sharing with others, you do not need 'git
submodule' and you do not need .gitmodules"), but with the recent
push to add "--recurse-submodules" to everything, the extent of what
was historically "iff you do 'git submodule' thing" is getting
larger and it becomes more and more important to keep .gitmodules
consistent with gitlinks in the tree that house it.

I find it a bit sad, but I do not think of a better way X-<.



  reply	other threads:[~2017-06-10 11:12 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-06  3:56 [BUG?] gitlink without .gitmodules no longer fails recursive clone Jeff King
2017-06-06 18:01 ` Stefan Beller
2017-06-06 18:10   ` Brandon Williams
2017-06-06 18:39     ` Jeff King
2017-06-09 23:19       ` Jeff King
2017-06-10  2:10         ` Junio C Hamano
2017-06-10  7:13           ` Jeff King
2017-06-10 11:12             ` Junio C Hamano [this message]
2017-06-12  5:30           ` Stefan Beller
2017-06-13  9:14         ` Jeff King
2017-06-13  9:24           ` [PATCH 1/2] add: warn when adding an embedded repository Jeff King
2017-06-13 17:07             ` Stefan Beller
2017-06-13 17:16               ` Brandon Williams
2017-06-14  6:36               ` Jeff King
2017-06-14 10:54                 ` [PATCH v2 0/2] " Jeff King
2017-06-14 10:58                   ` [PATCH v2 1/2] add: " Jeff King
2017-06-14 10:58                   ` [PATCH v2 2/2] t: move "git add submodule" into test blocks Jeff King
2017-06-14 17:53                 ` [PATCH 1/2] add: warn when adding an embedded repository Stefan Beller
2017-06-15  6:01                   ` Jeff King
2017-06-13 17:16             ` Junio C Hamano
2017-06-14  6:38               ` Jeff King
2017-06-13  9:24           ` [PATCH 2/2] t: move "git add submodule" into test blocks Jeff King
2017-06-13 17:15             ` 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

  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=xmqqr2ys14h2.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=bmwill@google.com \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    --cc=sbeller@google.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.
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).