{"thread":{"id":"53725","subject":"reset --merge documentation typo?","startedAt":"2020-06-20T16:16:34Z","lastAt":"2020-06-20T20:32:16Z","messageCount":3,"participants":["Solomon Ucko","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"400255","messageId":"CANtMP6qbX_U_0sWtUvNQVtMboMLJshsHc=n-5eA4_XXNGEnzLQ@mail.gmail.com","threadId":"53725","inReplyTo":null,"subject":"reset --merge documentation typo?","fromName":"Solomon Ucko","fromEmail":"solly.ucko@gmail.com","sentAt":"2020-06-20T16:15:54Z","receivedAt":"2020-06-20T16:16:34Z","isPatch":false,"sender":{"key":"solly.ucko@gmail.com","avatar":"https://gravatar.com/avatar/487b91b46eda9ca603fb9b4b93c45d27c542f0dc7429382d695204832b0b2e52?d=mp&s=160"},"body":"Oops, accidentally sent as HTML instead of plain text.\n\nThe documentation for `git reset --merge` states:\n\n> Resets the index and updates the files in the working tree that are\n> different between `<commit>` and `HEAD`, but keeps those which are\n> different between the index and working tree (i.e. which have changes\n> which have not been added).\n> If a file that is different between `<commit>` and the index has\n> unstaged changes, reset is aborted.\n>\n> In other words, `--merge` does something like a `git read-tree -u -m <commit>`,\n> but carries forward unmerged index entries.\n\nWhere it says \"`HEAD`\", should it say \"the index\"?\n\nThanks,\nSolomon Ucko\n"},{"id":"400258","messageId":"xmqqo8pdekqu.fsf@gitster.c.googlers.com","threadId":"53725","inReplyTo":"CANtMP6qbX_U_0sWtUvNQVtMboMLJshsHc=n-5eA4_XXNGEnzLQ@mail.gmail.com","subject":"Re: reset --merge documentation typo?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-06-20T16:59:37Z","receivedAt":"2020-06-20T16:59:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Solomon Ucko <solly.ucko@gmail.com> writes:\n\n> Oops, accidentally sent as HTML instead of plain text.\n>\n> The documentation for `git reset --merge` states:\n\nIt is talknig about `git reset --merge <commit>`.\n\n\n>> Resets the index and updates the files in the working tree that are\n>> different between `<commit>` and `HEAD`, but keeps those which are\n>> different between the index and working tree (i.e. which have changes\n>> which have not been added).\n\nCorrect.  The command makes this request to \"git\".\n\n    I am on the commit at `HEAD`; I want to move to <commit> as if I\n    did \"git checkout <otherbranch>\", updating the files in the\n    working tree to that of <otherbranch> except that if I had local\n    changes from `HEAD` for a path, and the path is identical\n    between `HEAD` and <otherbranch>, carry my local changes along,\n    but I am not flipping to a different branch---instead I am\n    resetting the tip of the current branch.\n\nIt allows the user to pretend as if the user started making these\nlocal changes _after_ \"git reset --hard <commit>\", on top of\n<commit>, and that is only possible because the command makes sure\nthat the paths involved in these local changes are the same between\n`HEAD` and <commit>.\n\n> Where it says \"`HEAD`\", should it say \"the index\"?\n\nNo.\n"},{"id":"400260","messageId":"CANtMP6o8025ZcFWZ081jgHp8dykcBje7QCQh-MtzwSz4CKuSSg@mail.gmail.com","threadId":"53725","inReplyTo":"xmqqo8pdekqu.fsf@gitster.c.googlers.com","subject":"Re: reset --merge documentation typo?","fromName":"Solomon Ucko","fromEmail":"solly.ucko@gmail.com","sentAt":"2020-06-20T20:30:08Z","receivedAt":"2020-06-20T20:32:16Z","isPatch":false,"sender":{"key":"solly.ucko@gmail.com","avatar":"https://gravatar.com/avatar/487b91b46eda9ca603fb9b4b93c45d27c542f0dc7429382d695204832b0b2e52?d=mp&s=160"},"body":"On Sat, Jun 20, 2020 at 12:59 PM Junio C Hamano <gitster@pobox.com> wrote:\n> > The documentation for `git reset --merge` states:\n> It is talknig about `git reset --merge <commit>`.\n\nYep, that's what I meant to say.\n\n>     I am on the commit at `HEAD`; I want to move to <commit> as if I\n>     did \"git checkout <otherbranch>\", updating the files in the\n>     working tree to that of <otherbranch> except that if I had local\n>     changes from `HEAD` for a path, and the path is identical\n>     between `HEAD` and <otherbranch>, carry my local changes along,\n>     but I am not flipping to a different branch---instead I am\n>     resetting the tip of the current branch.\n>\n> It allows the user to pretend as if the user started making these\n> local changes _after_ \"git reset --hard <commit>\", on top of\n> <commit>, and that is only possible because the command makes sure\n> that the paths involved in these local changes are the same between\n> `HEAD` and <commit>.\n\nThat makes sense, thanks.\n\n> > Where it says \"`HEAD`\", should it say \"the index\"?\n> No.\n\nI wrote a simple bash script (let me know if I should send it) to test\nthe behavior of `git reset --merge <commit>`, and got the following\nresults. I hard-coded the combinations; did I miss any?\n\n    (working tree, index, (HEAD), target commit => resulting working tree)\n    AA(A)A => A\n    AA(A)B => B\n    AA(B)A => A\n    AA(B)B => B\n    AA(B)C => C\n    AB(A)A => abort\n    AB(A)B => A\n    AB(A)C => abort\n    AB(B)A => abort\n    AB(B)B => A\n    AB(B)C => abort\n    AB(C)A => abort\n    AB(C)B => A\n    AB(C)C => abort\n    AB(C)D => abort\n\nIt appears that the file contents in HEAD have no effect on the result.\n\nAlso, the AB(A)B => A case only seems to make sense with \"`HEAD`\"\nreplaced with \"the index\" in the explanation, since the version in the\nworking tree matches the version in `HEAD`, but is kept anyways, since\nit differs from the index's. Since the index's file matches the target\ncommit's, the operation is not aborted.\n\nSame thing for the AA(B)B => B and AA(B)C => C cases: the working tree\ndiffers from `HEAD`, so the working tree's version should have been\nkept, but instead, since the working tree matches the index, the\ntarget's version is used.\n\nFYI, I'm testing with git version 2.20.1. Was this behavior changed recently?\n\nSolomon Ucko\n"}]}