On 02/07, Johannes Schindelin wrote: > Hi Thomas, > > On Wed, 6 Feb 2019, Thomas Gummerer wrote: > > - implement pushing the index state, without dealing with conflicts > > - implement poping the index state, without dealing with conflicts > > > > This can already be individually useful, and I think this is > > something people asked for on the mailing list, though I didn't try > > digging up old threads for now. After these two steps stashing and > > restoring a merge conflict would still not work, but we have a good > > first step that could be merged. > > We already have `git stash --keep-index`. Is this what you mean here? `git stash --keep-index` does something different, what I meant here was what `git stash pop --index` already does. I had forgotten that this functionality already exists. > > - implement pushing/poping conflicted state > > > > This would obviously be the end goal. > > On second thought, this might actually be super trivial. Right now, we > support two modes (not counting the `--untracked` stuff): --keep-index and > --no-keep-index. In both cases, we seem to create a merge commit whose > tree reflects the working directory and whose first parent is HEAD and > whose second parent is a single commit on top of HEAD (which contains > either no changes in the case of --no-keep-index, or whose tree reflects > the index in case of --keep-index). > > To extend that to the conflict case, we could introduce a new flag > --with-conflicts, and have the commit structure > > Worktree > | \ > | index stage 0 > | / | \ > | stage 1 stage 2 stage 3 > | / / / > HEAD --------------- > > The only tricky thing I can see is to maintain backwards compatibility if > possible, so that old `git stash` will do something at least semi-sensible > with those commit structures. > > It might be too small a project, after all. Yeah, looking at this I think you're right. Thanks for helping work through this. > Ciao, > Dscho
