linux-kernel - Re: Git training wheels for the pimple faced maintainer

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: <45387090.7020509@drzeus.cx>
Date:	Fri, 20 Oct 2006 08:45:36 +0200
From:	Pierre Ossman <drzeus-list@...eus.cx>
To:	Mark Fasheh <mark.fasheh@...cle.com>, Andrew Morton <akpm@...l.org>
CC:	Linus Torvalds <torvalds@...l.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: Git training wheels for the pimple faced maintainer

Mark Fasheh wrote:
> On Thu, Oct 19, 2006 at 04:44:41PM -0700, Linus Torvalds wrote:
>   
>> I think people have seen the messages that other people send out (eg at 
>> least Greg KH tends to Cc: those messages to linux-kernel, so others can 
>> see what's going on too - although not all other maintainers do that).
>>     
> I noticed also that people started sending out "What's in XX.git" type
> messages at the beginning of a merge window to describe what might shortly
> get sent upstream.
>
>   

Yes, I've found those to be quite nice. I'll try to remember to send my own.

>   
>> Other git maintainers may have other hints about how they work. Anybody?
>>     
> I think I have a slightly different workflow than what Pierre describes. I
> find that it works well for me and it keeps things very organized in
> ocfs2.git. It's also probably a little more work than other methods for
> managing a git tree that people employ. Hopefully a description of my
> process will be useful to someone.
>
> Basically I have two trees, ocfs2.git which is the main ocfs2 repository and
> my own personal linux-2.6.git which I actually hack in.
>   

Hmm.. What is the gain of having two tree instead of just more branches?

> Once I'm ready to send an upstream pull request, I'll update the master
> branch of ocfs2.git. I then make a for-linus branch based off of it, and
> git-cherry-pick each individual patch into that branch and send my request.
>   

This should be equivalent of just keeping the "for-linus" branch around
as it will just fast-forward along with Linus' tree when it doesn't
contain any local changes. Or am I missing something?

> Once Linus pulls, I'll re-make the ALL branch for Andrew by re-pulling all
> the patchsets which weren't a part of that pull request.
>   

In other words, you destroy all the old history of your ALL branch and
create a new one? So you couldn't continuously pull from that branch?

> Btw, I cannot over state how important and useful it is to have patches go
> to -mm first.
>   

My intention was always to send him everything but the most trivial patches.

On questions related to that though. Previously, I've always sent plain
patches to Andrew. After they have simmered a bit in -mm, he usually
pushes them on to Linus, even though they do not qualify as being just
bug fixes. As I will now be the one moving stuff from "from-andrew" to
"for-linus", will the decision of what to move now fall on me? I would
probably be more inclined to wait for the next merge window than Andrew is.

Thanks

-- 
     -- Pierre Ossman

  Linux kernel, MMC maintainer        http://www.kernel.org
  PulseAudio, core developer          http://pulseaudio.org
  rdesktop, core developer          http://www.rdesktop.org

-
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/