cURL / Mailing Lists / curl-library / Single Mail


Re: Using git to regenerate patches (was Re: [PATCH 1/7] Comment and debug output fixes.)

From: Carlo Wood <>
Date: Mon, 10 Nov 2014 15:49:22 +0100

On Mon, 10 Nov 2014 09:47:25 +0100 (CET)
Daniel Stenberg <> wrote:

> An easy way is to just commit the fix in the local branch where you
> do your patch series, and then 'git rebase -i' and move the fix next
> to the one one being fixed and mark it as 'fixup'. Done.

I know git :p.
A rebase is only possible (or can be called "natural" anyway) as long
as you didn't push your changes. However I did, two other people are
using the repository to compile and test that I know of, others might
because it's on github after all. I can create local-only branches
and do rebasing there but then I still have to apply the incremental
patches the normal way to the published repository; all in all, it's
just extra work.

I think I'm going to do the following now:
For each submitted patch I will create a new (local) branch, if patches
depend on each other then I'll merge them first. Then I can use git
to just generate a "diff between branches". The downside of this is
that having currently 7 outstanding patches (assuming all depend on
each other) making a change in the first one will require me to
to do six merges %-). I might opt for concentrating on the first patch
until it is merged in your repository and then go to the next :p.
That will still be easier. Hence that I compared this work flow with

Carlo Wood <>
List admin:
Received on 2014-11-10