Git development
 help / color / mirror / Atom feed
From: Phillip Wood <phillip.wood123@gmail.com>
To: Junio C Hamano <gitster@pobox.com>,
	"D. Ben Knoble" <ben.knoble@gmail.com>
Cc: git@vger.kernel.org, "Eli Barzilay" <eli@barzilay.org>,
	"Phillip Wood" <phillip.wood@dunelm.org.uk>,
	"Johannes Schindelin" <Johannes.Schindelin@gmx.de>,
	"Patrick Steinhardt" <ps@pks.im>,
	"Elijah Newren" <newren@gmail.com>, "Adam Johnson" <me@adamj.eu>,
	"Victoria Dye" <vdye@github.com>, "Jeff King" <peff@peff.net>,
	"Derrick Stolee" <stolee@gmail.com>,
	"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Subject: Re: [PATCH v2 4/4] builtin/stash: merge index in-core
Date: Fri, 25 Sep 2026 17:04:34 +0100	[thread overview]
Message-ID: <6e6420e8-3cbd-4975-a781-645e1ffbc1d2@gmail.com> (raw)
In-Reply-To: <xmqqse2yz4y4.fsf@gitster.g>

Hi Junio

On 24/09/2026 22:59, Junio C Hamano wrote:
> "D. Ben Knoble" <ben.knoble@gmail.com> writes:
> 
> Ahh, or perhaps the trees are indeed given in a wrong order, but not
> in a random wrong order.  merge_ort_nonrecursive(), which is *not*
> the function you are using, takes head, merge, and merge_base in
> this order, and that order matches what you wrote.

Ouch that's nasty. Well spotted, I missed it when I read the code 
(because the arguments were in the same order as the call to 
merge_ort_nonrecursive()) and the tests we have use the same version of 
the file for "base" and "stage2" so do not notice if they'd been 
transposed. It is rather confusing that two functions that are so 
closely related take their arguments in a different order.

> Perhaps the true culprit in this confusion is that the order in
> which merge_ort_nonrecursive() takes its three trees (head, merge,
> and common) and the order in which merge_incore_nonrecursive() takes
> its trees (merge_base, side1, and side2) are different, and if we
> fix them to match, it would make it easier to work with?

I think it is definitely worth fixing them to take the trees in the same 
order. My preference would be "base", "stage1", "stage2" but so long as 
they match each other I dont object to "stage1", "stage2", "base".

Thanks

Phillip

> The new test in the attached patch will fail with this step but if
> we revert the changes to builtin/stash.c in this step, it passes.
> 
>   t/t3903-stash.sh | 32 ++++++++++++++++++++++++++++++++
>   1 file changed, 32 insertions(+)
> 
> diff --git c/t/t3903-stash.sh w/t/t3903-stash.sh
> index 3958ab3c8d..0a87e62b11 100755
> --- c/t/t3903-stash.sh
> +++ w/t/t3903-stash.sh
> @@ -374,6 +374,38 @@ test_expect_success 'stash apply -q --index refreshes the index' '
>   	test_cmp expect actual
>   '
>   
> +
> +test_expect_success 'stash apply --index does not revert unrelated upstream index changes' '
> +	test_when_finished "rm -fr playpen" &&
> +	mkdir playpen &&
> +	(
> +		cd playpen &&
> +		git init &&
> +		echo "base1" >file1 &&
> +		echo "base2" >file2 &&
> +		git add file1 file2 &&
> +		git commit -m "initial base" &&
> +
> +		# Make a staged change to file1 and stash it
> +		echo "staged1" >file1 &&
> +		git add file1 &&
> +		git stash &&
> +
> +		# Upstream advances by modifying unrelated file2
> +		echo "upstream2" >file2 &&
> +		git add file2 &&
> +		git commit -m "upstream change to file2" &&
> +
> +		# Apply the stash with --index
> +		git stash apply --index &&
> +
> +		# Verify working tree and index state
> +		test "$(git show :file1)" = "staged1" &&
> +		test "$(git show :file2)" = "upstream2" &&
> +		test "$(git show HEAD:file2)" = "upstream2"
> +	)
> +'
> +
>   test_expect_success 'stash apply --index leaves everything untouched on failure' '
>   	git reset --hard &&
>   	echo test >other-file &&


  parent reply	other threads:[~2026-09-25 16:04 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-19 21:26 [PATCH 0/2] Hi all, D. Ben Knoble
2026-09-19 21:26 ` [PATCH 1/2] builtin/stash: remove unused header D. Ben Knoble
2026-09-21 15:10   ` Junio C Hamano
2026-09-19 21:26 ` [PATCH 2/2] builtin/stash: merge index in-core D. Ben Knoble
2026-09-21 13:17   ` Phillip Wood
2026-09-22 12:43     ` D. Ben Knoble
2026-09-22 12:51       ` D. Ben Knoble
2026-09-22 13:57       ` Phillip Wood
2026-09-22 20:34         ` D. Ben Knoble
2026-09-19 21:32 ` [PATCH 0/2] Hi all, D. Ben Knoble
2026-09-23 12:58 ` [PATCH v2 0/4] stash: clean up index-mode test merge D. Ben Knoble
2026-09-23 12:58   ` [PATCH v2 1/4] builtin/stash: remove unused header D. Ben Knoble
2026-09-23 12:58   ` [PATCH v2 2/4] stash: prepare merge options earlier D. Ben Knoble
2026-09-23 12:58   ` [PATCH v2 3/4] t: test failed "stash apply --index" D. Ben Knoble
2026-09-24  9:42     ` Phillip Wood
2026-09-25 13:36       ` D. Ben Knoble
2026-09-25 15:45         ` Phillip Wood
2026-09-26  9:53           ` Phillip Wood
2026-09-26 12:07             ` D. Ben Knoble
2026-09-23 12:58   ` [PATCH v2 4/4] builtin/stash: merge index in-core D. Ben Knoble
2026-09-24  9:42     ` Phillip Wood
2026-09-25 12:55       ` D. Ben Knoble
2026-09-25 15:58         ` Phillip Wood
2026-09-25 16:16           ` D. Ben Knoble
2026-09-24 21:59     ` Junio C Hamano
2026-09-25  4:12       ` Junio C Hamano
2026-09-25 13:00       ` D. Ben Knoble
2026-09-25 16:24         ` Junio C Hamano
2026-09-26  9:51           ` Phillip Wood
2026-09-26 12:04             ` D. Ben Knoble
2026-09-25 16:04       ` Phillip Wood [this message]
2026-09-25 16:17         ` D. Ben Knoble
2026-09-25 16:49           ` Junio C Hamano
2026-09-26 12:16   ` [PATCH v3 0/5] stash: clean up index-mode test merge D. Ben Knoble
2026-09-26 12:16     ` [PATCH v3 1/5] builtin/stash: remove unused header D. Ben Knoble
2026-09-26 12:16     ` [PATCH v3 2/5] stash: prepare merge options earlier D. Ben Knoble
2026-09-26 12:16     ` [PATCH v3 3/5] t3903: test stash --index merges D. Ben Knoble
2026-09-28 15:44       ` Phillip Wood
2026-09-28 15:55         ` D. Ben Knoble
2026-09-29  9:41           ` Phillip Wood
2026-09-26 12:16     ` [PATCH v3 4/5] t3903: test failed "stash apply --index" D. Ben Knoble
2026-09-26 12:16     ` [PATCH v3 5/5] builtin/stash: merge index in-core D. Ben Knoble
2026-09-27 18:59       ` Junio C Hamano
2026-09-28 12:02         ` D. Ben Knoble
2026-09-28  9:40       ` Junio C Hamano
2026-09-28 12:03         ` D. Ben Knoble
2026-09-28 15:32           ` Junio C Hamano
2026-09-26 12:20     ` [PATCH v3 0/5] stash: clean up index-mode test merge D. Ben Knoble
2026-09-27 19:21     ` Junio C Hamano
2026-09-28  9:50       ` Phillip Wood
2026-09-28 12:05         ` D. Ben Knoble
2026-09-28 12:33           ` D. Ben Knoble
2026-09-28 13:00             ` D. Ben Knoble
2026-09-28 13:45               ` Phillip Wood
2026-09-28 14:50                 ` Thomas Bachem
2026-09-28 15:36                   ` D. Ben Knoble
2026-09-29 11:38                     ` D. Ben Knoble
2026-09-29 15:54                     ` Phillip Wood
2026-09-28 15:40                   ` Phillip Wood
2026-09-29 12:18 ` [PATCH v4 " D. Ben Knoble
2026-09-29 12:18   ` [PATCH v4 1/5] builtin/stash: remove unused header D. Ben Knoble
2026-09-29 12:18   ` [PATCH v4 2/5] stash: prepare merge options earlier D. Ben Knoble
2026-09-29 12:18   ` [PATCH v4 3/5] t3903: test failed "stash apply --index" D. Ben Knoble
2026-09-29 12:18   ` [PATCH v4 4/5] t5520: don't expire reflogs where it matters D. Ben Knoble
2026-09-29 15:46     ` Phillip Wood
2026-09-29 12:18   ` [PATCH v4 5/5] builtin/stash: merge index in-core D. Ben Knoble
2026-09-29 20:07     ` Junio C Hamano
2026-09-30  1:29       ` D. Ben Knoble
2026-09-29 15:48   ` [PATCH v4 0/5] stash: clean up index-mode test merge Phillip Wood
2026-09-29 17:31     ` Ben Knoble
2026-09-30 21:26       ` D. Ben Knoble
2026-09-30 21:24 ` [PATCH v5 0/4] " D. Ben Knoble
2026-09-30 21:24   ` [PATCH v5 1/4] builtin/stash: remove unused header D. Ben Knoble
2026-09-30 21:24   ` [PATCH v5 2/4] stash: prepare merge options earlier D. Ben Knoble
2026-09-30 21:24   ` [PATCH v5 3/4] t3903: test failed "stash apply --index" D. Ben Knoble
2026-09-30 21:24   ` [PATCH v5 4/4] builtin/stash: merge index in-core D. Ben Knoble
2026-10-01 15:52   ` [PATCH v5 0/4] stash: clean up index-mode test merge Phillip Wood
2026-10-01 17:47     ` Junio C Hamano

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=6e6420e8-3cbd-4975-a781-645e1ffbc1d2@gmail.com \
    --to=phillip.wood123@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=avarab@gmail.com \
    --cc=ben.knoble@gmail.com \
    --cc=eli@barzilay.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=me@adamj.eu \
    --cc=newren@gmail.com \
    --cc=peff@peff.net \
    --cc=phillip.wood@dunelm.org.uk \
    --cc=ps@pks.im \
    --cc=stolee@gmail.com \
    --cc=vdye@github.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