[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Multiple checkout copies
From: |
Ivan Shmakov |
Subject: |
Re: Multiple checkout copies |
Date: |
Tue, 03 Feb 2015 07:14:29 +0000 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) |
>>>>> Richard Stallman <address@hidden> 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
- Multiple checkout copies, Richard Stallman, 2015/02/01
- Re: Multiple checkout copies, Paul Eggert, 2015/02/01
- Re: Multiple checkout copies, Ivan Shmakov, 2015/02/02
- Re: Multiple checkout copies, Ivan Shmakov, 2015/02/02
- Re: Multiple checkout copies, Richard Stallman, 2015/02/02
- Re: Multiple checkout copies,
Ivan Shmakov <=
- Re: Multiple checkout copies, Achim Gratz, 2015/02/03
- Re: Multiple checkout copies, David Kastrup, 2015/02/03
- Re: Multiple checkout copies, Achim Gratz, 2015/02/03
- Re: Multiple checkout copies, David Kastrup, 2015/02/03
- Re: Multiple checkout copies, Ivan Shmakov, 2015/02/03
- Re: Multiple checkout copies, David Kastrup, 2015/02/03
- Re: Multiple checkout copies, Ivan Shmakov, 2015/02/03
- Re: Multiple checkout copies, David Kastrup, 2015/02/03
- Re: Multiple checkout copies, Ivan Shmakov, 2015/02/03
- Re: Multiple checkout copies, David Kastrup, 2015/02/03