git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Henri GEIST <geist.henri@laposte.net>
To: Jens Lehmann <Jens.Lehmann@web.de>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH] submodule : Add --no-separate-git-dir option to add and update command.
Date: Thu, 06 Mar 2014 02:25:28 +0100	[thread overview]
Message-ID: <1394069128.7891.29.camel@Naugrim> (raw)
In-Reply-To: <53176951.7000201@web.de>

[-- Attachment #1: Type: text/plain, Size: 3272 bytes --]

Le mercredi 05 mars 2014 à 19:13 +0100, Jens Lehmann a écrit :
> Am 03.03.2014 21:34, schrieb Henri GEIST:
> > Le lundi 03 mars 2014 à 17:45 +0000, Jens Lehmann a écrit :
> >> Am 03.03.2014 14:47, schrieb Henri GEIST:
> >>> This new option prevent git submodule <add|update> to clone the missing
> >>> submodules with the --separate-git-dir option.
> >>> Then the submodule will be regular repository and their gitdir will not
> >>> be placed in the superproject gitdir/modules directory.
> >>
> >> And what is your motivation for this? After all submodules containing
> >> a .git directory are second class citizens (because they can never be
> >> safely removed by regular git commands).
> >>
> > 
> > I recognize most people will prefer to have the .git directory separate.
> > And I do not intend to make this option the default.
> > 
> > My reasons are:
> > 
> >   - As it is not clearly stated in the doc that the gitdir is separate.
> >     The first time I have copied one module to an USB key I had a big
> >     surprise.
> 
> Oops! Could you please help us by hinting how the documentation
> could be improved here?
> 

Of course.
There is nothing in Documentation/git-submodule.txt to inform that submodules
clones are different from regular clones.
I will write and propose a patch for the documentation.
But maybe in a new thread.


> >   - This will not change anything for people not using it.
> 
> I do not agree, as they'll be seeing a new option and might use
> it to "go backward" as Junio explained in his answer.
> 
> >   - I use an other patch which I plane to send later which enable multiple
> >     level of superproject to add a gitlink to the same submodule.
> >     And in this case the superproject containing the separate gitdir will be
> >     arbitrary and depend on the processing order of the
> >     'git submodule update --recursive' command.
> 
> I don't understand that. How is that different from using different
> names (and thus different separate gitdirs) for that duplicated
> submodule? After all, the .git directory is just moved somewhere
> else in the superproject's work tree, and as the name defaults to
> the path of the submodule ...
> 

I think I should give an example.
If I have a hierarchy like this :

superproject/submodule/subsubmodule

What I often do is:

superproject --> submodule --> subsubmodule
             |                 ^
             '-----------------'

Where '-->' is a gitlink.


That mean .gitmodules and index of the superproject contain both submodule and
submodule/subsubmodule.
And also mean (and that is the point) subsubmodule is a direct 'child' of both
superproject and submodule.
In this case where should the separate gitdir of subsubmodule be placed ?
  - In superproject/modules/submodule/subsubmodule ?
  - In superproject/submodule/modules/subsubmodule ?
  - Depending on the 'git submodule update' command order ?
  - Or both ?


> >   - I have written this for myself and have using it since 2012 and send it in
> >     the hope it could be useful for someone else even if it is only a few
> >     people. But if its not the case no problem I will keep using it for myself.
> 
> Thanks.




[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 230 bytes --]

  reply	other threads:[~2014-03-06  1:25 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-03 14:47 [PATCH] submodule : Add --no-separate-git-dir option to add and update command Henri GEIST
2014-03-03 17:45 ` Jens Lehmann
2014-03-03 20:34   ` Henri GEIST
2014-03-05 18:13     ` Jens Lehmann
2014-03-06  1:25       ` Henri GEIST [this message]
2014-03-06 19:48         ` Jens Lehmann
2014-03-06 20:15           ` Henri GEIST
2014-03-06 20:51             ` Jens Lehmann
2014-03-06 22:20               ` Henri GEIST
2014-03-07 23:00                 ` Jens Lehmann
2014-03-10  9:08                   ` Henri GEIST
2014-03-10 20:32                     ` Heiko Voigt
2014-03-11  9:55                       ` Henri GEIST
2014-03-11 20:11                         ` Heiko Voigt
2014-03-11 22:07                           ` Henri GEIST
2014-03-03 19:22 ` Junio C Hamano

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=1394069128.7891.29.camel@Naugrim \
    --to=geist.henri@laposte.net \
    --cc=Jens.Lehmann@web.de \
    --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).