From: Christian Couder <chriscool@tuxfamily.org>
To: Paolo Bonzini <bonzini@gnu.org>
Cc: Junio C Hamano <gitster@pobox.com>,
Johannes Schindelin <Johannes.Schindelin@gmx.de>,
git@vger.kernel.org,
Linus Torvalds <torvalds@linux-foundation.org>,
Ingo Molnar <mingo@elte.hu>,
Andrew Morton <akpm@linux-foundation.org>,
Jeff Garzik <jeff@garzik.org>, David Miller <davem@davemloft.net>
Subject: Re: [PATCH 1/9 v4] bisect: add "git bisect replace" subcommand
Date: Sat, 15 Nov 2008 15:19:27 +0100 [thread overview]
Message-ID: <200811151519.27426.chriscool@tuxfamily.org> (raw)
In-Reply-To: <491D4D02.6080004@gnu.org>
Le vendredi 14 novembre 2008, Paolo Bonzini a écrit :
> >> users could also set up a few
> >> special bisect/set-debug-to-1, bisect/remove-cflags-o2 and so on
> >> patches that you could use for purposes other than ensuring known bugs
> >> are fixed.
> >
> > In this case it is similar to Junio's proposal. But I think that for
> > changes like set-debug-to-1 and remove-cflags-o2, using the right make
> > command should be enough.
>
> Yeah, I couldn't think of a better usecase, but you got the idea.
>
> >> Finally, you could have a [bisect] configuration section with entries
> >> like "cherry-pick = BROKEN-SHA1 FIX-SHA1" and "git bisect" would apply
> >> FIX-SHA1 automatically if the bisect tip were in
> >> BROKEN-SHA1..FIX-SHA1.
> >
> > Yes, but how do you share this between members of a team?
>
> That's a common problem with stuff that goes in .gitconfig. It does not
> belong in the repository, though...
Why?
Git encourages people to develop by creating many branches of commits,
working on them and sharing them, and that seems to work very well. So I
really don't understand why _the hell_ people using bisect could not also
benefit of from creating patched up branches, sharing them, bisecting on
them.
Especially as, in my patch series, it does not in _any way_ change anything
for people who just don't want to use patched up branches. They just need
to not download any "bisect-replace-*" branch, or we can even implement a
config option "bisect.useReplaceBranches" that default to "no" if that is
such a big threat to them.
I agree that the name of the branches "bisect-replace-*" may not be the best
or that using special refs in "refs/replace/" might be better (except that
these refs should have in my opinion a special namespace to be easily
distinguished from others), but I don't think _at all_ that this should be
enough to discard the whole idea (and implementation but that's another
story).
Or is there a god command I don't know about that says:
Thou shall not use patched up branches to bisect!
Thou shall bisect painfully!
Regards,
Christian.
prev parent reply other threads:[~2008-11-15 14:21 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-11 5:39 [PATCH 1/9 v4] bisect: add "git bisect replace" subcommand Christian Couder
2008-11-11 23:23 ` Junio C Hamano
2008-11-12 14:15 ` Christian Couder
2008-11-13 9:46 ` Junio C Hamano
2008-11-13 17:50 ` Christian Couder
2008-11-13 16:41 ` Paolo Bonzini
2008-11-14 9:34 ` Christian Couder
2008-11-14 10:03 ` Paolo Bonzini
2008-11-15 14:19 ` 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=200811151519.27426.chriscool@tuxfamily.org \
--to=chriscool@tuxfamily.org \
--cc=Johannes.Schindelin@gmx.de \
--cc=akpm@linux-foundation.org \
--cc=bonzini@gnu.org \
--cc=davem@davemloft.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jeff@garzik.org \
--cc=mingo@elte.hu \
--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).