Duy Nguyen <pclo...@gmail.com> writes: > On Tue, Dec 4, 2018 at 6:43 PM Elijah Newren <new...@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. > 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....@gitster-ct.c.googlers.com>
