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.
