[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <489335CA.9000204@tuffmail.co.uk>
Date: Fri, 01 Aug 2008 17:11:54 +0100
From: Alan Jenkins <alan-jenkins@...fmail.co.uk>
To: Jiri Slaby <jirislaby@...il.com>
CC: Bob Copeland <me@...copeland.com>, tomasw@...il.com,
Dave Young <hidave.darkstar@...il.com>, stable@...nel.org,
linux-wireless@...r.kernel.org, linux-kernel@...r.kernel.org,
linville@...driver.com, Pekka Enberg <penberg@...helsinki.fi>,
ath5k-devel@...ema.h4ckr.net, johannes@...solutions.net,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: git-describe [Was: ath5k_config_interface deadlock fix]
Jiri Slaby wrote:
> Alan Jenkins napsal(a):
>> There must be a better way (for efficient merges, right?). But all I
>> can think of is comparing the files in question against the diff. I
>> checked myself and the changes don't appear to have been included in
>> v2.6.26.
>
> Ah, I see. Is this a git-describe bug or my misunderstanding of the tool?
It's not an implementation bug. It's just very easy to misunderstand.
git-describe only looks _back_ in time to what the current commit is
based on. In this case the commit was based on v2.6.26-rc8 - but it
_wasn't_ merged into 2.6.26. It was presumably merged in for
v2.6.27-rc1. This is a perfectly legal history in GIT.
It's probably most often encountered during git-bisect. If you bisect
e.g. between v2.6.26 and v.2.6.27-rc1, you're likely to see commits
which were based on v2.6.26-rc8.
If that doesn't help, try finding an introduction to GIT with some good
pictures. I think it's easier to understand it visually.
Alan
--
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/
Powered by blists - more mailing lists