git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jens Lehmann <Jens.Lehmann@web.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: Antony Male <antony.male@gmail.com>,
	git@vger.kernel.org, iveqy@iveqy.com
Subject: Re: [PATCH] Submodules always use a relative path to gitdir
Date: Sun, 01 Jan 2012 15:58:26 +0100	[thread overview]
Message-ID: <4F007492.8010909@web.de> (raw)
In-Reply-To: <7vsjk3vw67.fsf@alter.siamese.dyndns.org>

Am 29.12.2011 23:40, schrieb Junio C Hamano:
> Antony Male <antony.male@gmail.com> writes:
> I further wonder if we can get away without using separate-git-dir option
> in this codepath, though. IOW using
> 
>         git clone $quiet -bare ${reference:+"$reference"} "$url" "$gitdir"
> 
> might be a better solution.

A quick test shows that using a bare repo won't fly because without the
core.worktree setting commands that operate on the work tree can't be
run anymore inside submodules (starting with the initial checkout). If
we could teach setup to take the directory where the gitfile was found
as first guess for the git work tree it looks like we can make that
approach work. I'll see if I can come up with something here ...

> For example (this relates to the point I mumbled "haven't thought this
> through thoroughly yet"), doesn't the newly cloned repository have
> core.worktree that points at the working tree that records the <path>,
> which would become meaningless when a commit in the superproject that
> binds the submodule at different path <path2>?

Yes, and the core.worktree setting also contains an absolute path. So
we must either make that relative too and rewrite it on every "git
submodule add" to record the possibly changed path there or make the
bare clone work with a work tree (which sounds a bit strange ;-).

>  git-submodule.sh |   21 ++++++++-------------
>  1 files changed, 8 insertions(+), 13 deletions(-)
> 
> diff --git a/git-submodule.sh b/git-submodule.sh
> index 3adab93..9a23e9d 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -156,21 +156,16 @@ module_clone()
>  		;;
>  	esac
>  
> -	if test -d "$gitdir"
> +	if ! test -d "$gitdir"
>  	then
> -		mkdir -p "$path"
> -		echo "gitdir: $rel_gitdir" >"$path/.git"
> -		rm -f "$gitdir/index"
> -	else
> -		mkdir -p "$gitdir_base"
> -		if test -n "$reference"
> -		then
> -			git-clone $quiet "$reference" -n "$url" "$path" --separate-git-dir "$gitdir"
> -		else
> -			git-clone $quiet -n "$url" "$path" --separate-git-dir "$gitdir"
> -		fi ||
> -		die "$(eval_gettext "Clone of '\$url' into submodule path '\$path' failed")"
> +		git clone $quiet -n ${reference:+"$reference"} \
> +			--separate-git-dir "$gitdir" "$url" "$path" ||
> +		die "$(eval_gettext "Clone of '\$url' for submodule '\$name' failed")
>  	fi
> +
> +	mkdir -p "$path"
> +	echo "gitdir: $rel_gitdir" >"$path/.git"
> +	rm -f "$gitdir/index"
>  }
>  
>  #

That broke quite some tests for me (even though I really liked
to get rid of that if ;-)

Here is a patch that solves the first part of the absolute paths
problem (passes all tests; parts of the commit message shamelessly
copied from your proposal). Then another patch can tackle the
core.worktree config setting problem to make superprojects
relocatable gain.
---------8<--------
Subject: [PATCH] submodules: always use a relative path to gitdir

Recent versions of "git submodule" maintain the submodule <name> at
<path> in the superproject using a "separate git-dir" mechanism. The
repository data for the submodule is stored in ".git/modules/<name>/"
directory of the superproject, and its working tree is created at
"<path>/" directory, with "<path>/.git" file pointing at the
".git/modules/<name>/" directory.

This is so that we can check out an older version of the superproject
that does not yet have the submodule <name> anywhere without losing
(and later having to re-clone) the submodule repository. Removing
"<path>" won't lose ".git/modules/<name>", and a different branch that
has the submodule at different location in the superproject, say
"<path2>", can create "<path2>/" and ".git" in it to point at the same
".git/modules/<name>".

When instantiating such a submodule, if ".git/modules/<name>/" does
not exist in the superproject, the submodule repository needs to be
cloned there first. Then we only need to create "<path>" directory,
point ".git/modules/<name>/" in the superproject with "<path>/.git",
and check out the working tree.

However, the current code is not structured that way. The codepath to
deal with newly cloned submodules uses "git clone --separate-git-dir"
and creates "<path>" and "<path>/.git". This can make the resulting
submodule working tree at "<path>" different from the codepath for
existing submodules. An example of such differences is that this
codepath prepares "<path>/.git" with an absolute path, while the
normal codepath uses a relative path.

Fix the latter by always writing the relative path to the git directory
in "<path>/.git". To make that work, the 'name' variable has to be set to
the value of the 'path' variable for newly added submodules.

This is only the first step to make superprojects movable again like they
were before the separate-git-dir approach was introduced. The second step
must be to either use a relative path in core.worktree too or to get rid
of that setting by using a bare repo in "./git/modules/<name>".

While at it also replace an if/else construct evaluating the presence
of the 'reference' option with a single line of bash code.

Reported-by: Antony Male <antony.male@gmail.com>
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
 git-submodule.sh |   12 +++++-------
 1 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/git-submodule.sh b/git-submodule.sh
index 3adab93..2a93c61 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -131,6 +131,7 @@ module_clone()
 	gitdir=
 	gitdir_base=
 	name=$(module_name "$path" 2>/dev/null)
+	test -n "$name" || name="$path"
 	base_path=$(dirname "$path")

 	gitdir=$(git rev-parse --git-dir)
@@ -159,18 +160,15 @@ module_clone()
 	if test -d "$gitdir"
 	then
 		mkdir -p "$path"
-		echo "gitdir: $rel_gitdir" >"$path/.git"
 		rm -f "$gitdir/index"
 	else
 		mkdir -p "$gitdir_base"
-		if test -n "$reference"
-		then
-			git-clone $quiet "$reference" -n "$url" "$path" --separate-git-dir "$gitdir"
-		else
-			git-clone $quiet -n "$url" "$path" --separate-git-dir "$gitdir"
-		fi ||
+		git clone $quiet -n ${reference:+"$reference"} \
+			--separate-git-dir "$gitdir" "$url" "$path" ||
 		die "$(eval_gettext "Clone of '\$url' into submodule path '\$path' failed")"
 	fi
+
+	echo "gitdir: $rel_gitdir" >"$path/.git"
 }

 #
-- 
1.7.8.2.303.g78a27

  parent reply	other threads:[~2012-01-01 14:58 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-29 21:00 [PATCH] Submodules always use a relative path to gitdir Antony Male
2011-12-29 22:40 ` Junio C Hamano
2011-12-31 21:28   ` Phil Hord
2012-01-03 18:45     ` Junio C Hamano
2012-01-03 19:58       ` Junio C Hamano
2012-01-01 14:58   ` Jens Lehmann [this message]
2012-01-03 18:27     ` Junio C Hamano
2012-01-03 22:10       ` Jens Lehmann
2012-01-03 22:17         ` Junio C Hamano
2012-01-05 22:52           ` Jens Lehmann
2012-01-06  0:11             ` Junio C Hamano
2012-01-06 14:26               ` Phil Hord
2012-01-06 15:07                 ` Nguyen Thai Ngoc Duy
2012-01-06 18:53                 ` Junio C Hamano
2011-12-29 22:48 ` Fredrik Gustafsson
2011-12-31 20:31 ` Phil Hord

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=4F007492.8010909@web.de \
    --to=jens.lehmann@web.de \
    --cc=antony.male@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=iveqy@iveqy.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).