Re: [RFC] Add bad-branch-first option for git-bisect

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jan 24, 2011 at 1:53 AM, Christian Couder
<christian.couder@xxxxxxxxx> wrote:
> I am not opposed to an option to bisect on the first parents of the
> bad commit only. And after a very fast look at your patch it seems to
> be what it does. By the way Avery Pennarun's gitbuilder
> (https://github.com/apenwarr/gitbuilder) does the same thing. So I
> know some people are interested in such a feature.

Just some notes on gitbuilder's algorithm, since I haven't spent the
time to fully understand Shuang's proposal.

I do understand at least one of his concerns, that is, that people
like to do a lot of "messy" development on a branch, and when the
branch is done, merge the whole messy branch into the "mainline".  The
messy branch would then have a lot of commits that break a lot of
things before fixing them again later.

In a corporate environment, this method allows people to work all day,
make frequent commits, pull from other branches at will, and never
risk their lives by doing poorly-educated rebases.  It works pretty
well *until* you try to bisect, at which time all these messy commits
start to bite you.

gitbuilder's bisection is a total hack around this situation, although
it happens to work perfectly in the workflow it was designed for, thus
making me feel clever.

Basically, we push/fetch *all* the branches from *everybody* into a
single repo, and build all of them as frequently as we can.  If you
think about it, if you have all the branches that someone might have
pulled/merged from, then you don't have to think of the git history as
a whole complicated DAG; you can just think of it as a whole bunch of
separate chunks of linear history.  Moreover, as long as people are
careful to only pull from a branch when that branch is passing all
tests - which you can easily see by looking at the gitbuilder console
- then playing inside each of these chunks of linear history can help
you figure out where particular bugs were introduced during "messy"
branches.

It also allows you a nice separation of concerns.  The owner of the
mainline branch (the "integration manager" person) only really cares
about which branch they merged that caused a problem, because that
person doesn't want to fix bugs, he/she simply wants to know who owns
the failing branch, so that person can fix *their* bug and their
branch will merge without breaking things.

So this is why gitbuilder uses "git rev-list --first-parent" during
its "fake bisection" operation: because a different person is
responsible for each "linear chunk" of history.

Note that you have to use --no-ff when merging if you want this to
work reliably.  But the build manager person can just remember to do
that.  Combining --no-ff and --ff-only (which sound mutually exclusive
but aren't) is a way to be extra specially sure.

Now, if you aren't using gitbuilder, what we want from "bisection" is
not quite the same, but let's imagine that you at least have a similar
setup, where people *only* ever merge into the mainline by using
--no-ff.  In that case, you'd like a bisect operation that *starts* by
using --first-parent, which will tell you which merge caused the
problem.  After that, you might want to bisect into the branch.

(I don't actually remember if 'git bisect' understands --first-parent
correctly.  gitbuilder doesn't exactly bisect either, but that's
another story and not relevant right now.)

I can actually imagine that there are many more projects that do what
I'm talking about - "messy" branches that get broken and fixed over
time, then merge into a "clean" mainline - than projects (like the
kernel and git.git) that try to keep all branches clean at all times.
Thus, I could see some argument that a "--first-parents first"
bisection would actually help out a lot of people, and maybe even
deserves to be the default.

I don't really care though, I just use gitbuilder :)

Have fun,

Avery
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]