Is there a Git Repositories for Unaccept Patches or (work in Progress)?

[Steven Edwards]

On Feb 11, 2008 12:59 AM, Dan Kegel <dank at kegel.com> wrote:
> On Feb 10, 2008 9:57 PM, Steven Edwards <winehacker at gmail.com> wrote:
> > ... Having invested a
> > good bit of time in trying to understand git, I think I git it now so
> > to speak and not having a public repo where there can be really
> > collaborative development seems to be a step back to me.
>
> ?  But you don't need a central public git repository to do
> collaborative development, that's the whole point of git...

Maybe I still don't get git. Right now there are not many others
interested in winequartzdrv and the only place its hosted is in CVS.
I've got it imported locally and I can publish changesets on
wine-patches or bugzilla but thats going to spam wine-patches or be
very sucky for development if its not ready to merge in to master for
months++ or longer. For a proper push or pull to work, I'd either have
to publish my repo here or someone else would have to pick it up and
import it right? Then we could rebase off of each others changes? We
could push and pull to each other via email and still pull in from
winehq and rebase right? Then wouldn't that imply that I'd have to
push my changes to everyone via a mailing or something or still host
my own public repo if multiple people want to pull from my most recent
bleeding edge broken stuff?

It seems to me that its less trouble to have a central repo hosted
somewhere like repo.or.cz where winehq origin is imported in parallel
and as changes come in they are merged on to a public winequartzdrv
branch. Then I fix the stuff I know I can fix in my local tree like
the keyboard input handling changes, push those changes up, while
leaving other broken stuff like visable region handling for someone
else to work on. If others come along with an existing winehq tree,
they can pull from that repo without much trouble. I've still got my
local git repo I can branch off of and hack the hell out of and cherry
pick patches from, push them up to the winequartdrv branch on the
public repo, etc.

Thats in effect what I have here. I've got a faux-public git repo and
a private repo where I pull winehq origin in I pull the faux-public's
quartzdrv branch in, I rebase winehq on top of my private branch, fix
the changes and then push the new "stable" winequartzdrv up to my
faux-public repos winequartzdrv branch. It would work really well for
others to pull and push from except. A. I don't want to host it on my
cable modem and B. I can't commit to running it due to lack of time
and skill with the code in question. I can do minor enhancements like
fix up the changes for mouse/keyboard handling now that its moved to
the server but as far as actual design and real programming go I don't
view myself and competent enough to waste my or anyone elses time
publicly hosting. I just did all of this as a experiment to teach
myself git.

-- 
Steven Edwards

"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo