Re: [GSoC][RFC] discussion about stashing with conflicts

>
> On Mon, Apr 8, 2019 at 12:09 AM Thomas Gummerer <t.gummerer@gmail.com> wrote:
> >
> > On 04/07, Kapil Jain wrote:
> > >
> > > what is the use of ce_stage macro ?
> > > tells about stage of an index entry.
> > > if ce_stage says, stage #0 i.e staging area, then that index entry is
> > > in staging area
> > > and nothing needs to be done.
> >
> > I don't quite understand what you mean with "nothing needst to be
> > done" here.  In the context of teaching 'git stash' to handle unmerged
> > index entries, nothing that is not already being done needs to be done
> > with an index entry that is at stage #0.  The current implementation
> > already handles that correctly.
> >
> > > else a temporary index entry is created and repo_read_index_unmerged()
> > > calls other function and tries to add it to index.
> > > if it fails, it issues an error.
> >
> > Not sure what you mean here.  Index entries with higher stages are not
> > temporary, they are written out to the index file, and can then be
> > read back with 'repo_read_index()' for example.
>
> sorry, i failed to provide detailed explanation. below is what i meant.
>
> in repo_read_index_merged(),
> if ce_stage() macro says that this cache_entry is in stage #0 i.e.
> already merged,
> then the function doesn't try to add that entry into index.
>
> if (!ce_stage(ce))
>     continue;
>
> but when it is not in stage #0; the function, creates a temporary cache_entry,
>
> struct cache_entry *new_ce;
> new_ce = make_empty_cache_entry(istate, len);
>
> and tries to add it to index file.
>
> if (add_index_entry(istate, new_ce, ADD_CACHE_SKIP_DFCHECK))
>     return error(_("%s: cannot drop to stage #0"),
>              new_ce->name);
>
> now if this try of adding index entry is successful, then that entry
> is no longer unmerged, right ?
> so can we make `unmerged` variable 0.