From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Rast Subject: Re: [PATCH 0/3] merge -Xindex-only Date: Tue, 9 Jul 2013 22:01:06 +0200 Message-ID: <87wqozbj0d.fsf@hexa.v.cablecom.net> References: <51DAD8F2.5070008@alum.mit.edu> <87k3l1gip1.fsf@linux-k42r.v.cablecom.net> <51DBDB6F.7090105@alum.mit.edu> <878v1gey16.fsf@linux-k42r.v.cablecom.net> <51DC66A5.80500@alum.mit.edu> Mime-Version: 1.0 Content-Type: text/plain Cc: git discussion list To: Michael Haggerty X-From: git-owner@vger.kernel.org Tue Jul 09 22:01:56 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 1Uwe6e-0002Og-0h for gcvg-git-2@plane.gmane.org; Tue, 09 Jul 2013 22:01:48 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754074Ab3GIUBL (ORCPT ); Tue, 9 Jul 2013 16:01:11 -0400 Received: from edge20.ethz.ch ([82.130.99.26]:49793 "EHLO edge20.ethz.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753912Ab3GIUBJ (ORCPT ); Tue, 9 Jul 2013 16:01:09 -0400 Received: from CAS10.d.ethz.ch (172.31.38.210) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.2.298.4; Tue, 9 Jul 2013 22:01:03 +0200 Received: from hexa.v.cablecom.net.ethz.ch (46.126.8.85) by cas10.d.ethz.ch (172.31.38.210) with Microsoft SMTP Server (TLS) id 14.2.298.4; Tue, 9 Jul 2013 22:01:06 +0200 In-Reply-To: <51DC66A5.80500@alum.mit.edu> (Michael Haggerty's message of "Tue, 09 Jul 2013 21:38:13 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) X-Originating-IP: [46.126.8.85] Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: Michael Haggerty writes: > On 07/09/2013 02:08 PM, Thomas Rast wrote: >> Michael Haggerty writes: >> >>> Since you've already implemented a way to merge into the index (even an >>> alternative index) without touching the working copy, I'll just cross my >>> fingers and hope for the appearance of an option that makes merge leave >>> HEAD, MERGE_HEAD, etc. untouched. >> >> The most annoying part is probably where to put the output, since >> merging is more or less defined to do one of: >> >> - update HEAD and return 0 >> - update MERGE_HEAD and return 1 > > I don't understand what you mean here. [...] I was simply trying to describe what the status quo is, as a basis for the next paragraph. Does that clarify it? >> I'm not sure how much flexibility is worth having. Would it be >> sufficient if you had an option, e.g. -Xresult-ref=refs/heads/foo, that >> changes it to: >> >> - update refs/heads/foo and return 0 >> - return 1, not updating any refs >> >> That would mean that it would only work for noninteractive use. In the >> conflicting case, the driving script would need to remember what it >> wanted to merge so as have the information when finally committing. > > That would be fine with me. On IRC you said you would like a version that always acts as --no-commit, and simply returns the conflict/no conflict bit as usual. The caller would then proceed using commit-tree itself. I think that is probably a saner solution than this "output ref" idea. -- Thomas Rast trast@{inf,student}.ethz.ch