From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: git commit/push and VC Date: Sat, 22 Nov 2014 16:25:51 +0900 Message-ID: <871tovu268.fsf@uwakimon.sk.tsukuba.ac.jp> References: <871toysqyq.fsf@rosalinde.fritz.box> <838uj57u5b.fsf@gnu.org> <87ppchd9dk.fsf@Gertrud.fritz.box> <83fvdd612c.fsf@gnu.org> <87h9xttmwa.fsf@uwakimon.sk.tsukuba.ac.jp> <83oas13p1y.fsf@gnu.org> <87egsvu7iw.fsf@uwakimon.sk.tsukuba.ac.jp> <87k32nwwxg.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 1416641175 11181 80.91.229.3 (22 Nov 2014 07:26:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 22 Nov 2014 07:26:15 +0000 (UTC) Cc: emacs-devel@gnu.org To: Ivan Shmakov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 22 08:26:08 2014 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 1Xs556-0001ok-Cm for ged-emacs-devel@m.gmane.org; Sat, 22 Nov 2014 08:26:08 +0100 Original-Received: from localhost ([::1]:44274 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xs555-0004Nn-M8 for ged-emacs-devel@m.gmane.org; Sat, 22 Nov 2014 02:26:07 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59892) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xs54x-0004Nb-GA for emacs-devel@gnu.org; Sat, 22 Nov 2014 02:26:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xs54r-0002TX-JI for emacs-devel@gnu.org; Sat, 22 Nov 2014 02:25:59 -0500 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:50016) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xs54r-0002Rt-99 for emacs-devel@gnu.org; Sat, 22 Nov 2014 02:25:53 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id F1EAF1C39C7; Sat, 22 Nov 2014 16:25:51 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id CE6D61A2892; Sat, 22 Nov 2014 16:25:51 +0900 (JST) In-Reply-To: <87k32nwwxg.fsf@violet.siamics.net> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 130.158.97.161 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:177971 Archived-At: Ivan Shmakov writes: > >>>>> Stephen J Turnbull writes: >=20 > [=E2=80=A6] >=20 > > Technically speaking, it's not possible in git to merge between > > clones, you have to fetch and then merge (=3D=3D pull). >=20 > Not necessarily, =E2=80=93 you can just as well add the Git (or, rather, > .git/objects) directory of your =E2=80=9Cother=E2=80=9D clone to your c= urrent=E2=80=99s > .git/objects/info/alternates, which will make the other clone=E2=80=99s > commits available for any operation =E2=80=93 including merge =E2=80=93= on the > current one. OK, it's possible to avoid the copy/linking operations of fetch, but you still need to do the merge in the current repo (and typically pull the ref from the other repo). There are also reasons why using alternates is not necessarily great (especially for new users) -- eg, it means that rebase, commit --amend, filter-branch, and so on can corrupt the dependent repo. It's somewhat beside the point, but I don't consider the physical location of objects in the DAG particularly interesting. fetch is usually very cheap even over the network -- one hardly notices it unless one distrusts coworkers enough to insist on a fetch-review- merge workflow instead of a pull workflow.