From: Kevin Bracey <kevin@bracey.fi>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH v2 8/8] revision.c: discount UNINTERESTING parents
Date: Sat, 04 May 2013 23:18:39 +0300 [thread overview]
Message-ID: <51856D1F.4030303@bracey.fi> (raw)
In-Reply-To: <7v61z11721.fsf@alter.siamese.dyndns.org>
On 02/05/2013 23:05, Junio C Hamano wrote:
>
>>> ....Z...A===X---o---o---B
>>> \\ /
>>> W---Y
>>>
> OK, I think I understand it, and we are in agreement. For the
> purpose of the above paragraph, a side branch is what is not on the
> "--ancestry-path", so all of the below "examples" are about the
> behaviour when --ancestry-path is used.
Ah, in fact, no. In some previous mails I was concentrating on
ancestry-path, but those 3 examples were really of ordinary "A..B", with
W+Y in the INTERESTING set. I think the side-branch logic remains sound
and desirable even in the absence of --ancestry-path, so I don't think
this is an ancestry-path change. (And from a basic naive usability point
of view I'm much more interested in improving the more obvious modes
than the rather more obscure --ancestry-path.)
Ancestry path forces side branches to be ignored - it's the "simple"
case for ignoring (and understanding) side branches. But if we let other
modes know where the bottom is, they too can benefit from reliable side
branch logic - we can find out if anything happened on side branches,
but we can also ignore them completely if they turn out to be totally
irrelevant.
When not using ancestry-path, the side branches this patch works on are
thosewhich go off and don't come back - they stub off at some
UNINTERESTING commit other than the bottom(s). If no other limiting is
set, they must have hit an ancestor of our BOTTOM commit(s);
simplify-merges could have potentially pruned away if unlimited. And
this patch restores that pruning ability - simplify-merges can rewrite
them back to just 1 UNINTERESTING merge parent at the boundary (looking
like an ancestry-path boundary), then this patch can chuck the boundary
merge. Hey presto, irrelevant branch now invisible. And the patch also
provides benefits to all other modes.
I'll post v3 of the sequence tomorrow - it includes a new test which
illustrates the changes - it's a 60-or-so-item test set, with about 15
"failures" in a variety of modes that get fixed by this sequence. I
think that should make an excellent discussion topic. We'll see whether
folks agree with my view about what should and shouldn't be shown...
Kevin
next prev parent reply other threads:[~2013-05-04 20:44 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-30 17:26 [PATCH v2 0/8] History traversal refinements Kevin Bracey
2013-04-30 17:26 ` [PATCH v2 1/8] decorate.c: compact table when growing Kevin Bracey
2013-04-30 17:26 ` [PATCH v2 2/8] t6019: test file dropped in -s ours merge Kevin Bracey
2013-04-30 17:26 ` [PATCH v2 3/8] rev-list-options.txt: correct TREESAME for P Kevin Bracey
2013-04-30 17:26 ` [PATCH v2 4/8] revision.c: Make --full-history consider more merges Kevin Bracey
2013-04-30 17:26 ` [PATCH v2 5/8] t6012: update test for tweaked full-history traversal Kevin Bracey
2013-04-30 17:26 ` [PATCH v2 6/8] simplify-merges: never remove all TREESAME parents Kevin Bracey
2013-04-30 17:26 ` [PATCH v2 7/8] simplify-merges: drop merge from irrelevant side branch Kevin Bracey
2013-04-30 20:54 ` Junio C Hamano
2013-04-30 17:26 ` [PATCH v2 8/8] revision.c: discount UNINTERESTING parents Kevin Bracey
2013-04-30 21:18 ` Junio C Hamano
2013-05-02 17:52 ` Kevin Bracey
2013-05-02 17:58 ` [PATCH v2.1 8/8] revision.c: discount side branches when computing TREESAME Kevin Bracey
2013-05-02 18:26 ` [PATCH v2.2 " Kevin Bracey
2013-05-02 20:05 ` [PATCH v2 8/8] revision.c: discount UNINTERESTING parents Junio C Hamano
2013-05-04 20:18 ` Kevin Bracey [this message]
2013-04-30 21:28 ` [PATCH v2 0/8] History traversal refinements 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=51856D1F.4030303@bracey.fi \
--to=kevin@bracey.fi \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=torvalds@linux-foundation.org \
/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 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 NNTP newsgroup(s).