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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Dec 4, 2018 at 6:26 PM Junio C Hamano <gitster@xxxxxxxxx> wrote:
>
> Duy Nguyen <pclouds@xxxxxxxxx> writes:
>
> > On Tue, Dec 4, 2018 at 6:43 PM Elijah Newren <newren@xxxxxxxxx> 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.  :-)

> > 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@xxxxxxxxxxxxxxxxxxxxxxxxx>

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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux