git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Henri GEIST <geist.henri@laposte.net>
To: Andrew Keller <andrew@kellerfarm.com>
Cc: Junio C Hamano <gitster@pobox.com>,
	Git List <git@vger.kernel.org>,
	Jens Lehmann <Jens.Lehmann@web.de>
Subject: Re: [PATCH/RFC] Documentation: Say that submodule clones use a separate gitdirs.
Date: Mon, 10 Mar 2014 08:52:26 +0100	[thread overview]
Message-ID: <1394437946.7891.44.camel@Naugrim> (raw)
In-Reply-To: <B2A4F350-1F20-4ABA-80A6-CF244DD7FAFD@kellerfarm.com>

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

Le dimanche 09 mars 2014 à 19:24 -0400, Andrew Keller a écrit :
> On Mar 7, 2014, at 7:50 PM, Henri GEIST wrote:
> > Le vendredi 07 mars 2014 à 15:37 -0800, Junio C Hamano a écrit :
> >> Henri GEIST <geist.henri@laposte.net> writes:
> >> 
> >>> This information is technical in nature but has some importance for general users.
> >>> As this kind of clone have a separate gitdir, you will have a surprise if you
> >>> copy past the worktree as the gitdir will not come together.
> >> 
> >> I am not sure if I understand exactly what you are trying to say.
> >> Are you saying that you had a submodule at "sub/dir" in your working
> >> tree, and then "mkdir ../another && cp -R sub/dir ../another" did
> >> not result in a usable Git working tree in ../another directory?
> >> 
> >> It is almost like complaining that "mkdir ../newone && cp -R * ../newone/"
> >> did not result in a usable git repository in ../newone directory and
> >> honestly speaking, that sounds borderline insane, I'd have to say.
> >> 
> >> Yes, if a user knows what she is doing, she should be able to make
> >> something like that work, without running "git clone" (which is
> >> probably the way most users would do it).  And yes, it would be good
> >> to let the user learn from the documentation enough so that she
> >> "knows what she is doing".  But no, I do not think end-user facing
> >> documentation for "git-submodule" subcommand is the way to do that.
> >> 
> >> That is why I suggested repository-layout as potentially a better
> >> alternative location.
> >> 
> >> But perhaps I am mis-reading your rationale.
> >> 
> >> 
> > 
> > Let me rephrase my example :
> > 
> > To give one of my project to someone else I have copied it on a USB key.
> > By a simple drag and drop with the mouse.
> > And I am quite sure I am not alone doing this way.
> > 
> > I have done those kind of things lot of time without any problem.
> > But that day 'the_project' happened to be a submodule cloned by
> > 'git submodule update' then on the USB key the $GIT_DIR of 'the_project'
> > was missing.
> > 
> > If 'man git-submodule' have made me aware of the particularities of submodules
> > clone I had write in a terminal:
> > 
> > git clone the_project /media/usb/the_project
> > 
> > Or at least I had understand what happened quicker.
> > 
> > I have nothing against also adding something in repository-layout but I am
> > pretty sure normal users never read repository-layout as it is not a command
> > they use. And it is not mentioned in most tutorials.
> 
> How about something like this:
> 
> "The git directory of a submodule lives inside the git directory of the parent repository instead of within the working directory."
> 
> I'm not sure where to put it, though.
> 
>  - Andrew Keller
> 

'git directory' seems ambiguous to me. Maybe we could use 'git metadata'.



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

  reply	other threads:[~2014-03-10  7:52 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-07  7:53 [PATCH/RFC] Documentation: Say that submodule clones use a separate gitdirs Henri GEIST
2014-03-07 21:42 ` Andrew Keller
2014-03-07 22:19   ` Junio C Hamano
2014-03-07 22:35   ` Henri GEIST
2014-03-07 23:37     ` Junio C Hamano
2014-03-08  0:50       ` Henri GEIST
2014-03-09 23:24         ` Andrew Keller
2014-03-10  7:52           ` Henri GEIST [this message]
2014-03-10 15:31           ` Junio C Hamano
2014-03-10 18:22             ` Henri GEIST
2014-03-10 19:36               ` 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

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

  git send-email \
    --in-reply-to=1394437946.7891.44.camel@Naugrim \
    --to=geist.henri@laposte.net \
    --cc=Jens.Lehmann@web.de \
    --cc=andrew@kellerfarm.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.
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 NNTP newsgroup(s).