Ah, glad I could help then. I also learned git-bisect and a bit of
shell-script in the process :)
--
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/git-users/-/tnr4
On 5 Jan, 23:36, Thomas Ferris Nicolaisen wrote:
> Thanks for the example. I'm indeed able to recreate the problem. I guess
> that that's just the way it works, and my toy repo landed on the failing
> commit by accident. Sorry for misleading.
Good that you were able to re-produce it so that I kno
By the way, you need to inspect that file *before* you do git bisect reset.
You can also do git rev-parse bisect/bad, which prints the same thing.
--
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To view this discussion on the web visit
Thanks for the example. I'm indeed able to recreate the problem. I guess
that that's just the way it works, and my toy repo landed on the failing
commit by accident. Sorry for misleading.
How about you just use the contents of that file mentioned in the docs?
cat .git/refs/bisect/bad
--
You r
On 5 Jan, 16:30, Thomas Ferris Nicolaisen wrote:
> The intention of bisect is to get the first bad commit. From the docs:
>
> "Eventually there will be no more revisions left to bisect, and you will
> have been left with the first bad kernel revision in "refs/bisect/bad"."
>
> So git bisect run en
The intention of bisect is to get the first bad commit. From the docs:
"Eventually there will be no more revisions left to bisect, and you will
have been left with the first bad kernel revision in "refs/bisect/bad"."
So git bisect run ending up with a commit which is "good" doesn't make
sense.
On 5 Jan, 14:40, Thomas Ferris Nicolaisen wrote:
> I still believe that there's something fishy going on in your test.. Care
> to share some concrete examples?
Immediately after git bisect run HEAD is at d9:
git rev-parse HEAD
d9ab70394d306d5ab450513b2f69c8b81f6f255c
The bad commit is:
sed -n s
By the way, compare your git version:
➜ ~/projects/agnes/[(broke-the-build)|BISECTING]>git --version
tfnico@Thomas-Ferris-Nicolaisens-iMac
[14:34:13]
git version 1.7.3.4
--
You received this message because you are subscribed to the Google Groups "Git
I still think git show will show the commit that breaks the build.
Here's the output of me running bisect on a toy project, the target commit
is 74a227:
First, a oneline log of my recent commits:
c5f7e3a8a943b5a3d2a1b43981730405f9b9f9a0 A random commit message: flanky
c6a92b9c359f0ae4332d63d2b
On 5 Jan, 13:03, Thomas Ferris Nicolaisen wrote:
> Can you double check that the commit before is not failing as well, or
> maybe there are some other variables outside the test that are causing it
> to fail?
No the commit before is good. Even doing a "git bisect log" will list
it as good.
I'll
After running git bisect run, (I just actually tried bisecting for the
first time, after two years of gitting :)), I ended up with HEAD pointing
at the actual commit that broke the build.
Can you double check that the commit before is not failing as well, or
maybe there are some other variable
11 matches
Mail list logo
