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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html