Re: [GSoC] [RFC] stashing unmerged index entries
- Date: Tue, 9 Apr 2019 18:01:19 +0700
- From: Duy Nguyen <pclouds@xxxxxxxxx>
- Subject: Re: [GSoC] [RFC] stashing unmerged index entries
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 ?