All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] git-new-workdir: support submodules
@ 2014-12-23  2:10 Craig Silverstein
  2014-12-23 19:08 ` Junio C Hamano
  0 siblings, 1 reply; 13+ messages in thread
From: Craig Silverstein @ 2014-12-23  2:10 UTC (permalink / raw)
  To: git; +Cc: jrnieder, pclouds

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(-)

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

^ permalink raw reply related	[flat|nested] 13+ messages in thread
* Re: [PATCH] git-new-workdir: support submodules
@ 2014-12-23 21:51 Craig Silverstein
  2015-01-24  0:48 ` Craig Silverstein
  0 siblings, 1 reply; 13+ messages in thread
From: Craig Silverstein @ 2014-12-23 21:51 UTC (permalink / raw)
  To: git; +Cc: gitster, Jonathan Nieder, Nguyễn Thái Ngọc

[Ack, I forgot to cc myself on the original patch so now I can't reply
to it normally.  Hopefully my workaround doesn't mess up the threading
too badly.]

Junio C Hamano <gitster <at> pobox.com> writes:
>
> 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

Right until the last line.  The .git file holds a relative path (at
least, it always does in my experience), so W/S/.git will point to
W/.git/modules/S.

Also, to complete the story, my changes sets the following:

        W/.git/modules/S    - secondary working tree for S
             W/.git/modules/S/config   - symlink to O/.git/modules/S/config
             W/.git/modules/S/index    - worktree state in W's S
(independent of O and O's S)

> Doesn't a submodule checkout keep some state tied to the working
> tree in its repository configuration file?

Do you mean, in 'config' itself?  If so, I don't see it.  (Though it's
possible there are ways to use submodules that do keep working-tree
state in the config file, and we just happen not to use those ways.)
Here's what my webapp/.git/modules/khan-exercises/config looks like:
---
[core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
        worktree = ../../../khan-exercises
[remote "origin"]
        url = http://github.com/Khan/khan-exercises.git
        fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
        remote = origin
        merge = refs/heads/master
        rebase = true
[submodule "test/qunit"]
        url = https://github.com/jquery/qunit.git
--

The only thing that seems vaguely working-tree related is the
'worktree' field, which is the field that motivated me to set up my
patch the way it is.

> Wouldn't this change
> introduce problems by sharing O/.git/modules/S/config between the
> two checkouts?

It's true that this change does result in sharing that file, so if
that's problematic then you're right.  I'm afraid I don't know all the
things that can go into a submodule config file.

(There are other things I don't know as well, such as: do we see .git
files with 'gitdir: ...' contents only for submodules, or are there
other ways to create them as well?  Are 'gitdir' paths always
relative?  Are there special files in .git (or rather .git/modules/S)
that exist only for submodules and not for 'normal' repos, that we
need to worry about symlinking?  I apologize for not knowing all these
git internals, and hope you guys can help point out any gaps that
affect this patch!)

craig

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2015-01-29  3:00 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-12-23  2:10 [PATCH] git-new-workdir: support submodules Craig Silverstein
2014-12-23 19:08 ` Junio C Hamano
2014-12-23 21:51 Craig Silverstein
2015-01-24  0:48 ` Craig Silverstein
2015-01-24  1:37   ` Junio C Hamano
2015-01-25  1:47     ` Craig Silverstein
2015-01-26  4:05       ` Junio C Hamano
2015-01-26  4:57         ` Craig Silverstein
2015-01-26  5:39           ` Junio C Hamano
2015-01-27 17:35             ` Jens Lehmann
2015-01-28 10:50               ` Duy Nguyen
2015-01-28 10:53                 ` Duy Nguyen
2015-01-28 20:18                   ` Junio C Hamano

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.