[logback-dev] Git as a version control system?

[Ralph Goers]

> 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