Re: What's in git.git

Johannes Schindelin [off-list ref] 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.  

Hi,

On Thu, 9 Feb 2006, Junio C Hamano wrote:

Branches are cheap from the storage point of view (not really,
one inode and a filesystem block wasted to store only 41-bytes
;-)), [...]

Not really. I use reiserfs which is quite efficient on these small files.

Hth,
Dscho