From: Carlo Wood <carlo@alinoe.com>
To: Daniel Barkalow <barkalow@iabervon.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: My kernel hangs again: Help with git please
Date: Sat, 16 Jun 2007 16:03:40 +0200 [thread overview]
Message-ID: <20070616140340.GA30861@alinoe.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0706160059210.4740@iabervon.org>
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@alinoe.com>
next prev parent reply other threads:[~2007-06-16 14:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-16 0:12 My kernel hangs again: Help with git please Carlo Wood
2007-06-16 0:33 ` Daniel Barkalow
2007-06-16 4:07 ` Carlo Wood
2007-06-16 5:28 ` Daniel Barkalow
2007-06-16 14:03 ` Carlo Wood [this message]
2007-06-16 19:13 ` Daniel Barkalow
2007-06-17 10:52 ` Alex Riesen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070616140340.GA30861@alinoe.com \
--to=carlo@alinoe.com \
--cc=barkalow@iabervon.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.