lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 27 Oct 2009 09:48:36 +0000
From:	Catalin Marinas <>
To:	David Miller <>
Subject: Re: [RFC] to rebase or not to rebase on linux-next

David Miller <> wrote:
> From: Steven Rostedt <>
> Date: Mon, 26 Oct 2009 19:51:01 -0400
>> I get something working and then commit it. Then I do more changes
>> and commit that. I don't use quilt anymore for this.
> And you can do this all day long if you like.
> What you can't do is _PUBLISH_ this anywhere to a tree that people
> also do development against _UNTIL_ you get those acks and tested-by
> tags back from people.
> Once your acks etc. come in, you can pop all of those pending patches
> out of your tree, add the ack tags to the commit messages, then
> reapply them.
> Then you can push to your public tree, but no sooner.

I use stacked git for my patches and I may rewind the series (fixes
following reviews/testing, acked-by lines etc.) before patches are
pushed into mainline (nothing new here). But to make it easier for
others to test or develop on top of such branch, I added a "stg
publish" command which creates a separate merge-friendly branch that
is never rebased nor rewound (for some implementation details, see The top commit sha1
(and history) of the published and series branches differ but they
always have the same tree so that people using the published branch
always get the same source. You even get to add a comment about what
was modified in the series when publishing the change.

There is currently no way to publish commit message changes like
adding Acked-by (unless the "publish" command would do a revert of the
original commit, though not sure it's worth as it makes the history
more unreadable).

For mainline merging you can send a pull request on the series
(rewound) branch once you are happy with it and don't foresee further
changes (when rebasing a series on the latest mainline, the "publish"
command generates a "merge" with mainline so that people pulling both
the published branch and mainline don't need to resolve the possible
conflicts with your series).

A similar script could be easily done for plain git (Stefan Richter
mentioned something like this as well).

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists