Subject: Re: GSoC 2019: Git's application submitted

From: Thomas Gummerer <[email-masked]>
Date: Thu, 7 Feb 2019 21:33:26 +0000

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