Re: [PATCH v3 07/14] checkout: split into switch-branch and restore-files

From: Elijah Newren <newren@gmail.com>
Date: Dec 5, 2018, 04:45 UTC
Message-ID: <CABPp-BGZF8s=ReiC=jTKKQbt1LLO72K7a_2pYbQHrw0ZeA9J5w@mail.gmail.com>
In-Reply-To: <xmqqpnugemks.fsf@gitster-ct.c.googlers.com>

On Tue, Dec 4, 2018 at 6:26 PM Junio C Hamano <gitster@pobox.com> wrote:

Show 21 quoted lines

>
> Duy Nguyen <pclouds@gmail.com> writes:
>
> > On Tue, Dec 4, 2018 at 6:43 PM Elijah Newren <newren@gmail.com> wrote:
> >> > > > +--ours::
> >> > > > +--theirs::
> >> ...
> >> go away.  Maybe it can still be fixed (I haven't dug too deeply into
> >> it), but if so, the only fix needed here would be to remove this long
> >> explanation about why the tool gets things totally backward.
> >
> > Aha. I' not really deep in this merge business to know if stages 2 and
> > 3 can be swapped. This is right up your alley. I'll just leave it to
> > you.
>
> Please don't show stage#2 and stage#3 swapped to the end user,
> unless that is protected behind an option (not per-repo config).
> It is pretty much ingrained that stage#2 is what came from the
> commit that will become the first parent of the commit being
> prepared, and changing it without an explicit command line option
> will break tools.

What depends on stage#2 coming from the commit that will become the first parent? I wasn't thinking in terms of modifying checkout/restore-files/diff/etc in a way that would make them show things different than what was recorded in the index, I was rather musing on whether it was feasible to have rebase tell the merge machinery to treat HEAD as stage #3 and the other commit as stage #2 so that it was swapping what was actually recorded in the index.

I know the merge machinery implicitly assumes HEAD == stage #2 in multiple places, and it'd obviously need a fair amount of fixing to handle this. I wasn't immediately aware of other things that would break. If you know of some, I'm happy to hear. Otherwise, I might go and learn the hard way (after I get around to the merge rewrite) why my idea is crazy. :-)

Show 9 quoted lines

> > I'm actually still not sure how to move it here (I guess 'here' is
> > restore-files since we won't move HEAD). All the --mixed, --merge and
> > --hard are confusing. But maybe we could just make 'git restore-files
> > --from HEAD -f :/" behave just like "git reset --hard HEAD" (but with
> > some safety net) But we can leave it for discussion in the next round.
>
> Perhaps you two should pay a bit closer attention to what Thomas
> Gummerer is working on.  I've touched above in my earlier comments,
> too, e.g.  <xmqqefb3mhrs.fsf@gitster-ct.c.googlers.com>

Indeed, I'm excited about his changes now; I'll keep an eye out.