All of lore.kernel.org
 help / color / mirror / Atom feed
From: Clark Williams <clark.williams@gmail.com>
To: catalin.marinas@gmail.com
Cc: git@vger.kernel.org
Subject: Re: Problems using StGit and -rt kernel patchset
Date: Fri, 05 Oct 2007 12:28:52 -0500	[thread overview]
Message-ID: <47067454.3060003@gmail.com> (raw)
In-Reply-To: <1191591921.7321.63.camel@pc1117.cambridge.arm.com>

-----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-----

      reply	other threads:[~2007-10-05 17:29 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-03 14:19 Problems using StGit and -rt kernel patchset Clark Williams
2007-10-05 13:45 ` Catalin Marinas
2007-10-05 17:28   ` Clark Williams [this message]

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=47067454.3060003@gmail.com \
    --to=clark.williams@gmail.com \
    --cc=catalin.marinas@gmail.com \
    --cc=git@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.