Re: Multiple checkout copies

[Ivan Shmakov <ivan@siamics.net>]

>>>>> Richard Stallman <rms@gnu.org> writes:

[…]

 >> Using --shared may be risky, as Git may choose to GC the dangling
 >> objects away from emacs-1, not taking into account the possibility
 >> of them being used in some other trees.  In my case, the source
 >> directory is often a “bare” Git repository used only to mirror the
 >> upstream one, and thus it has no “local” commits, which are somewhat
 >> likely to become dangling after rebases and such.

 > Maybe I could use it in that way, but is there no way to make two
 > working trees both checked out in parallel from the same repository?

	I’m unsure I understand the purpose.

	The problem is that a Git repository (as in: working-copy/.git)
	is not just the graph of its respective commits, but also the
	mapping of branch (and tag) names to commit identifiers.  When a
	working copy is updated (say, via $ git pull), the respective
	branch name (.git/refs/heads/branchname) is also updated to
	point to the new head commit of the branch.  And I doubt that
	sharing such a mapping among several working copies for the same
	branch would be sensible.

	The approach I use is roughly as follows.

	First, I create a local clone of the remote repository /without/
	an associated working copy, like:

$ git clone --bare -- \
      git://example.org/jrh/example.git ~/public/download/git/example-2015.git 

	The repository so created can be updated with git-fetch(1):

$ GIT_DIR=~/public/download/git/example-2015.git \
      git fetch -t origin master:master 

	… Or without giving the branches explicitly, should
	example-2015.git/config contain an appropriate default, like:

[remote "origin"]
    url = git://example.org/jrh/example.git
    fetch = master:master example-42:example-42

	The working copies may now be created from this local repository
	(which git-clone(1) automatically aliases to ‘origin’)
	with --shared, and updated with the regular $ git pull command
	from there:

$ git clone --shared -- \
      ~/public/download/git/example-2015.git ~/devel/example-1 
$ git clone --shared -- \
      ~/public/download/git/example-2015.git ~/devel/example-2 
…
$ GIT_DIR=~/public/download/git/example-2015.git \
      git fetch -t origin master:master ## update the “bare” repository 
$ cd ~/devel/example-1 
$ git pull origin   ## update the working copy 

	This way, the commits which made it to the upstream are always
	available from example-2015.git and get reused upon git-pull(1),
	thus saving both time and filesystem space.  Furthermore, unless
	the upstream decides to “rewrite history” (at which point Git
	will require manual intervention), these commits won’t be
	eligible to GC, thus eliminating the risks generally associated
	with --shared.

	The commits made locally to either of the working copies stay in
	that same working copy (unless explicitly copied.)  I’m unsure
	that those of them which get incorporated upstream (and thus
	become available from example-2015.git) would be eligible for
	GC, but any “temporary” histories held within the individual
	example-N/.git (such as those left behind after a successful
	$ git rebase) surely would.

	The .git/refs/ mappings of these working copies are also
	entirely independent.

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A