public inbox for git@vger.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Sam Bostock via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org,  Sam Bostock <sam@sambostock.ca>
Subject: Re: [PATCH 2/2] merge-ours: integrate with sparse-index
Date: Fri, 06 Feb 2026 05:35:51 -0800	[thread overview]
Message-ID: <xmqq343ehu4o.fsf@gitster.g> (raw)
In-Reply-To: <20b9e0bf6e2b12eea1ff50b14d0d2809c601a943.1770345124.git.gitgitgadget@gmail.com> (Sam Bostock via GitGitGadget's message of "Fri, 06 Feb 2026 02:32:04 +0000")

"Sam Bostock via GitGitGadget" <gitgitgadget@gmail.com> writes:

> From: Sam Bostock <sam@sambostock.ca>
>
> The merge-ours builtin reads the index only to compare it against HEAD
> via index_differs_from(), whose diff machinery (run_diff_index) is
> already sparse-aware.
>
> Teach merge-ours to opt out of requiring a full index by setting
> command_requires_full_index to 0.

> Because merge-ours is invoked as a
> subprocess by "git merge -s ours"

It may be correct but I do not see a relevance

> and never previously read config,
> the global variables core_apply_sparse_checkout and
> core_sparse_checkout_cone remained unset,

This may be correct, but it only becomes relevant after somebody
decides to do something to cause is_sparse_index_allowed() to say
Yes.

> causing
> is_sparse_index_allowed() to return false and the index to be expanded
> anyway. Add a repo_config() call with git_default_config to populate
> these globals.

In total, while individual sentences in the above may tell correct
things, the order of presentation makes it hard to understand, at
least to me.

The usual way to compose a log message of this project is to

 - Give an observation on how the current system works in the
   present tense (so no need to say "Currently X is Y", or
   "Previously X was Y" to describe the state before your change;
   just "X is Y" is enough), and discuss what you perceive as a
   problem in it.

 - Propose a solution (optional---often, problem description
   trivially leads to an obvious solution in reader's minds).

 - Give commands to somebody editing the codebase to "make it so",
   instead of saying "This commit does X".

in this order.

So perhaps

    The merge-ours built-in opens the index to compare it against
    HEAD.  The machinery used to do this (i.e. run_diff_index()) is
    capable of working with sparse index, but because of the start
    up sequence of this command does not take necessary steps, we
    end up first expanding the index fully before doing this
    comparison.

    In order to convince sparse-index.c:is_sparse_index_allowed() to
    return true, we need to:

    - enable the global switch "core_apply_sparse_checkout" via
      the core.sparsecheckout configuration variable.  merge-ours
      currently do not even read basic configuration, so we need to
      make the configuration call ourselves.

    - set command_requires_full_index to 0.

    With that, the command can work without expanding the index
    fully before doing its work.

or something.

Thanks.

> Add tests to t1092 verifying that "git merge -s ours" produces
> identical results across full-checkout, sparse-checkout, and
> sparse-index modes, including verifying the resulting merge commit
> structure, and that the sparse index is not expanded during the
> operation.
>
> Signed-off-by: Sam Bostock <sam@sambostock.ca>
> ---
>  builtin/merge-ours.c                     |  6 ++++++
>  t/t1092-sparse-checkout-compatibility.sh | 14 ++++++++++++++
>  2 files changed, 20 insertions(+)
>
> diff --git a/builtin/merge-ours.c b/builtin/merge-ours.c
> index 2312e58ab3..405b2989f7 100644
> --- a/builtin/merge-ours.c
> +++ b/builtin/merge-ours.c
> @@ -10,6 +10,8 @@
>  
>  #include "git-compat-util.h"
>  #include "builtin.h"
> +#include "config.h"
> +#include "environment.h"
>  #include "diff.h"
>  
>  static const char builtin_merge_ours_usage[] =
> @@ -22,6 +24,10 @@ int cmd_merge_ours(int argc,
>  {
>  	show_usage_if_asked(argc, argv, builtin_merge_ours_usage);
>  
> +	repo_config(repo, git_default_config, NULL);
> +	prepare_repo_settings(repo);
> +	repo->settings.command_requires_full_index = 0;
> +
>  	/*
>  	 * The contents of the current index becomes the tree we
>  	 * commit.  The index must match HEAD, or this merge cannot go
> diff --git a/t/t1092-sparse-checkout-compatibility.sh b/t/t1092-sparse-checkout-compatibility.sh
> index b0f691c151..d98cb4ac11 100755
> --- a/t/t1092-sparse-checkout-compatibility.sh
> +++ b/t/t1092-sparse-checkout-compatibility.sh
> @@ -2559,4 +2559,18 @@ test_expect_success 'cat-file --batch' '
>  	ensure_expanded cat-file --batch <in
>  '
>  
> +test_expect_success 'merge -s ours' '
> +	init_repos &&
> +
> +	test_all_match git rev-parse HEAD^{tree} &&
> +	test_all_match git merge -s ours merge-right &&
> +	test_all_match git rev-parse HEAD^{tree} &&
> +	test_all_match git rev-parse HEAD^2
> +'
> +
> +test_expect_success 'sparse-index is not expanded: merge-ours' '
> +	init_repos &&
> +	ensure_not_expanded merge -s ours merge-right
> +'
> +
>  test_done

  reply	other threads:[~2026-02-06 13:35 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-06  2:32 [PATCH 0/2] merge-ours: sparse-index integration Sam Bostock via GitGitGadget
2026-02-06  2:32 ` [PATCH 1/2] merge-ours: drop USE_THE_REPOSITORY_VARIABLE Sam Bostock via GitGitGadget
2026-02-06 15:02   ` Patrick Steinhardt
2026-02-06 17:33     ` Junio C Hamano
2026-02-06  2:32 ` [PATCH 2/2] merge-ours: integrate with sparse-index Sam Bostock via GitGitGadget
2026-02-06 13:35   ` Junio C Hamano [this message]
2026-02-06 19:16 ` [PATCH v2 0/2] merge-ours: sparse-index integration Sam Bostock via GitGitGadget
2026-02-06 19:16   ` [PATCH v2 1/2] merge-ours: drop USE_THE_REPOSITORY_VARIABLE Sam Bostock via GitGitGadget
2026-02-06 19:16   ` [PATCH v2 2/2] merge-ours: integrate with sparse-index Sam Bostock via GitGitGadget
2026-02-09 15:05   ` [PATCH v2 0/2] merge-ours: sparse-index integration Patrick Steinhardt
2026-02-10  4:35   ` Derrick Stolee

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=xmqq343ehu4o.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=sam@sambostock.ca \
    /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