From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Multiple checkout copies Date: Tue, 03 Feb 2015 11:22:17 +0100 Message-ID: <87oapb2t2e.fsf@fencepost.gnu.org> References: <54CE9E10.5000709@cs.ucla.edu> <87sieogqgf.fsf@violet.siamics.net> <87386ncnz3.fsf@Rainer.invalid> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1422963688 17628 80.91.229.3 (3 Feb 2015 11:41:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 3 Feb 2015 11:41:28 +0000 (UTC) Cc: emacs-devel@gnu.org To: Achim Gratz Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 03 12:41:27 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 1YIbrC-0001yt-Ka for ged-emacs-devel@m.gmane.org; Tue, 03 Feb 2015 12:41:26 +0100 Original-Received: from localhost ([::1]:58802 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIbr7-0003Zr-5Q for ged-emacs-devel@m.gmane.org; Tue, 03 Feb 2015 06:41:21 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52103) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIbqr-0003Z0-BS for emacs-devel@gnu.org; Tue, 03 Feb 2015 06:41:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YIbqq-0001eY-9V for emacs-devel@gnu.org; Tue, 03 Feb 2015 06:41:05 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:43806) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIbqq-0001eU-6P for emacs-devel@gnu.org; Tue, 03 Feb 2015 06:41:04 -0500 Original-Received: from localhost ([127.0.0.1]:50981 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIbqo-0007iG-My; Tue, 03 Feb 2015 06:41:03 -0500 Original-Received: by lola (Postfix, from userid 1000) id CBB21E04E9; Tue, 3 Feb 2015 11:22:17 +0100 (CET) In-Reply-To: <87386ncnz3.fsf@Rainer.invalid> (Achim Gratz's message of "Tue, 03 Feb 2015 11:02:08 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e 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:182322 Archived-At: Achim Gratz writes: > 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 =E2=80=9Cbare=E2=80=9D Git reposito= ry used only >> > to mirror the upstream one, and thus it has no =E2=80=9Clocal=E2=80= =9D commits, >> > which are somewhat likely to become dangling after rebases and >> > such. > > That's mostly a red herring. The objects shared are hard-linked, No, they aren't. --shared, -s When the repository to clone is on the local machine, instead of using hard links, automatically setup .git/objects/info/alternat= es to share the objects with the source repository. The resulting repository starts out without any object of its own. And that's what makes this operation potentially dangerous. --shared has the advantage of never needing additional object space (the hard links used otherwise will start out with just requiring additional inodes, but as soon as objects get repacked, their contents are present twice as well), and being effective even when the repository is not on the same file system. The manual explicitly states with regard to --shared NOTE: this is a possibly dangerous operation; do not use it unless you understand what it does. And a corollary to "not not use it unless you understand what it does" is "do not publish any recipes or workflows containing --shared" because recipes or workflows are intended for the benefit of people not understanding every step. > 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. Apparently you confuse --shared with _not_ using --shared. --=20 David Kastrup