All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	git@vger.kernel.org, "Luis R. Rodriguez" <mcgrof@suse.com>,
	Jiri Slaby <jslaby@suse.cz>, Andreas Schwab <schwab@suse.de>,
	Jan Kara <jack@suse.cz>
Subject: Re: [PATCH] tag: add -i and --introduced modifier for --contains
Date: Fri, 18 Apr 2014 09:26:51 -0700	[thread overview]
Message-ID: <xmqqlhv2d2no.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <20140417221619.GA697@sigill.intra.peff.net> (Jeff King's message of "Thu, 17 Apr 2014 18:16:20 -0400")

Jeff King <peff@peff.net> writes:

>  ---A---B---C-----D---E---F (maint, v3.4)
>      \   \       /
>       \   ---G-----H---I (master, v4.0)
>        \       /  /
>         ------J---
>
> The fix is J, and it got merged up to maint at D, and to master at H.
> v4.0 does not contain v3.4. What's the best description of J?
>
> By the rules above, we hit the third rule "pick the closest". Which
> means we choose v3.4 or v4.0 based solely on how many commits are
> between the topic's merge and the tag release. Which has nothing at all
> to do with the topic itself.

Even if J..F and J..I were of the same hop-count, there is no
fundamental reason to choose one over the other.

What is "best" at that point depends on what the user wants to see.

 - Luis's case that started this thread may want to favor v3.4 if
   only because that "sounds" the smaller, even though v3.4 and v4.0
   in the illustration cannot be compared.

 - I think the "closest" we have had is primarily a heuristic to
   favour the result that is textually shorter.

 - And as I alluded to, "which one has the earliest timestamp?", is
   another valid question to ask.

In other words, there is no single "correct" answer, once you have
multiple canidates that are all valid from topological point of
view.

> In this case we'd show v4.0 (because "J-H-I" is shorter than "J-D-E-F").
> But I suspect most users would want to know v3.4, because they want to
> know the "oldest" release they can move up to that contains the commit.
> But that notion of oldness is not conveyed by the graph above; it's only
> an artifact of the tag names.

Yes, exactly.

  reply	other threads:[~2014-04-18 16:27 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-16 20:58 [PATCH] tag: add -i and --introduced modifier for --contains Luis R. Rodriguez
2014-04-16 22:02 ` Junio C Hamano
2014-04-16 22:35   ` Luis R. Rodriguez
2014-04-17 17:04     ` Junio C Hamano
2014-04-17 22:16       ` Jeff King
2014-04-18 16:26         ` Junio C Hamano [this message]
2014-04-22  4:04         ` W. Trevor King
2014-04-18 23:17       ` Luis R. Rodriguez
2014-04-18 23:36         ` Junio C Hamano
2014-04-22  0:38           ` Luis R. Rodriguez
2014-04-22 10:27       ` Jan Kara
2014-04-22 17:58         ` Junio C Hamano
2014-04-17  7:17   ` Andreas Schwab
2014-04-17 17:05     ` Junio C Hamano
2014-04-17 17:30       ` Andreas Schwab
2014-04-17 18:49         ` Junio C Hamano

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

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

  git send-email \
    --in-reply-to=xmqqlhv2d2no.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=jack@suse.cz \
    --cc=jslaby@suse.cz \
    --cc=mcgrof@do-not-panic.com \
    --cc=mcgrof@suse.com \
    --cc=peff@peff.net \
    --cc=schwab@suse.de \
    /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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.