-----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-----
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
