From: Christian Couder <chriscool@tuxfamily.org>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
John Tapsell <johnflux@gmail.com>,
Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: Re: [PATCH 7/7] bisect: use "rev-list --bisect-skip" and remove "filter_skipped" function
Date: Fri, 13 Mar 2009 06:29:25 +0100 [thread overview]
Message-ID: <200903130629.25452.chriscool@tuxfamily.org> (raw)
In-Reply-To: <7viqmfkuyt.fsf@gitster.siamese.dyndns.org>
Le jeudi 12 mars 2009, Junio C Hamano a écrit :
> These (except for the first one which I do not think belongs to the
> series) look more or less straightforward changes.
I added the first one to the series because I use strbuf_split with the new
behavior in the series.
> One worrysome thing that the series introduces is that you used to hold
> all the skipped ones in a shell variable $skip and fed it internally to
> the filter_skipped shell function, but now you give them from the command
> line. When you have tons of skipped commits, this can easily bust the
> command line length limit on some system, while the shell may still be Ok
> with such a large string variable.
Yeah. I will send a patch (8/7) that makes "git rev-list" read the skipped
commits from stdin when "--bisect-skip" is passed, and that changes
git-bisect.sh accordingly. If this behavior is ok, then I can reorder the
series if you want.
> Because the operations in rev-list related to bisect are very closely
> tied to the implementation of the bisect Porcelain anyway, I am wondering
> if it makes more sense to just feed the name of the toplevel refname
> hierarchy, i.e. "refs/bisect", as a rev-list parameter and let rev-list
> enumerate what is skipped, which commits are good and which ones are bad.
Yeah that could be an improvement, but then the enumeration will happen once
in git-bisect.sh and once in "git rev-list", instead of just once in
git-bisect.sh. And we also have to deal with the other command line
arguments passed to "git rev-list" on top of the enumerated commits from
the refname hierachy, so I don't think that would be very consistent.
But perhaps we could create a new "git rev-bisect" builtin plumbing command
that could do that. And later we could improve this new command so that it
checks merge bases (like what is done in bisect_next in git-bisect.sh) and
so that it also checks out the source code of the new revision to be tested
(like what is done in bisect_checkout in git-bisect.sh).
Thanks,
Christian.
prev parent reply other threads:[~2009-03-13 5:31 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-12 7:51 [PATCH 7/7] bisect: use "rev-list --bisect-skip" and remove "filter_skipped" function Christian Couder
2009-03-12 8:26 ` Junio C Hamano
2009-03-13 5:29 ` Christian Couder [this message]
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=200903130629.25452.chriscool@tuxfamily.org \
--to=chriscool@tuxfamily.org \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=johnflux@gmail.com \
--cc=mingo@elte.hu \
/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).