Status of git.git repository

I've been trying to streamline my workflow since I took it over from Linus, and I think I am getting used to it. So here is a short summary of what I am doing in the git.git repository.

Right now, there are two branches on kernel.org git.git repository. I would not rewind "master" so if I find out any screwups and need to do an emergency fix, that fix would go on top of the tip of "master" (I just did one today X-< due to lack of testing).

On the other hand, "pu" is rebased every time "master" advances. They are queued patches I receive in e-mails, and they hopefully will graduate to be part of "master" when I feel they look OK, and I feel that objections from the list were non-issues. Of course some may drop out without graduating. Please consider seeing your patch in "pu" branch an ACK from me, but seeing it sitting in "pu" for a long time is a sign of trouble.

By the way, do people mind my posting my own patches to the list? I keep the same in the "pu" (proposed updates) branch, so if the list readers think I am just adding noise to the list traffic, I would stop doing so, and instead just invite interested people to browse the "pu" branch.

Dear diary, on Sat, Jul 30, 2005 at 04:11:48AM CEST, I got a letter where Junio C Hamano <junkio@cox.net> told me that...

Browsing the "pu" branch may be bothersome and you won't ensure that the related discussion stays in a single thread, and posting the patches here makes them generally more visible, so I think it's a good idea to keep doing so.

Cogito (and Git itself as well, I guess) does not handle those "volatile" branches well at all - following them is difficult since Cogito will think that you did some local commits and want to do a tree merge. Would anyone consider doing

	if ref(updatebranch) == ref(master) then
		merge: always_fastforward
	else
		merge: perhaps_treemerge

a Bad Thing (tm)? It seems to me that it should do the right thing and never get it wrong.