Re: [RFC PATCH] sequencer - tipped merge strategy

[Edmundo Carmona Antoranz <eantoranz@gmail.com>]

Hey, Elijah!

Thank you for all of that feedback. Really good Will need to go
through it which will take me some time to digest but I did want to go
over one of the subjects.


> So, if I'm reading correctly (please double check me), since your
> merge strategy made no changes to the index or working tree, and
> returned a status of 2, and since !2 == !1 == 0, we'll treat this the
> same as a successful merge and commit the "results", i.e. the tree of
> the first parent.  Doesn't this tipped merge strategy thus behave the
> same as a `--strategy ours` merge when its preconditions are not
> satisfied?  If it does, that would be horrifying.

I think that is not correct. The possible values that come out of
try_tms_merge are 0 if nothing happened and 1 if the merge was
successful and we changed the index and the working tree. Then I think
I wrote this correctly following the call:

if (ret) {
  discard_index(r->index);
  if (repo_read_index(r) < 0) {
    ret = error(_("could not read index"));
    goto leave_merge;
  }
  goto ran_merge;
}
// regain lock to go into recursive
if (repo_hold_locked_index(r, &lock, LOCK_REPORT_ON_ERROR) < 0) {
  ret = -1;
  goto leave_merge;
}

Actually, if we will be switching to using a library, then this won't
be that important because we might be able to pull it off without
having to release the lock given that we would be running in-process,
but I wanted to clear up what the intended flow is there, just in
case.

Ok.... more questions or comments will be coming in the following
days. And thank you, again.

BR!