From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-3.6 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_PASS, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by dcvr.yhbt.net (Postfix) with ESMTP id 7D0A01F9FD for ; Thu, 25 Feb 2021 20:30:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233441AbhBYU12 (ORCPT ); Thu, 25 Feb 2021 15:27:28 -0500 Received: from mx2.suse.de ([195.135.220.15]:45762 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234222AbhBYU1O (ORCPT ); Thu, 25 Feb 2021 15:27:14 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 17AD9AAAE; Thu, 25 Feb 2021 20:26:29 +0000 (UTC) Date: Thu, 25 Feb 2021 21:26:27 +0100 From: Michal =?iso-8859-1?Q?Such=E1nek?= To: Junio C Hamano Cc: Elijah Newren , "brian m. carlson" , Git Mailing List Subject: Re: Getting an actuallt useful merge base? Message-ID: <20210225202627.GA6564@kitsune.suse.cz> References: <20210224175834.GT6564@kitsune.suse.cz> <20210225182924.GY6564@kitsune.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.11.3 (2019-02-01) Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Thu, Feb 25, 2021 at 12:03:58PM -0800, Junio C Hamano wrote: > Elijah Newren writes: > > >> It's like this > >> > >> T > >> ----o----o----o----o----o----o----o----o----o----o----o----o---(t)---o----o---- > >> \ \ \ \\\ > >> \ \ \ \\\ > >> \ \ \ \\\ > >> \ o----o----o\̶---o---(s)---o----o----o----o----o----o\̶\̶-(a) > >> \ / \ / \\ > >> S+T o----o----o----o----o----o---(u)---o----o----o----o----o----o----o\̶--(b) > >> / / \ > >> ---o----o----o----o----o----o----o----o----o----o----o----o----o----o----o---(m) > >> > >> So (t) is common ancestor for (a) and (b) that merge-base reports but it is > >> only ancestor for files in set T, and does not have files from set S at all. > >> The common ancestor I am insterested in is (s) which is merge base for both > >> sets of files. > > > > From git-merge-base(1): > > > > "When the history involves criss-cross merges, there can be more than > > one best common ancestor for two commits...When the --all option is > > not given, it is unspecified which best one is output." > > > > Perhaps you want to specify --all to git merge-base, and then perform > > additional checks on the output to select one yourself? The description does not inspire much confidence but it indeed gives something reasonable (ie what looks like would be (t) (u) in this situation). Nonetheless, (t) is clearly inferior and is reported by default when --all is not given. > > Ignore me, as it is likely I am just confused, but if we are merging > (a) and (b), I do not think (s) could be usable as a merge base; it > may be an ancestor of (a) but is not an ancestor of (b), no? Indeed, it should be the parent of (s) on the (b) branch - (u). Thanks Michal