Skip to content
Permalink

Comparing changes

Choose two branches to see what’s changed or to start a new pull request. If you need to, you can also or learn more about diff comparisons.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also . Learn more about diff comparisons here.
base repository: git/git
Failed to load repositories. Confirm that selected base ref is valid, then try again.
Loading
base: dd33e738a469cb7841a4a6132bdce1809d0772aa
Choose a base ref
...
head repository: git/git
Failed to load repositories. Confirm that selected head ref is valid, then try again.
Loading
compare: d563ecec2845467880f5742e178a9723afef495a
Choose a head ref
  • 8 commits
  • 16 files changed
  • 1 contributor

Commits on Mar 3, 2026

  1. add-patch: split out header from "add-interactive.h" 

    While we have a "add-patch.c" code file, its declarations are part of
"add-interactive.h". This makes it somewhat harder than necessary to
find relevant code and to identify clear boundaries between the two
subsystems.

Split up concerns and move declarations that relate to "add-patch.c"
into a new "add-patch.h" header.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
    @pks-t @gitster
    pks-t authored and gitster committed Mar 3, 2026
    Configuration menu
    Copy the full SHA
    6e4d923 View commit details
    Browse the repository at this point in the history

  2. add-patch: split out struct interactive_options 

    The `struct add_p_opt` is reused both by our infra for "git add -p" and
"git add -i". Users of `run_add_i()` for example are expected to pass
`struct add_p_opt`. This is somewhat confusing and raises the question
of which options apply to what part of the stack.

But things are even more confusing than that: while callers are expected
to pass in `struct add_p_opt`, these options ultimately get used to
initialize a `struct add_i_state` that is used by both subsystems. So we
are basically going full circle here.

Refactor the code and split out a new `struct interactive_options` that
hosts common options used by both. These options are then applied to a
`struct interactive_config` that hosts common configuration.

This refactoring doesn't yet fully detangle the two subsystems from one
another, as we still end up calling `init_add_i_state()` in the "git add
-p" subsystem. This will be fixed in a subsequent commit.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
    @pks-t @gitster
    pks-t authored and gitster committed Mar 3, 2026
    Configuration menu
    Copy the full SHA
    e3d4d77 View commit details
    Browse the repository at this point in the history

  3. add-patch: remove dependency on "add-interactive" subsystem 

    With the preceding commit we have split out interactive configuration
that is used by both "git add -p" and "git add -i". But we still
initialize that configuration in the "add -p" subsystem by calling
`init_add_i_state()`, even though we only do so to initialize the
interactive configuration as well as a repository pointer.

Stop doing so and instead store and initialize the interactive
configuration in `struct add_p_state` directly.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
    @pks-t @gitster
    pks-t authored and gitster committed Mar 3, 2026
    Configuration menu
    Copy the full SHA
    d51b61f View commit details
    Browse the repository at this point in the history

  4. add-patch: add support for in-memory index patching 

    With `run_add_p()` callers have the ability to apply changes from a
specific revision to a repository's index. This infra supports several
different modes, like for example applying changes to the index,
working tree or both.

One feature that is missing though is the ability to apply changes to an
in-memory index different from the repository's index. Add a new
function `run_add_p_index()` to plug this gap.

This new function will be used in a subsequent commit.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
    @pks-t @gitster
    pks-t authored and gitster committed Mar 3, 2026
    Configuration menu
    Copy the full SHA
    0c5583a View commit details
    Browse the repository at this point in the history

  5. add-patch: allow disabling editing of hunks 

    The "add-patch" mode allows the user to edit hunks to apply custom
changes. This is incompatible with a new `git history split` command
that we're about to introduce in a subsequent commit, so we need a way
to disable this mode.

Add a new flag to disable editing hunks.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
    @pks-t @gitster
    pks-t authored and gitster committed Mar 3, 2026
    Configuration menu
    Copy the full SHA
    48f6d92 View commit details
    Browse the repository at this point in the history

  6. cache-tree: allow writing in-memory index as tree 

    The function `write_in_core_index_as_tree()` takes a repository and
writes its index into a tree object. What this function cannot do though
is to take an _arbitrary_ in-memory index.

Introduce a new `struct index_state` parameter so that the caller can
pass a different index than the one belonging to the repository. This
will be used in a subsequent commit.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
    @pks-t @gitster
    pks-t authored and gitster committed Mar 3, 2026
    Configuration menu
    Copy the full SHA
    a021e4f View commit details
    Browse the repository at this point in the history

  7. builtin/history: split out extended function to create commits 

    In the next commit we're about to introduce a new command that splits up
a commit into two. Most of the logic will be shared with rewording
commits, except that we also need to have control over the parents and
the old/new trees.

Extract a new function `commit_tree_with_edited_message_ext()` to
prepare for this commit.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
    @pks-t @gitster
    pks-t authored and gitster committed Mar 3, 2026
    Configuration menu
    Copy the full SHA
    98f8394 View commit details
    Browse the repository at this point in the history

  8. builtin/history: implement "split" subcommand 

    It is quite a common use case that one wants to split up one commit into
multiple commits by moving parts of the changes of the original commit
out into a separate commit. This is quite an involved operation though:

  1. Identify the commit in question that is to be dropped.

  2. Perform an interactive rebase on top of that commit's parent.

  3. Modify the instruction sheet to "edit" the commit that is to be
     split up.

  4. Drop the commit via "git reset HEAD~".

  5. Stage changes that should go into the first commit and commit it.

  6. Stage changes that should go into the second commit and commit it.

  7. Finalize the rebase.

This is quite complex, and overall I would claim that most people who
are not experts in Git would struggle with this flow.

Introduce a new "split" subcommand for git-history(1) to make this way
easier. All the user needs to do is to say `git history split $COMMIT`.
From hereon, Git asks the user which parts of the commit shall be moved
out into a separate commit and, once done, asks the user for the commit
message. Git then creates that split-out commit and applies the original
commit on top of it.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
    @pks-t @gitster
    pks-t authored and gitster committed Mar 3, 2026
    Configuration menu
    Copy the full SHA
    d563ece View commit details
    Browse the repository at this point in the history
Loading