Re: My kernel hangs again: Help with git please
Carlo Wood, Sat, Jun 16, 2007 16:03:40 +0200: > $ git merge origin > fatal: Needed a single revision > Usage: /usr/bin/git-merge [-n] [--no-commit] [--squash] [-s ]... > + > > For some reason I don't think I should be needing commands that need > ""; I don't want to change the (local) tree in anyway. I'd recommend to upgrade your git. There are some really nice improvements in the latest versions (1.5.2.2, for instance). Particularly, the command above would have worked. That is, assuming you actually do have that origin branch. In any case, a $ git fetch git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git master $ git reset --hard FETCH_HEAD will get you the very latest kernel in your working directory. Has some disadvantages, though: does not retrieve the tags and destroys local changes. But you'll find a man page of git-remote and git-config very interesting, especially wrt the above operation. I do just "git pull", for example and actually _am_ sure I get the latest kernel, get all the tags and never loose local changes. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: My kernel hangs again: Help with git please
On Sat, 16 Jun 2007, Carlo Wood wrote: > 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) >| Right, except that, in your repository, "master" has ended up pointing to "3" also. Or, in any case, all of your local branches ("master" is no different from other branches, except that it's the initial default name for a branch) are somewhere down the web from the latest stuff from Linus's repositry. > 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. Right, except that "HEAD" is really just a symlink, not a pointer directly to the history; the branch it points to is what you've got in your working directory currently. So in that case, HEAD moves to '2' simply because it's indirection for branch, which has moved to 2. Side note: in more recent versions of git, there's the feature that you seem to be trying to use. It's called "detatched HEAD", and means that you can have HEAD be some arbitrary commit, not a link to a branch. You'd do this with "git checkout ", and then your working directory would match that revision, and "git branch" would have no *, and you wouldn't have a current branch at all, and you wouldn't be moving branch pointers around. But I don't think you're using a version of git that supports this, and you need to get your branch pointers back to the present anyway. > 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. git reset --hard moves the current branch to that revision, as well as moving the working directory (and the index, which doesn't matter for your case). If you were thinking that it only changed the working directory, you probably moved some branches without realizing it. > > 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'. Right; since the normal goal is to find regressions, not fixes, "bad" is the "after it changed" case, and "good" is the "before it changed". It is trying to find a commit which all of the "bad" commits are descended from, and which is descended from only "good" commits. > > 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 :/ Those dates are when the patches which became the commits
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 ]... + For some reason I don't think I should be needing commands that need ""; 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 <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: My kernel hangs again: Help with git please
On Sat, 16 Jun 2007, Carlo Wood wrote: > I don't understand - any branch that I am on has many tags. I can use > 'git reset --hard sometag' to change the source tree to that tag (which > works if I look at the version in the Makefile and pick tags that are > far apart enough). 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". 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. You may find "gitk --all" informative. > Anyway, I tried this: > > $ git checkout master > $ git branch > bisect > * master > origin > $ BRANCH=$(git branch | grep "^\*" | sed -e "s/\* //") > $ echo $BRANCH > master > $ git rev-list --max-count=1 $BRANCH > 5ecd3100e695228ac5e0ce0e325e252c0f11806f > > Is it correct that this last command gives me the 'git id' (if that > is the correct name for the hash) of the revision that my local > working copy is at? Yes. > Can you tell me what is the latest git id that you see? I'm seeing de7f928ca460005086a8296be07c217aac4b625d, but I just got the latest code, more recently than you probably did. > Because, if I compile 5ecd3100e695228ac5e0ce0e325e252c0f11806f is > still hangs at boot :( It looks like you moved master back to 2.6.22-rc4 (with git reset --hard v2.6.22-rc4) at some point. 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. Alternatively: $ git checkout master $ git pull Should fetch the latest stuff and advance master to the fetched version. -Daniel *This .sig left intentionally blank* - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: My kernel hangs again: Help with git please
On Fri, Jun 15, 2007 at 08:33:38PM -0400, Daniel Barkalow wrote: > HEAD doesn't mean what you think it means. It's the latest revision on the > branch with the *. What you want is: > > $ git checkout master > > This will move the * to "master", which shouldn't have been affected by > any of this, and move your working directory to this point as well. At > that point, you should be able to build a working kernel. > > What "git reset --hard HEAD" does is discard any differences to tracked > files between your working directory and the revision you're on. It's > relevant if you want to discard local changes, not otherwise. I don't understand - any branch that I am on has many tags. I can use 'git reset --hard sometag' to change the source tree to that tag (which works if I look at the version in the Makefile and pick tags that are far apart enough). Then, shouldn't 'HEAD' have the meaning: the newest tag on the branch? I was on the 'bisect' branch - but that is a copy of the master, no? At least, that was what I started on when I started the bisect. Anyway, I tried this: $ git checkout master $ git branch bisect * master origin $ BRANCH=$(git branch | grep "^\*" | sed -e "s/\* //") $ echo $BRANCH master $ git rev-list --max-count=1 $BRANCH 5ecd3100e695228ac5e0ce0e325e252c0f11806f Is it correct that this last command gives me the 'git id' (if that is the correct name for the hash) of the revision that my local working copy is at? Can you tell me what is the latest git id that you see? Because, if I compile 5ecd3100e695228ac5e0ce0e325e252c0f11806f is still hangs at boot :( I really don't know how I got a working kernel before :/ -- Carlo Wood <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: My kernel hangs again: Help with git please
On Sat, 16 Jun 2007, Carlo Wood wrote: > Therefore I have the following questions: > > 1) What git command will ASSURE that I get the LATEST >kernel tree checked out? > > I tried this: > > hikaru:/usr/src/kernel/git/linux-2.6>git branch -l > * bisect > master > origin > hikaru:/usr/src/kernel/git/linux-2.6>git reset --hard HEAD HEAD doesn't mean what you think it means. It's the latest revision on the branch with the *. What you want is: $ git checkout master This will move the * to "master", which shouldn't have been affected by any of this, and move your working directory to this point as well. At that point, you should be able to build a working kernel. What "git reset --hard HEAD" does is discard any differences to tracked files between your working directory and the revision you're on. It's relevant if you want to discard local changes, not otherwise. -Daniel *This .sig left intentionally blank* - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
My kernel hangs again: Help with git please
Somewhere between 2.6.18 and 2.6.19, a patch was added to the kernel that makes it hang on my machine after the message: apgart: Detected an Intel 965G Chipset. When I upgraded to 2.6.22-rc4 (from debian trunk), I still ran into this same bug. After installing git for the first time, I made my first little steps with git - but it didn't get any further then an attempt to mount my root because I had done my configuration wrong (due the fact that libata seems to have moved). Later, I managed to get the configuration right, compiled HEAD (I think) and got a working 2.6.22-rc4 (+ patches). I was very happy, and assumed that by coincidence the very bug that was introduced shortly after 2.6.18 that made my machine hang during boot, was fixed only two or so days after I joined linux-kernel and installed git, somewhere after 2.6.22-rc4 ... What a coincidence right? Indeed, I thought it was a bit TOO much of a coincidence. So I just HAD to see that patch that fixed the problem, and I tried to used git bisect to find the patch that changes the behaviour from a hang to a working kernel (that I am now using to write this very mail). Surprise: Nothing I try produces a working kernel anymore?! Therefore I have the following questions: 1) What git command will ASSURE that I get the LATEST kernel tree checked out? I tried this: hikaru:/usr/src/kernel/git/linux-2.6>git branch -l * bisect master origin hikaru:/usr/src/kernel/git/linux-2.6>git reset --hard HEAD hikaru:/usr/src/kernel/git/linux-2.6>git rev-list --max-count=1 bisect c420bc9f09a0926b708c3edb27eacba434a4f4ba And, assuming I have c420bc9f09a0926b708c3edb27eacba434a4f4ba at that moment, then git reset --hard HEAD didn't do what I wanted: that is namely -rc3 even! I can see THAT in the Makefile -- but whenever I see -rc4 in the Makefile, that doesn't garantee in any way (apparently) that I have the latest of the latest. 2) Is there some way to find back the exact version (git id) from the .config, System.map and vmlinuz image (or /proc, since I can boot it)? Because that is all I have left from the time that I managed to create a working kernel :( -- Carlo Wood <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/