)]}'
{
  "commit": "8ae4c185a6d65533d0941ca39de1b98821ba7496",
  "tree": "df2d4e2dd4bdbd20bbd611212d64e69a35e231b5",
  "parents": [
    "b15661a2cd35ec4825be0dd9b69ac41bbd2157b3"
  ],
  "author": {
    "name": "D. Ben Knoble",
    "email": "ben.knoble@gmail.com",
    "time": "Wed Sep 30 17:24:41 2026 -0400"
  },
  "committer": {
    "name": "Junio C Hamano",
    "email": "gitster@pobox.com",
    "time": "Thu Oct 01 06:40:10 2026 -0700"
  },
  "message": "builtin/stash: merge index in-core\n\n\"git stash apply --index\" does a 2-step dance to report index conflicts\nbefore carrying out the main unstash: first, attempt to merge the index\n(and remember the name of the resulting tree). If that succeeds, reset\nthe index and carry on unstashing the working tree, then use the\nremembered index tree to unstash the index.\n\nThe \"merge the index\" step is performed on the actual index by a\ncombination of git-diff-tree(1) and git-apply(1), which incurs an extra\ncost to git-reset(1) to cleanup. This also introduces an autostash bug\nwhen stash.index is true: \"git reset\" eventually wants to\nremove_merge_branch_state(), which calls save_autostash() due to\na03b55530a (merge: teach --autostash option, 2020-04-07). This can\nhappen from a \"git merge --autostash\", which itself calls\nsave_autostash(). Operating on the file-system in this way is not\nre-entrant, so we end up trying to lock a now-deleted MERGE_AUTOSTASH\nref [1]. This bug has lurked for a while, but it would have been\nimpossible to trigger without the availability of stash.index to force\nthe autostash apply into index mode.\n\n[1]: https://lore.kernel.org/git/CALO-guvbk2TcrVwzdNQ3yRpzHr0HHZ3h1wite0Xp0sUyAT4otA@mail.gmail.com/\n\nFortunately, we can achieve 2 goals at once: avoid round-tripping to the\nfile-system (and invoking expensive subprocesses) by performing the\nmerge in-core. If there are conflicts, we discard the resulting tree, so\nwe don\u0027t see the usual branch and ancestor labels, but the merge\nsubroutines insist on their presence, so use something simple.\n\nWe need to take care to get the order of trees right when merging. Add a\ntest that covers this case.\n\nWe *could* swap just the git-reset(1) subprocess with our internal\nreset_tree() and refresh_index(), which would fix the bug. We\u0027d much\nprefer to clean up these vestiges of the shell-based git-stash, though.\n\nReported-by: Eli Barzilay \u003celi@barzilay.org\u003e\nHelped-by: Phillip Wood \u003cphillip.wood@dunelm.org.uk\u003e\nHelped-by: Junio C Hamano \u003cgitster@pobox.com\u003e\nSigned-off-by: D. Ben Knoble \u003cben.knoble@gmail.com\u003e\nSigned-off-by: Junio C Hamano \u003cgitster@pobox.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "d2b736d4e669429a736e9c41ccff7db1156fd684",
      "old_mode": 33188,
      "old_path": "builtin/stash.c",
      "new_id": "fa3deeecbe0534ce1a556c7a5eb1b54b0246a443",
      "new_mode": 33188,
      "new_path": "builtin/stash.c"
    },
    {
      "type": "modify",
      "old_id": "70af58e161539a926c76dd2cb37973a53f28993c",
      "old_mode": 33261,
      "old_path": "t/t3903-stash.sh",
      "new_id": "70c60319588190e206255dd8ec3e6c7c7fb944a9",
      "new_mode": 33261,
      "new_path": "t/t3903-stash.sh"
    },
    {
      "type": "modify",
      "old_id": "64fe21717db0d470f9cd3580b5ea5728cfc7832f",
      "old_mode": 33261,
      "old_path": "t/t7600-merge.sh",
      "new_id": "8f6109fb91f54c7110519a5fc84425de7cf4a9fd",
      "new_mode": 33261,
      "new_path": "t/t7600-merge.sh"
    }
  ]
}