Re: [RFC] git-publish

On Sun, Aug 13, 2006 at 09:13:46PM +0200, Sam Ravnborg wrote:
> 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.

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

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html