git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: George Shammas <georgyo@gmail.com>
To: peff@peff.net
Cc: Junio C Hamano <gitster@pobox.com>, l.s.r@web.de, git@vger.kernel.org
Subject: Re: git merge -s subtree seems to be broken.
Date: Tue, 31 Jul 2018 15:52:26 -0400	[thread overview]
Message-ID: <CAF1Ko+FHsvmqzwVHh+fEnk=UGUftNW8VkFwaWTSKu3xYprb+wg@mail.gmail.com> (raw)
In-Reply-To: <20180731190459.GA3372@sigill.intra.peff.net>

[-- Attachment #1: Type: text/plain, Size: 7840 bytes --]

This is the fastest I ever seen an open source project respond to an issue
I reported. Thanks for being awesome!

On Tue, Jul 31, 2018 at 3:05 PM Jeff King <peff@peff.net> wrote:

> On Tue, Jul 31, 2018 at 01:23:04PM -0400, Jeff King wrote:
>
> > On Tue, Jul 31, 2018 at 10:17:15AM -0700, Junio C Hamano wrote:
> >
> > > Jeff King <peff@peff.net> writes:
> > >
> > > > +...
> > > > +         } else if (cmp > 0) {
> > > >                   /* path2 does not appear in one */
> > > > +                 score += score_missing(two.entry.mode,
> two.entry.path);
> > > > +                 update_tree_entry(&two);
> > > > +                 continue;
> > > > +         } if (oidcmp(one.entry.oid, two.entry.oid)) {
> > >
> > > As the earlier ones do the "continue at the end of the block", this
> > > does not affect the correctness, but I think you either meant "else if"
> > > or a fresh "if/else" that is disconnected from the previous if/else
> if/...
> > > chain.
> >
> > Yes, thanks. I actually started to write it without the "continue" at
> > all, and a big "else" that checked the "we have both" case. But I backed
> > that out (in favor of a smaller diff), and forgot to add back in the
> > "else if".
>
> So here it is fixed, and with a commit message. I'm not happy to omit a
> regression test, but I actually couldn't come up with a minimal one that
> tickled the problem, because we're playing around with heuristics. So I
> compensated by probably over-explaining in the commit message. But
> clearly this is not a well-tested code path given the length of time
> between introducing and detecting the bug.
>
> -- >8 --
> Subject: [PATCH] score_trees(): fix iteration over trees with missing
> entries
>
> In score_trees(), we walk over two sorted trees to find
> which entries are missing or have different content between
> the two.  So if we have two trees with these entries:
>
>   one   two
>   ---   ---
>   a     a
>   b     c
>   c     d
>
> we'd expect the loop to:
>
>   - compare "a" to "a"
>
>   - compare "b" to "c"; because these are sorted lists, we
>     know that the second tree does not have "b"
>
>   - compare "c" to "c"
>
>   - compare "d" to end-of-list; we know that the first tree
>     does not have "d"
>
> And prior to d8febde370 (match-trees: simplify score_trees()
> using tree_entry(), 2013-03-24) that worked. But after that
> commit, we mistakenly increment the tree pointers for every
> loop iteration, even when we've processed the entry for only
> one side. As a result, we end up doing this:
>
>   - compare "a" to "a"
>
>   - compare "b" to "c"; we know that we do not have "b", but
>     we still increment both tree pointers; at this point
>     we're out of sync and all further comparisons are wrong
>
>   - compare "c" to "d" and mistakenly claim that the second
>     tree does not have "c"
>
>   - exit the loop, mistakenly not realizing that the first
>     tree does not have "d"
>
> So contrary to the claim in d8febde370, we really do need to
> manually use update_tree_entry(), because advancing the tree
> pointer depends on the entry comparison.
>
> That means we must stop using tree_entry() to access each
> entry, since it auto-advances the pointer. Instead:
>
>   - we'll use tree_desc.size directly to know if there's
>     anything left to look at (which is what tree_entry() was
>     doing under the hood)
>
>   - rather than do an extra struct assignment to "e1" and
>     "e2", we can just access the "entry" field of tree_desc
>     directly
>
> That makes us a little more intimate with the tree_desc
> code, but that's not uncommon for its callers.
>
> There's no regression test here, as it's a little tricky to
> trigger this with a minimal example. The user-visible effect
> is that the heuristics fail to correlate two trees that
> should be. But in a minimal example, there aren't a lot of
> other trees to match, so we often end up doing the right
> thing anyway.
>
> A real-world example (from the original bug report) is:
>
> -- >8 --
> git init repo
> cd repo
>
> echo init >file
> git add file
> git commit -m init
>
> git remote add tig https://github.com/jonas/tig.git
> git fetch tig
> git merge -s ours --no-commit --allow-unrelated-histories tig-2.3.0
> git read-tree --prefix=src/ -u tig-2.3.0
> git commit -m 'get upstream tig-2.3.0'
>
> echo update >file
> git commit -a -m update
>
> git merge -s subtree tig-2.4.0
> -- 8< --
>
> Before this patch, we fail to realize that the tig-2.4.0
> content should go into the "src" directory.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
>  match-trees.c | 43 ++++++++++++++++++++++++++-----------------
>  1 file changed, 26 insertions(+), 17 deletions(-)
>
> diff --git a/match-trees.c b/match-trees.c
> index 4cdeff53e1..37653308d3 100644
> --- a/match-trees.c
> +++ b/match-trees.c
> @@ -83,34 +83,43 @@ static int score_trees(const struct object_id *hash1,
> const struct object_id *ha
>         int score = 0;
>
>         for (;;) {
> -               struct name_entry e1, e2;
> -               int got_entry_from_one = tree_entry(&one, &e1);
> -               int got_entry_from_two = tree_entry(&two, &e2);
>                 int cmp;
>
> -               if (got_entry_from_one && got_entry_from_two)
> -                       cmp = base_name_entries_compare(&e1, &e2);
> -               else if (got_entry_from_one)
> +               if (one.size && two.size)
> +                       cmp = base_name_entries_compare(&one.entry,
> &two.entry);
> +               else if (one.size)
>                         /* two lacks this entry */
>                         cmp = -1;
> -               else if (got_entry_from_two)
> +               else if (two.size)
>                         /* two has more entries */
>                         cmp = 1;
>                 else
>                         break;
>
> -               if (cmp < 0)
> +               if (cmp < 0) {
>                         /* path1 does not appear in two */
> -                       score += score_missing(e1.mode, e1.path);
> -               else if (cmp > 0)
> +                       score += score_missing(one.entry.mode,
> one.entry.path);
> +                       update_tree_entry(&one);
> +               } else if (cmp > 0) {
>                         /* path2 does not appear in one */
> -                       score += score_missing(e2.mode, e2.path);
> -               else if (oidcmp(e1.oid, e2.oid))
> -                       /* they are different */
> -                       score += score_differs(e1.mode, e2.mode, e1.path);
> -               else
> -                       /* same subtree or blob */
> -                       score += score_matches(e1.mode, e2.mode, e1.path);
> +                       score += score_missing(two.entry.mode,
> two.entry.path);
> +                       update_tree_entry(&two);
> +               } else {
> +                       /* path appears in both */
> +                       if (oidcmp(one.entry.oid, two.entry.oid)) {
> +                               /* they are different */
> +                               score += score_differs(one.entry.mode,
> +                                                      two.entry.mode,
> +                                                      one.entry.path);
> +                       } else {
> +                               /* same subtree or blob */
> +                               score += score_matches(one.entry.mode,
> +                                                      two.entry.mode,
> +                                                      one.entry.path);
> +                       }
> +                       update_tree_entry(&one);
> +                       update_tree_entry(&two);
> +               }
>         }
>         free(one_buf);
>         free(two_buf);
> --
> 2.18.0.796.g4bfd63b683
>
>

[-- Attachment #2: Type: text/html, Size: 10318 bytes --]

  reply	other threads:[~2018-07-31 19:52 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-31 14:09 git merge -s subtree seems to be broken George Shammas
2018-07-31 15:03 ` George Shammas
2018-07-31 15:50   ` Jeff King
2018-07-31 16:08     ` Junio C Hamano
2018-08-01  0:58     ` René Scharfe
2018-07-31 15:53   ` Junio C Hamano
2018-07-31 15:56     ` George Shammas
2018-07-31 16:15     ` Jeff King
2018-07-31 17:17       ` Junio C Hamano
2018-07-31 17:23         ` Jeff King
2018-07-31 19:04           ` Jeff King
2018-07-31 19:52             ` George Shammas [this message]
2018-07-31 20:40               ` Jeff King
2018-07-31 21:06             ` Junio C Hamano
2018-08-01  0:58               ` René Scharfe
2018-08-02 18:58                 ` Jeff King
2018-08-02 18:45               ` Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAF1Ko+FHsvmqzwVHh+fEnk=UGUftNW8VkFwaWTSKu3xYprb+wg@mail.gmail.com' \
    --to=georgyo@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=l.s.r@web.de \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).