On Aug 7, 2009, at 7:55 AM, Ceki Gulcu wrote:
Ralph Goers wrote:
I'm not 100% sure what the real benefit would be. Ultimately the code needs to be committed back to logback. How would using git make it easier? Would we be able to commit somewhere that would allow you to commit stuff to the "real" repository?
That's an excellent question. If git is better at merging and creating forks is easy, Alice could fork logback, work on our branch for a few days or even a few weeks, committing many changes to her forked repository. She could later publicize her repository for others to study. If her changes are deemed interesting, they could be imported back into the "official" logback repository. This is similar to the workflow that would take place on the SVN, except that Alice would not be able to commit her changes locally and nor would she be able to publicize her repository. She would be constrained to patch files.
This is the part I don't get. First, I doubt too many people would be publishing their repositories, at least for the world to see. I could see doing it in my organization where I may need to create my own changes until they are incorporated into the main code base, but frankly I want that to happen as quickly as possible (and you have been very good about that).
What does "imported back into the official logback repository" mean? You aren't going to get access to my repository because it would be behind firewalls. I was under the impression git made it possible to push stuff somewhere where you would be able to pick and choose what you want.
Supposedly this forking and merging is supposed to be the main advantage of git, yet I've never gotten anyone to sufficiently explain it so that my feeble mind can actually grasp what the work flow looks like.
Ralph