linux-kernel - Re: [GIT pull] x86 fixes for 2.6.26

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]

Date:	Sun, 18 May 2008 00:45:24 +0200
From:	"Jesper Juhl" <jesper.juhl@...il.com>
To:	"Linus Torvalds" <torvalds@...ux-foundation.org>
Cc:	"Theodore Tso" <tytso@....edu>,
	"Thomas Gleixner" <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>,
	"Ingo Molnar" <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>
Subject: Re: [GIT pull] x86 fixes for 2.6.26

2008/5/17 Linus Torvalds <torvalds@...ux-foundation.org>:
>
>
> On Fri, 16 May 2008, Theodore Tso wrote:
>>
>> Why do you consider rebasing topic branches a bad thing?
>
> Rebasing branches is absolutely not a bad thing for individual developers.
>
> But it *is* a bad thing for a subsystem maintainer.
>
<snip very nice description of when to use rebase>
>
> BUT if you're a subsystem maintainer, and other people are supposed to be
> able to pull from you, and you're supposed to merge other peoples work,
> then rebasing is a *horrible* workflow.
>
<snip stuff on fetch + merge>
> In other words, I very heavily would suggest that subsystem maintainers -
> at least of the bigger subsystems, really see themselves as being in the
> same situation I am: rather than doing the work, trying to make it easy
> for *others* to do the work, and then just pulling the result.
>

Linus,

Thank you for some very good descriptions on proper git workflow. That
was very informative.

As new Trivial tree maintainer I'm trying to figure out how I should
manage that tree, and based on your description on git use I have a
few questions.

What I did for my first merge-window was simply clone your tree,
create a for-linus branch, add all the patches to that branch and ask
you to pull. That worked nicely that once, but I guess that wiping the
tree and starting from a fresh clone every merge window wouldn't be a
good idea - especially since I'd like Trivial to also get pulled into
linux-next.

This is what I think I should be doing going forward. I'd appreciate
it if you could comment on whether or not it's the right way to do
things.

Start off with a clone of your tree (master branch).

Pull your tree into 'master' daily (or at least often).

Create a for-linux-2.6.27 branch or the upcomming 2.6.27 merge window
and apply all the patches I currently have pendng in a mailbox to that
branch. Keep the branch reasonably up-to-date by doing a weekly git
fetch + merge from my 'master' branch that tracks your tree.

Once the 2.6.27 merge window opens, ask you to pull the
'for-linux-2.6.27' branch and once you have done so, leave that branch
alone forever.

Branch off a new 'for-linux-2.6.28' branch and repeat.

As for linux-next, I'd create a 'linux-next' branch that I would
update whenever I change one of the 'for-linux-2.6.xx' branches, by
doing a fetch from the branch into 'linux-next' and then a merge.

Does that sound sane or is there a better way?

-- 
Jesper Juhl <jesper.juhl@...il.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
--
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/