Re: GSoC 2019: Git's application submitted

> 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?

> >  - 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.