linux-kernel - Re: My kernel hangs again: Help with git please

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 16 Jun 2007 16:03:40 +0200
From:	Carlo Wood <carlo@...noe.com>
To:	Daniel Barkalow <barkalow@...ervon.org>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: My kernel hangs again: Help with git please

On Sat, Jun 16, 2007 at 01:28:13AM -0400, Daniel Barkalow wrote:
> That's not actually the right image. There's a graph of commits with a lot 
> of splitting and joining lines. Each branch and each tag sits something in 
> this web. The difference between branches and tags is that you're expected 
> to move branch pointers around, and tags stay mostly in place. There's no 
> accounting of commits newer than the current spot in the web for a branch 
> belonging to that branch, so if you move a branch back to an older tag (or 
> other commit), the spot it's leaving is no longer "on the branch".

Okay, it took me two hours before I understood this... but here's the
picture that I have in mind now:

	   master->X        (merge point)
		  /|
		 / |
      ^ branch->3  X
 Time |         |  |
      |         2  X
		|  |
	        1  X
		|  |
		 \ |
		  \|
		   X        (branch point)
		   |

Then if I define a branch pointer to point to '3', then the branch is
3--2--1. If next I move the branch pointer to point to '2', node '3' is
no longer on the branch because now the branch exists of 2--1, and
HEAD moves to '2' as well.

This seems to make most sense in the light of your last sentence.
I don't understand how I'd have moved branch pointers however. I thought
I would just change my working copy along the branch by specifying
tag nodes. Ie, I have a branch '3'(--2--1) and I say: give me '2',
then give me '1' - and when I do: git reset --hard HEAD - it moves
me to 3 because the branch was never touched.

> So master is a point in the web, and bisect jumps around through the web 
> according to some special rules (due to having git-bisect use the good/bad 
> marks do determine which commit to try next, and jump there). git-bisect 
> doesn't really even care that you started on any single branch. It's just 
> operating on the web, and the branch you start on is treated as an 
> arbitrary commit that has the problem.

Ok - so it does something magical that I don't have to understand :P
The only thing that matters is that I choose the begin and end point,
the first two points, correctly: where one is bad and the other is good.
I seems that git bisect can't deal with swapping good/bad (the 'bad'
one always has to be the newest revision), so I had decided to call
'kernel hangs' good and 'kernel works' bad. The problem then is that
I can't find any starting point anymore that is 'bad'.

> You may find "gitk --all" informative.

The dates on the right side seem to make no sense. Even in a part
where there are no branches/merges at all, the date goes in both
direction (sometimes older, sometimes newer). Roughly it seems that
the newest date is at the top - but I see a lot of times things like:

|||O||  Description   Author1  2007-05-14 03:43:20
|||O||  Description   Author2  2007-05-15 15:10:34
|||O||  Description   Author3  2007-05-13 17:50:27

Thus, there seems to be no time related ordering :/

> It looks like you moved master back to 2.6.22-rc4 (with git reset --hard 
> v2.6.22-rc4) at some point.

Yup, I can see that in the gitk --all graph :)

> What you should do now is:
> 
> $ git checkout master
> $ git merge origin
> 
> Which should move master forward through the web to "origin", which is 
> (unless you've moved it) what you got from upsteam.

$ git merge origin
fatal: Needed a single revision
Usage: /usr/bin/git-merge [-n] [--no-commit] [--squash] [-s <strategy>]... <merge-message> <head> <remote>+

For some reason I don't think I should be needing commands that need
"<merge-message>"; I don't want to change the (local) tree in anyway.

Isn't there another way to just move master back to the HEAD of origin?

> Alternatively:
> 
> $ git checkout master
> $ git pull
> 
> Should fetch the latest stuff and advance master to the fetched version.

I'd rather first reproduce a working kernel - that should be possible
without pulling in more commits.

-- 
Carlo Wood <carlo@...noe.com>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/