linux-kernel - Re: [RFC] to rebase or not to rebase on linux-next

lists.openwall.net		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 linux-cve-announce 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]

Message-ID: <tnx4opl5frf.fsf@pc1117.cambridge.arm.com>
Date:	Tue, 27 Oct 2009 09:48:36 +0000
From:	Catalin Marinas <catalin.marinas@....com>
To:	David Miller <davem@...emloft.net>
Cc:	rostedt@...dmis.org, sam@...nborg.org, mingo@...e.hu,
	linux-kernel@...r.kernel.org, nico@...xnic.net,
	tony.luck@...el.com, sfr@...b.auug.org.au, mcgrof@...il.com,
	jeff@...zik.org, robert.richter@....com, dmitry.torokhov@...il.com,
	khali@...ux-fr.org, torvalds@...ux-foundation.org
Subject: Re: [RFC] to rebase or not to rebase on linux-next

David Miller <davem@...emloft.net> wrote:
> From: Steven Rostedt <rostedt@...dmis.org>
> 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
http://procode.org/stgit/doc/stg-publish.html). 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).

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/