git problem

git problem

[Ken Moffat]

 I seem to be doing something wrong.  I'm trying to bisect to
discover which commit causes my failure to shut down or restart from
gdm on one box (the gdm window disappears, but the background
remains instead of falling back to a console and shutting down).

 So far, I've discovered that the problem is slightly intermittent,
so I'm not labelling a kernel good until it successfully restarts or
shuts down 10 times (indications are that a bad version will fail in
the first 3 attempts).

 Anyway, I've confirmed my supposition that 2.6.24 was good in this
respect, and that 2.6.25-rc1 was bad.  After about a day of
bisection / archive / build /test I went to set an extraversion in
the Makefile (everything had been labelled 2.6.24 because this was
before rc1), and discovered it was already labelled as 2.6.24-rc4,
i.e. far too early.

 Reset, repeated, git came up with the same commits (I wondered if
I'd mispasted at some point).  Looked at the log, this seemed to be
the newest thing available.  Reset, looked at the full log, but I'm
out of my depth trying to understand this.

FWIW, these were the commits it told me to test:
[1c17f4d615f34a4ecfcf9132d643126b226f5e79] x86: ioremap_nocache fix
good

[d2fc0bacd5c438cb459fdf531eff00ab18422a00] Merge git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86
bad

[7c0141591fcf92ddc96a4ee04e35783a15bd68c8] [ALSA] virtuoso: monitor external power on D2X
good

[b6cf160c4b788a31f6a4017a469b956ca77febf4] Merge git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6
bad

[5de8b3acda2d03f8aeb21b5a267645088718c356] USB: CP2101 New Device IDs
bad - dated 3rd Jan, but I think it was merged in the right timeframe

[f776c4cda449bab463f5388eb07bd63dc52e2b13] [NETFILTER]: ebtables: Update modules' descriptions
bad

[e78c9d285709f535caae405f1da5b2936f51f0b5] b43legacy: fix MAC control and microcode init
bad

[e1a9c9872dd004617555dff079b357a6ffd945e9] Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/perex/alsa
good

[294d5cc233d81ec4aec77ebc60dc5752a3d0082a] Add schedule_timeout_killable
 - This appears to date from 6th December, and to have been merged
around then.

Confused.  Help ?  Please ?

Ken
-- 
das eine Mal als Tragödie, das andere Mal als Farce

git problem

[Larry Finger]

I had my system freeze when doing a pull from Linus's repo. Since then, every 
pull results in the following errors:

~> git pull
error: unable to resolve reference refs/tags/v3.1-rc8: Success
 From git://github.com/torvalds/linux
  ! [new tag]         v3.1-rc8   -> v3.1-rc8  (unable to update local ref)

Any suggestions on how to fix this error?

Thanks,

Larry

git problem

[Thomas Koeller]

Hi,

on my machine I have clones of both the linux-mips and
Linus' kernel tree. I recently found that git-describe
behaves differently in those trees:

bash-3.2$ cd linux-2.6.git/
bash-3.2$ git-status
# On branch master
nothing to commit (working directory clean)
bash-3.2$ git-describe bd71c182d5a02337305fc381831c11029dd17d64
v2.6.21-2747-gbd71c18
bash-3.2$ cd ../excite.git/
bash-3.2$ git-status
# On branch master
nothing to commit (working directory clean)
bash-3.2$ git-describe bd71c182d5a02337305fc381831c11029dd17d64
fatal: cannot describe 'bd71c182d5a02337305fc381831c11029dd17d64'

The commit is of course present in both trees. AFAIK the
'cannot describe' error shows if there are no tags at all,
but this is not the case; .git/refs/tags is fully populated.
Has anybody got a clue as to what may be wrong here?
-- 
Thomas Koeller
thomas at koeller dot dyndns dot org

Re: git problem

[Ralf Baechle]

On Wed, Nov 28, 2007 at 07:50:46PM +0100, Thomas Koeller wrote:

> on my machine I have clones of both the linux-mips and
> Linus' kernel tree. I recently found that git-describe
> behaves differently in those trees:
> 
> bash-3.2$ cd linux-2.6.git/
> bash-3.2$ git-status
> # On branch master
> nothing to commit (working directory clean)
> bash-3.2$ git-describe bd71c182d5a02337305fc381831c11029dd17d64
> v2.6.21-2747-gbd71c18
> bash-3.2$ cd ../excite.git/
> bash-3.2$ git-status
> # On branch master
> nothing to commit (working directory clean)
> bash-3.2$ git-describe bd71c182d5a02337305fc381831c11029dd17d64
> fatal: cannot describe 'bd71c182d5a02337305fc381831c11029dd17d64'
> 
> The commit is of course present in both trees. AFAIK the
> 'cannot describe' error shows if there are no tags at all,
> but this is not the case; .git/refs/tags is fully populated.
> Has anybody got a clue as to what may be wrong here?

I know the issue, for example:

[ralf@denk linux-mips]$ git log linux-1.3.0 | head -5
commit 908d4681a1dc3792ecafbe64265783a86c4cccb6
Author: Ralf Baechle <ralf@linux-mips.org>
Date:   Sun Oct 6 07:00:00 1996 +0000

    Import of Linux/MIPS 2.1.1
[ralf@denk linux-mips]$ git describe 908d4681a1dc3792ecafbe64265783a86c4cccb6
fatal: cannot describe '908d4681a1dc3792ecafbe64265783a86c4cccb6'
[ralf@denk linux-mips]$ 

I notice it primarily with fairly old tags though not necessarily as
antique as this one.

Cheers,

  Ralf

Re: git problem

[Franck Bui-Huu]

Thomas Koeller wrote:
> on my machine I have clones of both the linux-mips and
> Linus' kernel tree. I recently found that git-describe
> behaves differently in those trees:
 
[snip]

> The commit is of course present in both trees. AFAIK the
> 'cannot describe' error shows if there are no tags at all,
> but this is not the case; .git/refs/tags is fully populated.

Not really, it can happen if the commit you're trying to describe and
all of its parents are not tagged.

> Has anybody got a clue as to what may be wrong here?

Is the commit originally part of Linus' tree and was pulled later by
Ralf ?

If so, it probably means that the commits committed by Ralf in his
tree, which are the tagged ones, have no relationship with the ones
pulled from Linus.

		Franck

Re: git problem

[Ralf Baechle]

On Thu, Nov 29, 2007 at 12:32:38PM +0100, Franck Bui-Huu wrote:

> Thomas Koeller wrote:
> > on my machine I have clones of both the linux-mips and
> > Linus' kernel tree. I recently found that git-describe
> > behaves differently in those trees:
>  
> [snip]
> 
> > The commit is of course present in both trees. AFAIK the
> > 'cannot describe' error shows if there are no tags at all,
> > but this is not the case; .git/refs/tags is fully populated.
> 
> Not really, it can happen if the commit you're trying to describe and
> all of its parents are not tagged.
> 
> > Has anybody got a clue as to what may be wrong here?
> 
> Is the commit originally part of Linus' tree and was pulled later by
> Ralf ?
> 
> If so, it probably means that the commits committed by Ralf in his
> tree, which are the tagged ones, have no relationship with the ones
> pulled from Linus.

I intentionally do not carry the tags from Linus tree in the lmo git
tree.  Lots of additional tags with little actual use.  Whoever would
like then can pull from Linus' tree into a lmo clone to get Linus'
tags.

Back to the original topic - git describe fails even with some of the
very old commits of the lmo tree which are known to be tagged so there
is something wrong.

  Ralf

Re: git problem

[Franck Bui-Huu]

Ralf Baechle wrote:
> Back to the original topic - git describe fails even with some of the
> very old commits of the lmo tree which are known to be tagged so there
> is something wrong.

Your issue seems different from Thomas' one. In your case:

	$ git cat-file -t refs/tags/linux-1.3.0
	commit

So the tag you mentioned is a _lightweight_ tag. These are not
considered by git-describe by default.

To make git-describe work, just do:

	$ git describe --tags $(cat .git/refs/tags/linux-1.3.0)
	linux-1.3.0

		Franck

Re: git problem

[Ralf Baechle]

On Thu, Nov 29, 2007 at 03:38:41PM +0100, Franck Bui-Huu wrote:

> Ralf Baechle wrote:
> > Back to the original topic - git describe fails even with some of the
> > very old commits of the lmo tree which are known to be tagged so there
> > is something wrong.
> 
> Your issue seems different from Thomas' one. In your case:
> 
> 	$ git cat-file -t refs/tags/linux-1.3.0
> 	commit
> 
> So the tag you mentioned is a _lightweight_ tag. These are not
> considered by git-describe by default.

Ah, thanks solving that miracle.

The lightweight tags were all created by the git to CVS converter two years
ago.  I was planning to replace those with signed tags anyway, another
reason to do so.

  Ralf

Re: git problem

[Thomas Koeller]

On Donnerstag, 29. November 2007, Franck Bui-Huu wrote:
> Thomas Koeller wrote:
> > The commit is of course present in both trees. AFAIK the
> > 'cannot describe' error shows if there are no tags at all,
> > but this is not the case; .git/refs/tags is fully populated.
>
> Not really, it can happen if the commit you're trying to describe and
> all of its parents are not tagged.
Yes, that is what I meant to say.

> Is the commit originally part of Linus' tree and was pulled later by
> Ralf ?
Indeed.

>
> If so, it probably means that the commits committed by Ralf in his
> tree, which are the tagged ones, have no relationship with the ones
> pulled from Linus.
So far it has been my understanding that if I pull from a remote
repository, all the commits are merged into the target branch,
resulting in a combined history containing all my commits as well as
those pulled. This means that as long as any (locally created or
pulled) commit preceeding the one that git-describe is applied to
is tagged, I would expect git-describe to find that tag. This seems
to be a misconception, then?

Thomas



-- 
Thomas Koeller
thomas@koeller.dyndns.org