From mboxrd@z Thu Jan 1 00:00:00 1970 From: Johan Herland Subject: Re: [PATCH v3 2/6] notes: replace pseudorefs with real refs Date: Wed, 29 Jul 2015 15:19:28 +0200 Message-ID: References: <1438107144-24293-1-git-send-email-dturner@twopensource.com> <1438107144-24293-3-git-send-email-dturner@twopensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Cc: David Turner , Git mailing list , Michael Haggerty , Eric Sunshine , Philip Oakley To: Junio C Hamano X-From: git-owner@vger.kernel.org Wed Jul 29 15:19:45 2015 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 1ZKRGn-0007Fj-GA for gcvg-git-2@plane.gmane.org; Wed, 29 Jul 2015 15:19:41 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752382AbbG2NTh (ORCPT ); Wed, 29 Jul 2015 09:19:37 -0400 Received: from locusts.copyleft.no ([188.94.218.116]:61542 "EHLO mail.mailgateway.no" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750819AbbG2NTg (ORCPT ); Wed, 29 Jul 2015 09:19:36 -0400 Received: from mail-yk0-f177.google.com ([209.85.160.177]) by mail.mailgateway.no with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ZKRGg-000OXV-7Z for git@vger.kernel.org; Wed, 29 Jul 2015 15:19:34 +0200 Received: by ykdu72 with SMTP id u72so7095661ykd.2 for ; Wed, 29 Jul 2015 06:19:28 -0700 (PDT) X-Received: by 10.13.206.133 with SMTP id q127mr43760786ywd.10.1438175968378; Wed, 29 Jul 2015 06:19:28 -0700 (PDT) Received: by 10.37.208.71 with HTTP; Wed, 29 Jul 2015 06:19:28 -0700 (PDT) In-Reply-To: Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: On Wed, Jul 29, 2015 at 7:01 AM, Junio C Hamano wrote: > Johan Herland writes: > >> I believe it is a bad compromise. It complicates the code, and it >> provides a concurrent notes merges that is unnecessarily tied to (and >> dependent on) worktrees. For example, if I wanted to perform N >> concurrent notes merges in a project that happens to have a huge >> worktree, I would now have to create N copies of the huge worktree... > > Who said worktree has to be populated? You should be able to have > an absolutely empty checkout just like "clone --no-checkout". IMHO that's an insane workaround that only serves to highlight the conceptual problems of binding notes merges (as they are implemented today) to worktrees. I'm much more excited about Michael's idea of formalising the concept of a notes tree checkout (although as already discussed, checking out a notes tree is different from checking out a "regular" tree). Then, a notes merge (as you already suggested) should be implemented by creating a linked worktree whose HEAD is the notes ref being merged into. I believe there are potential complications here as well (where a notes-merge might behave differently from a regular merge), but those should be solvable. But, whatever. This is unrelated to David's current effort, and I don't want to hold that up, so please move along, nothing to see here. ...Johan -- Johan Herland, www.herland.net