emacs-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]