threads / patch / 38235

patchgit-new-workdir: support submodules

Subject: [PATCH] git-new-workdir: support submodules

## tl;dr

2 messages between Dec 23, 2014 and Dec 23, 2014. Diffs are folded; open one to read it.

replies: 1people: 2as markdown or json

Craig Silverstein· Dec 23, 2014, 02:10 UTC · lore

The basic problem with submodules, from git-new-workdir's point of view, is that instead of having a .git directory, they have a .git file with contents `gitdir: <some other path>`. This is a problem because the submodule's config file has an entry like `worktree = ../../../khan-exercises` which is relative to "<some other path>" rather than to "submodule_dir/.git".

As a result, if we want the new workdir to work properly, it needs to keep the same directory structure as the original repository: it should also contain a .git file with a 'gitdir', and the actual .git contents should be in the place mentioned therein. (There are other ways we could have solved this problem, including modifying the 'config' file, but this seemed most in keeping with the symlink-y philosophy of git-new-branch.)

This commit implements this, by detecting if the source .git directory is actually a .git file with 'gitdir: ...' as its contents, and if so reproducing the .git file + gitdir structure in the destination work-tree.

Test plan: On a repo (~/khan/webapp) with a submodule, ran

    git new-workdir ~/khan/webapp /tmp/webapp      # the main module
    git new-workdir ~/khan/webapp/khan-exercises /tmp/webapp/khan-exercises

and saw that /tmp/webapp/khan-exercises was populated correctly, /tmp/webapp/.git/modules/khan-exercises existed with symlinks, and /tmp/webapp/khan-exercises/.git was a file with a 'gitdir:' entry pointing to the .git/modules directory.

Signed-off-by: Craig Silverstein <csilvers@khanacademy.org>
---
 contrib/workdir/git-new-workdir | 55 +++++++++++++++++++++++++++--------------
 1 file changed, 36 insertions(+), 19 deletions(-)
Show changes to contrib/workdir/git-new-workdir +36 −19
diff --git a/contrib/workdir/git-new-workdir b/contrib/workdir/git-new-workdir
index 888c34a..3cc50de 100755
--- a/contrib/workdir/git-new-workdir
+++ b/contrib/workdir/git-new-workdir
@@ -52,26 +52,45 @@ then
 		"a complete repository."
 fi
 
+# don't modify an existing directory, unless it's empty
+if test -d "$new_workdir" && test $(ls -a1 "$new_workdir/." | wc -l) -ne 2
+then
+	die "destination directory '$new_workdir' is not empty."
+fi
+
 # make sure the links in the workdir have full paths to the original repo
 git_dir=$(cd "$git_dir" && pwd) || exit 1
 
-# don't recreate a workdir over an existing directory, unless it's empty
-if test -d "$new_workdir"
+new_git_dir="$new_workdir/.git"
+
+# if $orig_git is a .git file with a 'gitdir' entry (as is the case for
+# submodules), have the new git dir follow that same pattern.  otherwise
+# the 'worktree' entry in .git/config, which is a relative path, will
+# not resolve properly because we're not in the expected subdirectory.
+gitdir_text=$(sed -ne 's/^gitdir: *//p' "$orig_git/.git" 2>/dev/null)
+if test -n "$gitdir_text"; then
+	ln -s "$orig_git/.git" "$new_workdir/.git" || failed
+	new_git_dir="$new_workdir/$gitdir_text"
+fi
+
+# if new_workdir already exists, leave it along in case of error
+if ! test -d "$new_workdir"
 then
-	if test $(ls -a1 "$new_workdir/." | wc -l) -ne 2
-	then
-		die "destination directory '$new_workdir' is not empty."
-	fi
-	cleandir="$new_workdir/.git"
-else
-	cleandir="$new_workdir"
+	clean_new_workdir=true
 fi
 
-mkdir -p "$new_workdir/.git" || failed
-cleandir=$(cd "$cleandir" && pwd) || failed
+mkdir -p "$new_git_dir" || failed
 
+cleandir=$(cd "$cleandir" && pwd) || failed
 cleanup () {
-	rm -rf "$cleandir"
+	if test z"$clean_new_workdir" = ztrue
+	then
+		rm -rf "$new_workdir"
+	fi
+	# this may (or may not) be a noop if new_workdir was already deleted.
+	rm -rf "$new_git_dir"
+	# this is a noop unless .git is a 'gitdir: ...' file.
+	rm -f "$new_workdir/.git"
 }
 siglist="0 1 2 15"
 trap cleanup $siglist
@@ -84,22 +103,20 @@ do
 	# create a containing directory if needed
 	case $x in
 	*/*)
-		mkdir -p "$new_workdir/.git/${x%/*}"
+		mkdir -p "$new_git_dir/${x%/*}"
 		;;
 	esac
 
-	ln -s "$git_dir/$x" "$new_workdir/.git/$x" || failed
+	ln -s "$git_dir/$x" "$new_git_dir/$x" || failed
 done
 
-# commands below this are run in the context of the new workdir
-cd "$new_workdir" || failed
-
 # copy the HEAD from the original repository as a default branch
-cp "$git_dir/HEAD" .git/HEAD || failed
+cp "$git_dir/HEAD" "$new_git_dir/HEAD" || failed
 
 # the workdir is set up.  if the checkout fails, the user can fix it.
 trap - $siglist
 
 # checkout the branch (either the same as HEAD from the original repository,
-# or the one that was asked for)
+# or the one that was asked for).  we must be in the new workdir for this.
+cd "$new_workdir" || failed
 git checkout -f $branch
-- 
2.2.1
Junio C Hamano· Dec 23, 2014, 19:08 UTC · re: Craig Silverstein · lore

Re: [PATCH] git-new-workdir: support submodules

Craig Silverstein <csilvers.mail@gmail.com> writes:
Show 11 quoted lines
> The basic problem with submodules, from git-new-workdir's point of
> view, is that instead of having a .git directory, they have a .git
> file with contents `gitdir: <some other path>`.  This is a problem
> because the submodule's config file has an entry like `worktree =
> ../../../khan-exercises` which is relative to "<some other path>"
> rather than to "submodule_dir/.git".
>
> As a result, if we want the new workdir to work properly, it needs to
> keep the same directory structure as the original repository: it
> should also contain a .git file with a 'gitdir', and the actual .git
> contents should be in the place mentioned therein.

Hmmmm, does that mean that the submodule S in the original repository O's working tree and its checkout in the secondary working tree W created from O using git-new-workdir share the same repository location? More specifically:

	O/.git/                 - original repository
        O/.git/index            - worktree state in O
        O/S                     - submodule S's checkout in O
        O/S/.git                - a gitfile pointing to O/.git/modules/S
	O/.git/modules/S        - submodule S's repository contents
        O/.git/modules/S/config - submodule S's config
	W/.git/                 - secondary working tree
        W/.git/config           - symlink to O/.git/config
        W/.git/index            - worktree state in W (independent of O)
	W/S                     - submodule S's checkout in W (independent of O)
	W/S/.git                - a gitfile pointing to O/.git/modules/S

Doesn't a submodule checkout keep some state tied to the working tree in its repository configuration file? Wouldn't this change introduce problems by sharing O/.git/modules/S/config between the two checkouts?

← back to recent threads