From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jonathan Nieder Subject: Re: 'git replace' and pushing Date: Sat, 27 Nov 2010 01:52:36 -0600 Message-ID: <20101127075236.GB24433@burratino> References: <4CEE2060.4020507@drmicha.warpmail.net> <20101126214325.GC23462@burratino> <7vvd3jptch.fsf@alter.siamese.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Junio C Hamano , Michael J Gruber , git@vger.kernel.org To: Cory Fields X-From: git-owner@vger.kernel.org Sat Nov 27 08:54:54 2010 Return-path: Envelope-to: gcvg-git-2@lo.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PMFcR-0003nx-6N for gcvg-git-2@lo.gmane.org; Sat, 27 Nov 2010 08:54:51 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751383Ab0K0Hwm convert rfc822-to-quoted-printable (ORCPT ); Sat, 27 Nov 2010 02:52:42 -0500 Received: from mail-gw0-f46.google.com ([74.125.83.46]:49241 "EHLO mail-gw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751154Ab0K0Hwm (ORCPT ); Sat, 27 Nov 2010 02:52:42 -0500 Received: by gwj20 with SMTP id 20so1260128gwj.19 for ; Fri, 26 Nov 2010 23:52:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:references:mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=KmB4bMgo7fJfQmxPq13QopvUpdvSfeffXf4x4gJMLIg=; b=F+RZ8UZr69aZoeBkcZPDqKCGIrkUghWCiODOhgK7Bu/9mkQptJz71JL89TYbLM6opt Tbj3MBUsvreloTqJs7wYeQY1R3ereItja2g1SpSmPbKktxScWZdIJfLwmA+FhOon6u92 VzQBUfGhYPIiQBPYOryn6CvZXAAeMykNZVcP0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; b=kHHw4Isiu6X+QkNmn/TxmkQvXTVAWghWBJ3cBOFl0IEzPHerjMLYmbA5rFaEOEjulg lbOCq/EE5uSntBrkU2yWe6lam8rSgMTdcJO/Vb6WCQuZ0SvAq1FoON6yLljGjO4M3zsw eFc2iiprgV/c8h2F53qm6xWKcKfL6Qf3WwPz8= Received: by 10.100.94.1 with SMTP id r1mr2297213anb.76.1290844361513; Fri, 26 Nov 2010 23:52:41 -0800 (PST) Received: from burratino ([68.255.101.216]) by mx.google.com with ESMTPS id x36sm3041623anx.14.2010.11.26.23.52.39 (version=SSLv3 cipher=RC4-MD5); Fri, 26 Nov 2010 23:52:40 -0800 (PST) Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: Cory Fields wrote: > On Fri, Nov 26, 2010 at 6:18 PM, Junio C Hamano w= rote: >> True, but I suspect the above picture pretty much satisfies Cory's i= nitial >> wish, no? =C2=A0You can fetch recent 4'--5---6 history as if 4' were= the root >> commit, and if you fetched replacement that tells us to pretend that= 4' >> has 3 as its parent (and the history leading to 3), you will get a d= eeper >> history. > > Yes, both of these can be accomplished. I've managed to get that part > working, where a default clone pulls in half history, and fetching > refs/replace gives you the rest. The only problem is that it requires= a > filter-branch before pushing. That's a one-time thing, not per-push, right? A filter-branch would indeed be needed to transform the history 1 --- 2 --- 3 --- 4 --- 5' --- 6' into 1 --- 2 --- 3 --- 4 4' --- 5 --- 6 and that is unavoidable: the object names encode the entire list of ancestors, you cannot push an object without its ancestors, etc. But afterwards you can build on the history rooted at 4' and all should be well, and you can use checkout --orphan to get a new root when the current line of history is about to grow too long. In other words, the distinction between real history and fake history is very relevant. Object transport only cares about the real history (barring bugs); if you want to tweak what objects get transferred, you really need to rewrite the real history (or use --depth). > A shallow clone does not fit for us, because we want the default clon= e to > only pull half. Having a public 1gb repository that will be cloned q= uite > often is bound to make our host unhappy, so we're doing everything we= can to > get the size down. Why not publish a "git bundle" of the first 1gb using HTTP, BitTorrent, or some other cache-friendly protocol and use a hook to reject attempts to fetch too many objects at once from the host? > Also, maybe I haven't made this clear... the "real" commit IDs need t= o > match the "fake" ones in order to prevent confusion. Not sure what this means. But commit IDs are defined based on content, and for simplicity and sanity the object transport machinery deliberately does not look beyond that. Regards, Jonathan