From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Achim Gratz Newsgroups: gmane.emacs.devel Subject: Re: Multiple checkout copies Date: Tue, 03 Feb 2015 11:02:08 +0100 Organization: Linux Private Site Message-ID: <87386ncnz3.fsf@Rainer.invalid> References: <54CE9E10.5000709@cs.ucla.edu> <87sieogqgf.fsf@violet.siamics.net> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1422957794 14143 80.91.229.3 (3 Feb 2015 10:03:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 3 Feb 2015 10:03:14 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 03 11:03:11 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YIaK6-0005XB-4X for ged-emacs-devel@m.gmane.org; Tue, 03 Feb 2015 11:03:10 +0100 Original-Received: from localhost ([::1]:58464 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIaK5-0008JD-9N for ged-emacs-devel@m.gmane.org; Tue, 03 Feb 2015 05:03:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45929) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIaJT-0008Ce-0t for emacs-devel@gnu.org; Tue, 03 Feb 2015 05:02:54 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YIaJL-0007cN-Rc for emacs-devel@gnu.org; Tue, 03 Feb 2015 05:02:30 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:55607) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIaJL-0007Yl-DR for emacs-devel@gnu.org; Tue, 03 Feb 2015 05:02:23 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1YIaJI-00055v-Ly for emacs-devel@gnu.org; Tue, 03 Feb 2015 11:02:20 +0100 Original-Received: from p54b4790b.dip0.t-ipconnect.de ([84.180.121.11]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 03 Feb 2015 11:02:15 +0100 Original-Received: from Stromeko by p54b4790b.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 03 Feb 2015 11:02:15 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 55 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: p54b4790b.dip0.t-ipconnect.de User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) Cancel-Lock: sha1:CWAcuh21OWcdcTh9etgXzJX5L6w= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:182316 Archived-At: 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