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 19:53:26 +0100 Message-ID: <87zj8u25eh.fsf@fencepost.gnu.org> References: <54CE9E10.5000709@cs.ucla.edu> <87sieogqgf.fsf@violet.siamics.net> <87386ncnz3.fsf@Rainer.invalid> <87oapb2t2e.fsf@fencepost.gnu.org> <87y4ofb1gt.fsf@Rainer.invalid> <87fvan2l29.fsf@fencepost.gnu.org> <87fvanglpz.fsf@violet.siamics.net> <87bnlb2j48.fsf@fencepost.gnu.org> <87bnlahmpf.fsf@violet.siamics.net> 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 1422989615 30004 80.91.229.3 (3 Feb 2015 18:53:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 3 Feb 2015 18:53:35 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 03 19:53:34 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 1YIibO-0001qs-4a for ged-emacs-devel@m.gmane.org; Tue, 03 Feb 2015 19:53:34 +0100 Original-Received: from localhost ([::1]:60921 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIibN-0001iE-Nj for ged-emacs-devel@m.gmane.org; Tue, 03 Feb 2015 13:53:33 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36174) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIibK-0001i9-4S for emacs-devel@gnu.org; Tue, 03 Feb 2015 13:53:31 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YIibI-0000OI-VT for emacs-devel@gnu.org; Tue, 03 Feb 2015 13:53:30 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:52381) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIibI-0000OD-Rf for emacs-devel@gnu.org; Tue, 03 Feb 2015 13:53:28 -0500 Original-Received: from localhost ([127.0.0.1]:59557 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIibI-0008V0-29 for emacs-devel@gnu.org; Tue, 03 Feb 2015 13:53:28 -0500 Original-Received: by lola (Postfix, from userid 1000) id 8EF3CE04E9; Tue, 3 Feb 2015 19:53:26 +0100 (CET) In-Reply-To: <87bnlahmpf.fsf@violet.siamics.net> (Ivan Shmakov's message of "Tue, 03 Feb 2015 18:30:36 +0000") 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:182337 Archived-At: Ivan Shmakov writes: >>>>>> David Kastrup writes: >>>>>> Ivan Shmakov writes: >>>>>> David Kastrup writes: > > [=E2=80=A6] > > >>> No, it isn't. You can have both local branches and remote branches > >>> removed from the cloned bare repo while your --shared clone still > >>> uses objects that are no longer retained in the first clone. > > >> =E2=80=9CCan=E2=80=9D in the sense that you /can/ use Git to shoot yo= urself in the > >> foot, or are there cases where git-fetch(1) would indeed autoremove > >> any branch references from a bare repository? > > > If you want to mirror the upstream, you'll use "git fetch -p" in > > order to have branches that are removed upstream to get deleted in > > the mirror as well. > > And why would I want that, In order not to accumulate temporary branches that are no longer present in upstream? > especially given that I=E2=80=99m already aware that a. some of the > objects may be used elsewhere (and thus such an operation would > be potentially unsafe) and b. the packs received from the remote > are likely to contain a mix of Git objects belonging to both > removed and extant branches, Why would they? > and it would thus /not/ be possible to remove them anyway? > > And as for repacking such a mirror from time to time, =E2=80=94 it=E2=80= =99s > going to be a sure nuisance due to backup reasons, etc. Uh, it's going to get repacked anyway. Git does that without asking. > > Even without -p, references in frequently rewritten work branches > > (like Git's pu or next branches) will disappear eventually. > > Do fast-forward updates (which git-fetch(1) defaults to) ever > result in dangling Git objects? Maybe it would be worth checking the man pages before making such statements. It's just annoying when people spray arbitrary statements to the list and leave it to others to clean up. git-fetch does not merge in any manner and consequently also does not "fast-forward". It updates references after making them backed by the respective objects. You are confusing this with the git-pull action of updating a local branch based on a remote-tracking branch. There is a very limited situation when using explicit branch names for source and target branch where git-fetch will only update a reference to a non-descendant when given the option -f. Since there is no way to trigger a "slow forward" (also known as "merge") without involving the work directory and index, this is neither the same as a fast forward, nor referenced as such. > Also, I=E2=80=99m typically interested in mirroring just a few branches > (mostly =E2=80=98master=E2=80=99 and the latest stable, if any.) Per my > experience, such branches rarely (if ever) get =E2=80=9Crewritten.=E2=80= =9D "I'm typically interested in" is no base for promoting problematic workflows since it violates the "do not use it unless you understand what it does" dictum for the recipient of such a recipe. --=20 David Kastrup