Re: [RFC] git-publish

From: Fredrik Kuivinen <freku045@student.liu.se>
Date: Aug 13, 2006, 19:42 UTC
Message-ID: <20060813194256.GB5205@c165.ib.student.liu.se>
In-Reply-To: <20060813191346.GA21487@mars.ravnborg.org>

On Sun, Aug 13, 2006 at 09:13:46PM +0200, Sam Ravnborg wrote:

Show 18 quoted lines

> On Sun, Aug 13, 2006 at 12:34:49PM -0400, Daniel Barkalow wrote:
> > 
> > Actually, I'm also curious as to how other people generate the series of 
> > commits for a patch series, when they've actually got a working directory 
> > that contains the end result. I doubt that people actually do their 
> > modifications in patch order, committing each time, without writing 
> > and testing the end result.
> hack hack
> git commit -a
> test <= ohh crap a trivial bug
> git format-patch HEAD^..HEAD
> git reset HEAD^ --hard
> patch -p1 0001*
> hack hack
> git commit -a <= reading in old changelog from 0001*
> 
> The above is easier if you know git I expect.
> If I find bugs in older patches I just go back more steps.

If it is the top commit you want to change it is possible to do so with the '--amend' option to git commit. Instead of the sequence of commands above you can just do:

    hack hack
    git commit -a
    test <= trivial bug
    hack hack
    git commit -a --amend

It wont work if you find bugs in older patches though.

Show 9 quoted lines

> 
> I often (twice or more for each kernel release) throw away my kbuild.git
> tree and start all over.
> That gives me a recent kernel to work with and still providing Linux
> with a linar history.
> 
> I have considered stgit - but have not tried it. The above works pretty
> well for me (my fingers and my logic i accused to it now) so the
> incentive to shift is small.

I really like stgit. IMHO it is much easier to use stgit when preparing a patch series compared to git itself. Maybe it is because I never got used to the sequence of commands you described above.

- Fredrik