On Fri, Aug 16, 2019 at 9:51 AM Junio C Hamano <gitster@xxxxxxxxx> wrote:
>
> Elijah Newren <newren@xxxxxxxxx> writes:
>
> > Now, a manual merge of these files gives no conflicts, which surprises me:
> >
> > $ git merge-file ours base theirs; echo $?
> > 0
>
> Indeed that is surprising.
>
> > -- 8< --
> > Subject: checkout: remove duplicate code
> >
> > Both commit a7256debd4b6 ("checkout.txt: note about losing staged
> > changes with --merge", 2019-03-19) from nd/checkout-m-doc-update and
> > commit 6eff409e8a76 ("checkout: prevent losing staged changes with
> > --merge", 2019-03-22) from nd/checkout-m were included in git.git
> > despite the fact that the latter was meant to be v2 of the former.
> > The merge of these two topics resulted in a redundant chunk of code;
> > remove it.
> >
> > Signed-off-by: Elijah Newren <newren@xxxxxxxxx>
>
> The latter half that you remove cannot be reached, because the first
> half would have already died after checking the same condition, so
> we were doing the same repo-index-has-changes check twice when there
> is no change; in other words, we were lucky that this accidental dup
> did not cause any real damange.
Yes, but I am wondering if there are other cases we just don't know
about yet and for which we did not get lucky.
I dug a little further and found that even the first version of `git
merge-file` that Dscho added to git in 2006 also exhibited the same
behavior. Since he was basically making a minimal replacement for RCS
merge, I tried out /usr/bin/merge from the rcs package and found it
has the same behavior. I then downloaded the oldest tarball on the
GNU ftp site I could find for rcs (5.7 from June 1995) and found that
its' merge command had the same behavior.
I'm not sure if that alarms me (not only have all versions of git
potentially been mis-merging things, but all versions of rcs, cvs, and
probably any other version control system out there in current use),
or comforts me ("hey, it's been around for at least 24 years so it
must only mis-merge things in both rare and innocuous ways or else
someone would have noticed it decades ago")
I'm leaning towards "It can't be that bad; I'll look at it again later
if someone else who knows xdiff better hasn't already solved it"
