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
_______________________________________________
logback-dev mailing list
[email protected]
http://qos.ch/mailman/listinfo/logback-dev
