From: Junio C Hamano <hidden> Date: 2016-06-16 02:19:02
Hagen Paul Pfeifer [off-list ref] writes:
Imagine a "rebase feature branch" style of development. All features are
developed on separate features branch which are rebased on master and
immediately merged into the upstream master.
I do not want to imagine such ;-) The only semi-sensible reason why
people might want to always rebase on top of 'master' is to keep the
history completely linear, so with such a workflow, there won't be a
merge commit.
But I think "rebase" part of your description is a red herring. If
a development goes by always doing a new feature in a side branch
and then merge the branch only after it is done to the 'master'
branch, then bisecting only the commits on first-parent chain would
often be a quick first-pass to find the topic whose merge into the
'master' branch introduced a breakage. From there you can dig down
to each individual commit on the side branch. And for that, it is
immaterial that the side branch gets rebased on 'master' and forced
to become a merge with "--no-ff", of the side branch was developed
on older upstream but in a careless way full of "oops, previous one
I broke the entire world and it does not even compile; this commit
fixes it" commits.
So being able to stop at only commits on the first-parent chain is a
valid and useful tool. "git bisect --first-parent" is one of the
things that are sometimes asked for.
From: Johannes Sixt <hidden> Date: 2016-06-16 02:19:03
Am 27.04.2016 um 22:56 schrieb Junio C Hamano:
So being able to stop at only commits on the first-parent chain is a
valid and useful tool. "git bisect --first-parent" is one of the
things that are sometimes asked for.
With origin pointing to git.git, I attempted this:
git bisect start
git rev-list --first-parent --boundary origin..origin/pu |
sed -ne s/-//p | xargs git bisect good
git bisect bad origin/pu
and it starts bisecting among the 50-something first-parent commits
between origin and origin/pu.
-- Hannes
git bisect start
git rev-list --first-parent --boundary origin..origin/pu |
sed -ne s/-//p | xargs git bisect good
git bisect bad origin/pu
and it starts bisecting among the 50-something first-parent commits between
origin and origin/pu.
just for clarification: contributors rebase their work before pushing it on
master. The integrator simple merges --no-ff the individual branches. Just a
regular workflow, nothing special - except that many contributor commits will
not build. ;(
The idea is just to skip the contributor commits during bisect and focus on
the merge commits (the ones with more than one ancestors) because they are
likely build and testable.
One possible approach is probably to sort out all non-merge commits before
bisecting and bisect only on a this set of commits. The advantage is that the
first bad commit is the merge commit introduced the regression. Mmmh, any
comments?
hgn
git bisect start
git rev-list --first-parent --boundary origin..origin/pu |
sed -ne s/-//p | xargs git bisect good
git bisect bad origin/pu
and it starts bisecting among the 50-something first-parent commits between
origin and origin/pu.
just for clarification: contributors rebase their work before pushing it on
master. The integrator simple merges --no-ff the individual branches. Just a
regular workflow, nothing special - except that many contributor commits will
not build. ;(
The idea is just to skip the contributor commits during bisect and focus on
the merge commits (the ones with more than one ancestors) because they are
likely build and testable.
One possible approach is probably to sort out all non-merge commits before
bisecting and bisect only on a this set of commits. The advantage is that the
first bad commit is the merge commit introduced the regression. Mmmh, any
comments?
I suspect doing something akin to the idea of "bisect --first-parent"
would work for this use case and be more flexible in general. Your
idea is pretty much what i think bisect --first-parent would do,
except that it would also work for non-merge commits which happen to
be in the "mainline" history.
Thanks,
Jake