From: Jeff King <peff@peff.net>
To: Jaime Soriano Pastor <jsorianopastor@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
Git Mailing List <git@vger.kernel.org>
Subject: Re: [PATCH 1/2] Check order when reading index
Date: Tue, 26 Aug 2014 08:20:09 -0400 [thread overview]
Message-ID: <20140826122008.GC29180@peff.net> (raw)
In-Reply-To: <CAPuZ2NHafXQthtuq-RnTvpjVfNPaXHEy8SejuhPEnG+MwCK=sg@mail.gmail.com>
On Tue, Aug 26, 2014 at 02:08:35PM +0200, Jaime Soriano Pastor wrote:
> > That is how we natively (read: not with the funky "virtual" stuff
> > merge-recursive does) express a merge with multiple merge bases.
> > You also should be able to read this in the way how "git merge" invokes
> > merge strategies (one or more bases, double-dash and then current
> > HEAD and the other branches). I think there are some tests in 3way
> > merge tests that checks what should happen when our HEAD matches
> > one of the stage #1 while their branch matches a different one of the
> > stage #1, too.
>
> I'm a bit lost with this, conceptually it doesn't seem to be any
> problem with having multiple merge bases, but I don't manage to
> reproduce it.
> With "natively" do you mean some internal state that is never written
> into the index? If this were the case then there wouldn't be any
> problem with the restriction when reading the index file.
FWIW, that was my question on reading Junio's response, too.
> I have also tried to reproduce it by directly calling
> git-merge-recursive and the most I have got is what it seemed to be
> like a conflict in the stage #1:
>
> $ git ls-files -s
> 100644 1036ba5101378f06aa10c5fa249b67e14f83166b 1 conflict
> 100644 2638c45f8e7bc5b56f70e92390153572811782c3 2 conflict
> 100644 178481050188cf00d7d9cd5a11e43ab8fab9294f 3 conflict
>
> $ git cat-file blob 1036ba5101378f06aa10c5fa249b67e14f83166b
> <<<<<<< Temporary merge branch 1
> G
> =======
> E
> F
> >>>>>>> Temporary merge branch 2
Yes, I think merge-recursive resolves the earlier merges and then feeds
the result into the main merge. And that's how you end up with the
"temporary merge branch" name instead of something useful.
It might work to have a recursive merge that causes a conflict on path
X, and then we further need to resolve that conflict. I'm not sure if we
try to represent that in the index somehow, or if merge-recursive just
bails in this case (I didn't try it).
-Peff
next prev parent reply other threads:[~2014-08-26 12:20 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-12 15:31 [PATCH] read-cache.c: Ensure unmerged entries are removed Jaime Soriano Pastor
2014-08-12 15:31 ` Jaime Soriano Pastor
2014-08-12 18:39 ` Junio C Hamano
2014-08-13 22:10 ` Jaime Soriano Pastor
2014-08-13 23:04 ` Junio C Hamano
2014-08-15 19:50 ` Jaime Soriano Pastor
2014-08-15 21:45 ` Junio C Hamano
2014-08-16 14:51 ` Jaime Soriano Pastor
2014-08-18 16:34 ` Junio C Hamano
2014-08-18 17:23 ` Jaime Soriano Pastor
2014-08-20 11:25 ` [PATCH 0/4] Handling unmerged files with merged entries Jaime Soriano Pastor
2014-08-20 11:26 ` [PATCH 1/4] read_index_unmerged doesn't loop forever if merged stage exists for unmerged file Jaime Soriano Pastor
2014-08-20 11:26 ` [PATCH 2/4] Error out when adding a file with merged and unmerged entries Jaime Soriano Pastor
2014-08-20 11:26 ` [PATCH 3/4] Added tests for the case of merged and unmerged entries for the same file Jaime Soriano Pastor
2014-08-20 21:00 ` Junio C Hamano
2014-08-21 13:51 ` Jaime Soriano Pastor
2014-08-21 22:21 ` Junio C Hamano
2014-08-20 11:26 ` [PATCH 4/4] git update-index --cacheinfo can be used to select a stage when there are merged and unmerged entries Jaime Soriano Pastor
2014-08-20 21:08 ` Junio C Hamano
2014-08-21 13:57 ` Jaime Soriano Pastor
2014-08-20 22:19 ` [PATCH 0/4] Handling unmerged files with merged entries Junio C Hamano
2014-08-21 13:42 ` Jaime Soriano Pastor
2014-08-21 13:43 ` [PATCH] Check order when reading index Jaime Soriano Pastor
2014-08-21 13:49 ` Jaime Soriano Pastor
2014-08-21 13:59 ` Duy Nguyen
2014-08-21 18:51 ` Junio C Hamano
2014-08-24 17:57 ` [PATCH 1/2] " Jaime Soriano Pastor
2014-08-24 17:57 ` [PATCH 2/2] Loop index increases monotonically when reading unmerged entries Jaime Soriano Pastor
2014-08-24 18:04 ` Jaime Soriano Pastor
2014-08-25 17:09 ` Junio C Hamano
2014-08-25 17:21 ` [PATCH 1/2] Check order when reading index Junio C Hamano
2014-08-25 19:44 ` Jeff King
2014-08-25 20:52 ` Junio C Hamano
2014-08-26 12:08 ` Jaime Soriano Pastor
2014-08-26 12:20 ` Jeff King [this message]
2014-08-26 16:53 ` Junio C Hamano
2014-08-26 17:22 ` Jaime Soriano Pastor
2014-08-26 17:43 ` Junio C Hamano
2014-08-27 19:48 ` [PATCH 1/2] read_index_from(): catch out of order entries when reading an index file Jaime Soriano Pastor
2014-08-27 19:48 ` [PATCH 2/2] read_index_unmerged(): remove unnecessary loop index adjustment Jaime Soriano Pastor
2014-08-29 2:16 ` [PATCH 1/2] read_index_from(): catch out of order entries when reading an index file Eric Sunshine
2014-08-29 8:54 ` [PATCH] " Jaime Soriano Pastor
2014-08-29 17:06 ` Junio C Hamano
2014-08-27 19:52 ` [PATCH 1/2] Check order when reading index Jaime Soriano Pastor
2014-08-27 21:11 ` Junio C Hamano
2014-08-27 22:13 ` Jaime Soriano Pastor
2014-08-25 20:26 ` Jaime Soriano Pastor
2014-08-21 18:40 ` [PATCH 0/4] Handling unmerged files with merged entries Johannes Sixt
2014-08-21 22:18 ` Junio C Hamano
2014-08-12 18:31 ` [PATCH] read-cache.c: Ensure unmerged entries are removed Junio C Hamano
2014-08-13 22:10 ` Jaime Soriano Pastor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140826122008.GC29180@peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jsorianopastor@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).