Re: What's in git.git

From: Junio C Hamano <junkio@cox.net>
Date: Feb 9, 2006, 10:32 UTC
Message-ID: <7vfymsddqo.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.63.0602091055540.24701@wbgn013.biozentrum.uni-wuerzburg.de>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> IMHO what you intend to put into "next" should be put into "master" 
> anyway: everyone interested in git development should try the new features 
> as early as possible.

Yes, but I've been trying to be _very_ conservative to keep "master" clean and stable, as I said in my inauguration speech.

Since git is still young and we are building features that are needed in the field every day, it is very beneficial for users to keep up-to-date with "master", and I would really like to encourage that. It saddens me to see git patches posted to the kernel list marked with 0.99.9.GIT by prominent kernel people.

However, I do not want to see their time wasted on getting bitten by stupid bugs I carelessly place on the "master" branch. So I'd like to keep "master" conservative, stable and boring, at least for now.

Instead of introducing "next", I could treat "pu" the way I said I would do "next". But even if I rid of its constant rewinding nature, "pu" tends to have intrusive stuff near its tip and is very hard to build on top of it. Patches against the tip of "pu" to fix things unrelated to the whacky ones often would be inapplicable to "master". This is especially true with what are currently pending near the tip of "pu" (bind commits and shallow clones). I do not forsee them to graduate to "master" any time soon. Not in their current shape.

The promised "next" should be much easier to build on top of, without disecting it into component topic branches, and it would be the branch to track for people interested in git development if you want to stay closer to the edge without touching bleeding or even broken edge. Making it easier to participate in git development by people interested is what I am aiming at here.

I've considered publishing the topic branches individually. Branches are cheap from the storage point of view (not really, one inode and a filesystem block wasted to store only 41-bytes ;-)), but it needs management time and care (I will need to remember to go to the repository and remove stale ones once they are merged up). Since branches in "next" are meant to be short-lived, I am hoping it is easier for me to bundle them up like I am planning.

On the other hand, long-lived whacky intrusive ones might be better published as individual branches.