git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jens Lehmann <Jens.Lehmann@web.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>, git@vger.kernel.org
Subject: Re: [PATCH] git submodule: add submodules with git add -f <path>
Date: Tue, 06 Jul 2010 23:51:14 +0200	[thread overview]
Message-ID: <4C33A552.5060008@web.de> (raw)
In-Reply-To: <7vmxu572w5.fsf@alter.siamese.dyndns.org>

Am 06.07.2010 04:36, schrieb Junio C Hamano:
> Ævar Arnfjörð Bjarmason  <avarab@gmail.com> writes:
> 
>> Resubmitting this as a non-RFC.
> 
> I don't recall any negative nor supporting discussion on this one.  Will
> queue in 'pu' to see if people who do care about submodules complain.

First: I think this patch fixes a bug. Without it "git submodule add"
leaves the work tree in an inconsistent state when either .gitmodules
or the submodule path are ignored: the submodule is checked out and
populated but the path and/or a new .gitmodules file is not added to
the index. And even worse: The advice of the failed "git add" called
from the script that using "-f" might help is misleading here, as
"git submodule add" doesn't know this option.

But while I think adding the --force option to the "git add .gitmodules"
makes perfect sense (as the submodule can't be successfully added until
it is recorded in this file and there is really no point in ignoring
.gitmodules when you decide to use submodules), I'm not so sure about
what to do when the submodule path itself is ignored.

I see two possible behaviors here:

a) We just ignore .gitignore and add the submodule anyways (which is
   what this patch does)

b) We do the same a "git add <ignored file>" does: Print an error
   message, maybe even tell the user to use a - still to be added -
   "--force" (or "-f") option and exit. But without checking out the
   submodule first nor adding or changing .gitmodules.

IMHO b) is more consistent with the current behavior of "git add". And
when you later decide that the submodules files should live in the
superproject and you drop the submodule, the then probably still
present entry in .gitignore might really shoot you in the foot when
you add new files there and they won't show up because they are still
ignored.

What do others think?

  reply	other threads:[~2010-07-06 21:51 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-02 19:22 [PATCH/RFC] git submodule: add submodules with git add -f <path> Ævar Arnfjörð Bjarmason
2010-07-05 17:33 ` [PATCH] " Ævar Arnfjörð Bjarmason
2010-07-06  2:36   ` Junio C Hamano
2010-07-06 21:51     ` Jens Lehmann [this message]
2010-07-06 22:33       ` Ævar Arnfjörð Bjarmason
2010-07-09 22:18         ` [PATCH] git add: Add the "--ignore-missing" option for the dry run Jens Lehmann
2010-07-12 22:14           ` Junio C Hamano
2010-07-17 15:11             ` [PATCH] git submodule add: Require the new --force option to add ignored paths Jens Lehmann
2010-07-17 15:53               ` [PATCH] git submodule add: Remove old docs about implicit -f Ævar Arnfjörð Bjarmason
2010-07-17 16:26                 ` Jens Lehmann

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=4C33A552.5060008@web.de \
    --to=jens.lehmann@web.de \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.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).