On Tue, Apr 9, 2019 at 3:16 PM Kapil Jain <jkapil.cs@xxxxxxxxx> wrote: > > Reference: https://git.github.io/SoC-2019-Ideas/#teach-git-stash-to-handle-unmerged-index-entries > > "When the index is unmerged, git stash refuses to do anything. That is > unnecessary, though, as it could easily craft e.g. an octopus merge of > the various stages. A subsequent git stash apply can detect that > octopus and re-generate the unmerged index." > > according to it we take the unmerged entries (caused by conflicted > merge) in index from all stages, and do an octopus merge. how does > this solve the problem, i mean where do those entries go after octopus > merge ? I'm not even into git-stash, but it does sound like it solves the problem, which is _restoring_ the conflict after you unstash. Since you have all the unmerged entries in the merge (which is stored in some stash ref), you can safely destroy all conflicts in worktree and put it back to a clean state. When people want to apply the stash, you re-generate the unmerged index from the octopus merge. > a conflicted merge is still there, yes, but because you can restore it later now, you can remove the conflict safely. That's what git-stash is for. > do we store the merge separately ? -- Duy
