On Mon, Apr 8, 2019 at 12:09 AM Thomas Gummerer <t.gummerer@xxxxxxxxx> 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.
> >
> > 1) in repo_read_index_unmerged(), why don't we make the value of
> > `unmerged` 0, if adding index entry is successful; as the entry is no
> > longer unmerged ?
>
> Because the caller often wants to know if the index is unmerged in the
> first place, and would refuse to operate on such an index. Read the
> comment documenting the function again, that explains this very
> nicely. Then see how some callers actually use the function, and
> you'll see that they actually don't care about dropping the entry to
> stage 0,
>but they care about knowing whether the index is unmerged or
> not.
if they care about whether the index *is* unmerged, and that call to
add_index_entry()
is successful, then index is no longer unmerged (at least because of
that index_entry).
is it possible that they care about if index *was* unmerged ?
> So the question is, did you read this function in depth and understand
> what it does? If you want to validate your understanding of the
> function, try to repeat what it does in your own words, and ask for us
> to correct you.
upcoming mail will do so.
