From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ramkumar Ramachandra Subject: Re: [PATCH] t4202 (log): add failing test for log with subtree Date: Tue, 23 Apr 2013 21:59:43 +0530 Message-ID: References: <1366632487-28153-1-git-send-email-artagnon@gmail.com> <87ppxmogdv.fsf@linux-k42r.v.cablecom.net> <87wqruk2pj.fsf@linux-k42r.v.cablecom.net> <87zjwqpebl.fsf@hexa.v.cablecom.net> <7vmwsqns4p.fsf@alter.siamese.dyndns.org> <7vehe2m88a.fsf@alter.siamese.dyndns.org> <7vobd5jktd.fsf@alter.siamese.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Cc: Matthieu Moy , Thomas Rast , Git List , Avery Pennarun To: Junio C Hamano X-From: git-owner@vger.kernel.org Tue Apr 23 18:30:31 2013 Return-path: Envelope-to: gcvg-git-2@plane.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UUg6v-0004qK-6d for gcvg-git-2@plane.gmane.org; Tue, 23 Apr 2013 18:30:29 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932379Ab3DWQaY (ORCPT ); Tue, 23 Apr 2013 12:30:24 -0400 Received: from mail-ie0-f182.google.com ([209.85.223.182]:62077 "EHLO mail-ie0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756483Ab3DWQaX (ORCPT ); Tue, 23 Apr 2013 12:30:23 -0400 Received: by mail-ie0-f182.google.com with SMTP id bn7so891947ieb.41 for ; Tue, 23 Apr 2013 09:30:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=nW44MQsbctt3vT5YIVqC/WPHpivZymwrLKk2j3ebAT4=; b=s0ykxaraYtUm93xvEKNmw6MvVXBsZbHf9Bx6JGEwKAAlbVhAuCdVMyRkuYS5KW3gTE eHUOFAtv6kUzOCISTObKlZDm7LToVaqkprQbwnq5LJ3Z99E+bfwc9FhfmK6o1FwMwv0j HToWp/UewYkWtMNheMpC0Ic37qHf45L46G+T7USeItRW6VxtZ7bqXXcSac3ma3YcuaN/ uuOLX2GGOyE1q/6IIeoLBv8G5NYdVYMWHs07SrWBzKQztn6QG98cFwyyrt69a7OtWMAh mnGUOqdXBcjoXROZ1PWBAaCY+/eMzt/glXxH72nC5kAC1YqDhmXO2H+X57PjoPMNp5Mz jA8Q== X-Received: by 10.50.117.3 with SMTP id ka3mr23815414igb.107.1366734623336; Tue, 23 Apr 2013 09:30:23 -0700 (PDT) Received: by 10.64.63.48 with HTTP; Tue, 23 Apr 2013 09:29:43 -0700 (PDT) In-Reply-To: <7vobd5jktd.fsf@alter.siamese.dyndns.org> Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: Junio C Hamano wrote: > If you need the history context (i.e. M, M^1, M^2) around it to > interpret that additional information, isn't it essentially the same > as storing renames in the merge commit M? There's one big difference. The point is that for any kind of repository composition, you're going to have to store tree renames at some level if you want to be able to move the submodule around in the tree. In the current submodule system, you could say that you're storing tree renames in a blob (submodule..path in .gitmodules). Ofcourse, the difference is that the other side of the tree entry is completely opaque to the superproject (and I think we can do better than that now). You should use heuristics for all other kinds of renames, but I'm arguing that repository composition is a special case that needs more thought. You shouldn't be against storing renames in principle, because we already do that in a way. What you should be against is storing renames in a way that will lock up the repository if a different path is taken to the same state. What I'm proposing is an optional field to speed up (and make more reliable) rename detection in a very specific case. I'm not putting the information in a commit because that will lock up our repository: If there are two different commits representing the same tree, but one contains bind lines and the other doesn't, we've done something seriously wrong: rebase and merge are screwed. In my case, if there are two perfectly identical trees except that one contains auxiliary information, nothing goes wrong: the tree without the auxiliary information will just be a little slower and can't support DWIM git operations. > Not very impressed, at least not yet. Please bear with me. I really think the repository composition problem is worth solving.