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: <20061020210822.GH10128@ca-server1.us.oracle.com>
Date:	Fri, 20 Oct 2006 14:08:22 -0700
From:	Mark Fasheh <mark.fasheh@...cle.com>
To:	Pierre Ossman <drzeus-list@...eus.cx>
Cc:	Andrew Morton <akpm@...l.org>, Linus Torvalds <torvalds@...l.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: Git training wheels for the pimple faced maintainer

On Fri, Oct 20, 2006 at 08:45:36AM +0200, Pierre Ossman wrote:
> Hmm.. What is the gain of having two tree instead of just more branches?
That way I have my own private playground where I can mess around with
patches, prototype new ideas, etc. It also serves as my local repository of
patches I got from other folks. I treat ocfs2.git as a 'public' repository,
so I don't want to pollute it with junk branches, etc.


> > 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?
Yeah. I just remove it after the merge and re-create later, but I could just
fast-forward it if I wanted to. I guess it's personal preference - it
doesn't really cost me much to re-create the for-linus branch.

 
> 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?
Yep. ALL is essentially a throwaway branch. Keep in mind that the topic
branches don't get thrown out until they've been merged upstream.

Typically people aren't pulling continuously from ALL. Most patches are
against Linus' tree - I take it as part of my "job" to handle merging stuff
into ALL.

 
> 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.
Yes, generally you now have the responsibility of deciding what patches in
your git tree are appropriate to be pushed upstream at any given time :)
There are rules that people should follow of course, which Linus outlined
earlier in this thread.

Good Luck!
	--Mark

--
Mark Fasheh
Senior Software Developer, Oracle
mark.fasheh@...cle.com
-
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/