[logback-dev] Git as a version control system?
rgoers at apache.org
Fri Aug 7 18:02:43 CEST 2009
> 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
>> 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
> 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.
More information about the logback-dev