unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Achim Gratz <Stromeko@nexgo.de>
To: emacs-devel@gnu.org
Subject: Re: Multiple checkout copies
Date: Tue, 03 Feb 2015 11:02:08 +0100	[thread overview]
Message-ID: <87386ncnz3.fsf@Rainer.invalid> (raw)
In-Reply-To: E1YIS10-0000T1-IL@fencepost.gnu.org

Richard Stallman writes:
>    > $ git clone --shared emacs-1 emacs-2
>
> sounded like just the right thing until you posted
> the caveat.  After this, I hesitate to use it:
>
> 	  > 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.

That's mostly a red herring.  The objects shared are hard-linked, so
even if the GC removes objects in a repository that doesn't reference
them anymore they continue to exist in the repository that still needs
them.  As long as you do not delete that other repository you cannot
lose anything.

> 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?

The officially sanctioned Git way of getting a new worktree is to make
another clone.  If you don't intend to use it as a full repository later
on, you can do a shallow clone or you can use another repository as an
"alternate" to skip copying / linking the object files.

There is a sort-of way of splitting off additional working trees, either
using the --work-tree argument or by setting the GIT_WORK_TREE
environment variable or even manipulating the core.worktree property of
the repository.  But you can only ever make changes on a single worktree
anyway since a lot of meta-information regarding the worktree is also
kept in the repository, so while you have those multiple working
directories, only the last of them is properly "checked out".

The way to do this properly is to link all shared information back to
the original repository (I'd only ever use a bare one for this) and keep
the per-worktree files separated.  The git-new-workdir script does this,
but it's still in contrib since it doesn't work on some systems.

http://git.kernel.org/cgit/git/git.git/tree/contrib/workdir/git-new-workdir

You are quite likely on a system where that script works, so it would
just be a matter of dropping it into /usr/lib/git and making it
executable.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada




  parent reply	other threads:[~2015-02-03 10:02 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-01 20:34 Multiple checkout copies Richard Stallman
2015-02-01 21:43 ` Paul Eggert
2015-02-02 13:35   ` Richard Stallman
2015-02-02 15:19     ` Elias Mårtenson
2015-02-03  1:10       ` Richard Stallman
2015-02-03  1:32         ` Paul Eggert
2015-02-03  8:40         ` David Kastrup
2015-02-02 17:42     ` Ivan Shmakov
2015-02-02 18:12       ` Ivan Shmakov
2015-02-03  1:10       ` Richard Stallman
2015-02-03  7:14         ` Ivan Shmakov
2015-02-03 10:02         ` Achim Gratz [this message]
2015-02-03 10:22           ` David Kastrup
2015-02-03 12:53             ` Achim Gratz
2015-02-03 13:15               ` David Kastrup
2015-02-03 13:37                 ` Ivan Shmakov
2015-02-03 13:57                   ` David Kastrup
2015-02-03 18:30                     ` Ivan Shmakov
2015-02-03 18:53                       ` David Kastrup
2015-02-03 19:17                         ` Ivan Shmakov
2015-02-03 19:41                           ` David Kastrup
2015-02-03 20:25                             ` Ivan Shmakov
2015-02-04 23:02                             ` Richard Stallman
2015-02-03 17:46         ` Stefan Monnier
2015-02-03 16:50 ` Steinar Bang
2015-02-03 17:05   ` David Kastrup
2015-02-03 22:55     ` Steinar Bang
2015-02-03 23:05   ` Richard Stallman
2015-02-04  8:48     ` Achim Gratz
2015-02-04  8:55       ` David Kastrup
2015-02-04 12:02       ` Ivan Shmakov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87386ncnz3.fsf@Rainer.invalid \
    --to=stromeko@nexgo.de \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).