Problems using StGit and -rt kernel patchset

Problems using StGit and -rt kernel patchset

[Clark Williams]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello all,

I've been working on the -rt patch series for the kernel and would like to to use
StGit to manage the patches. Unfortunately I've had limited success, so I thought I'd
ask the git/stgit community if what I'm doing is wrong.

I clone Linus's tree to a common directory, then clone it locally to work:

$ git clone -s -l /home/src/linux-2.6.git scratch.git
$ cd scratch.git
$ stg init
$ stg branch --create rt-2.6.23-rc8-rt1 v2.6.23-rc8
$ stg import --series --ignore --replace ../sources/patch-queue-2.6.23-rc8-rt1/series
<fix the things quilt lets through and stg barfs on, like malformed email addresses>
<watch 368 patches be applied and committed>
<work work work>
<get a new patch queue>
$ (cd /home/src/linux-2.6.git && git pull)
$ stg pull
$ stg branch --create rt-2.6.23-rc8-rt1 v2.6.23-rc9
$ stg import --series --ignore --replace ../sources/patch-queue-2.6.23-rc9-rt1/series
Checking for changes in the working directory ... done
stg import: env git-commit-tree 520b9d0db6a1142271a68b2b38cca002be40f6cb -p
da0a81e98c06aa0d1e05b9012c2b2facb1807e12 failed (fatal:
da0a81e98c06aa0d1e05b9012c2b2facb1807e12 is not a valid 'commit' object)

At this point I'm clueless as to:

1. What I've done wrong
2. How to recover/debug this

I really like using stgit to manage the patch queue with each patch as a commit, so
I'd prefer to figure out how to either use stgit properly, or fix whatevers going wrong.

Thanks,
Clark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHA6TuqA4JVb61b9cRAl12AJ0V3SNg9hO4cnFhefRS/mWdGF696ACeNspM
a+aLdBeFCHCPeyypUr6AwJQ=
=Z2eU
-----END PGP SIGNATURE-----

Re: Problems using StGit and -rt kernel patchset

[Catalin Marinas]

Clark,

What version of StGIT are you using? You might use a too new GIT with an
older StGIT or maybe there are just some bugs in StGIT.

On Wed, 2007-10-03 at 09:19 -0500, Clark Williams wrote:
> I've been working on the -rt patch series for the kernel and would like to to use
> StGit to manage the patches. Unfortunately I've had limited success, so I thought I'd
> ask the git/stgit community if what I'm doing is wrong.
> 
> I clone Linus's tree to a common directory, then clone it locally to work:
> 
> $ git clone -s -l /home/src/linux-2.6.git scratch.git
> $ cd scratch.git
> $ stg init
> $ stg branch --create rt-2.6.23-rc8-rt1 v2.6.23-rc8
> $ stg import --series --ignore --replace ../sources/patch-queue-2.6.23-rc8-rt1/series
> <fix the things quilt lets through and stg barfs on, like malformed email addresses>

If git-quiltimport behaves better with malformed patches, use it and run
'stg uncommit -n 368' afterwards (the 'uncommit' takes some other useful
options as well, see --help).

> <watch 368 patches be applied and committed>
> <work work work>

Do you modify any of the -rt patches or you create new ones?

> <get a new patch queue>
> $ (cd /home/src/linux-2.6.git && git pull)
> $ stg pull
> $ stg branch --create rt-2.6.23-rc8-rt1 v2.6.23-rc9
> $ stg import --series --ignore --replace ../sources/patch-queue-2.6.23-rc9-rt1/series
> Checking for changes in the working directory ... done
> stg import: env git-commit-tree 520b9d0db6a1142271a68b2b38cca002be40f6cb -p
> da0a81e98c06aa0d1e05b9012c2b2facb1807e12 failed (fatal:
> da0a81e98c06aa0d1e05b9012c2b2facb1807e12 is not a valid 'commit' object)

I'm not sure why the first import worked. It seems that StGIT uses the
tag id (da0a81e9) rather than the corresponding commit id (3146b39c). I
remember having this problem in the past when creating branches and I
fixed StGIT to always get the corresponding commit id. Using
'v2.6.23-rc9^{commit}' as the 'branch' argument rather than just the tag
should fix the problem.

> At this point I'm clueless as to:
> 
> 1. What I've done wrong

Probably nothing (just hidden features of StGIT :-))

> 2. How to recover/debug this

You can recreate the branch with the commit rather than tag id. With a
sufficiently new StGIT, you could use 'stg rebase <id>' on the branch. I
assume that no patch was pushed because import failed (though the first
imported patch might be in an undefined state and can be removed).

Catalin

Re: Problems using StGit and -rt kernel patchset

[Clark Williams]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Catalin Marinas wrote:
> Clark,
> 
> What version of StGIT are you using? You might use a too new GIT with an
> older StGIT or maybe there are just some bugs in StGIT.
> 

$ stg --version
Stacked GIT 0.13
git version 1.5.3.3
Python version 2.5.1 (r251:54863, Sep 14 2007, 10:49:05)
[GCC 4.1.2 20070821 (Red Hat 4.1.2-23)]


> On Wed, 2007-10-03 at 09:19 -0500, Clark Williams wrote:
>> I've been working on the -rt patch series for the kernel and would like to to use
>> StGit to manage the patches. Unfortunately I've had limited success, so I thought I'd
>> ask the git/stgit community if what I'm doing is wrong.
>>
>> I clone Linus's tree to a common directory, then clone it locally to work:
>>
>> $ git clone -s -l /home/src/linux-2.6.git scratch.git
>> $ cd scratch.git
>> $ stg init
>> $ stg branch --create rt-2.6.23-rc8-rt1 v2.6.23-rc8
>> $ stg import --series --ignore --replace ../sources/patch-queue-2.6.23-rc8-rt1/series
>> <fix the things quilt lets through and stg barfs on, like malformed email addresses>
> 
> If git-quiltimport behaves better with malformed patches, use it and run
> 'stg uncommit -n 368' afterwards (the 'uncommit' takes some other useful
> options as well, see --help).

Ah, I *knew* I had seen a git import command go by on the list. I may try that.

> 
>> <watch 368 patches be applied and committed>
>> <work work work>
> 
> Do you modify any of the -rt patches or you create new ones?

I've modified patches in the past, but normally I just apply patches on top of the
- -rt patchset

> 
>> <get a new patch queue>
>> $ (cd /home/src/linux-2.6.git && git pull)
>> $ stg pull
>> $ stg branch --create rt-2.6.23-rc8-rt1 v2.6.23-rc9
>> $ stg import --series --ignore --replace ../sources/patch-queue-2.6.23-rc9-rt1/series
>> Checking for changes in the working directory ... done
>> stg import: env git-commit-tree 520b9d0db6a1142271a68b2b38cca002be40f6cb -p
>> da0a81e98c06aa0d1e05b9012c2b2facb1807e12 failed (fatal:
>> da0a81e98c06aa0d1e05b9012c2b2facb1807e12 is not a valid 'commit' object)
> 
> I'm not sure why the first import worked. It seems that StGIT uses the
> tag id (da0a81e9) rather than the corresponding commit id (3146b39c). I
> remember having this problem in the past when creating branches and I
> fixed StGIT to always get the corresponding commit id. Using
> 'v2.6.23-rc9^{commit}' as the 'branch' argument rather than just the tag
> should fix the problem.
> 

Gah, I just realized I typoed the above stg branch. It should have been named
rt-2.6.23-rc9-rt1.

Hmmm, you're saying that when I want to create a branch that's based on a particular
tag, I need to use this:

$ stg branch --create rt-2.6.23-rc9-rt1 v2.6.23-rc9^{commit}

That is, add '^{commit}' to the tag I want to base from?

>> At this point I'm clueless as to:
>>
>> 1. What I've done wrong
> 
> Probably nothing (just hidden features of StGIT :-))
> 
>> 2. How to recover/debug this
> 
> You can recreate the branch with the commit rather than tag id. With a
> sufficiently new StGIT, you could use 'stg rebase <id>' on the branch. I
> assume that no patch was pushed because import failed (though the first
> imported patch might be in an undefined state and can be removed).
> 

I'm not really sure that 'stg rebase' is what I want, since I tend to go back and
forth between -rt kernel and would like to leave them alone (i.e. not rebase the
rt-2.6.23-rt8 branch to rt-2.6.23-rt9, but just create a new branch). Possibly I'm
missing a usage for stg rebase?


Thanks for the ideas. I'll go try some out right now!

clark

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHBnRUqA4JVb61b9cRAvoPAJsG4Ej3J6mSuHeT6KEpiRF33+4dcgCglmvT
18DbpCixAt/x+Ug0pUn24cw=
=oL/g
-----END PGP SIGNATURE-----