On Aug 7, 2009, at 10:17 AM, Ceki Gulcu wrote:
Ralph Goers wrote:
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.
Here is an attempt at explaining the workflow:
http://blog.discursive.com/2009/08/couchdb4j-is-case-in-point-for-git-and.html
The only thing in that post that makes it "different" is that the
workarea where he did the patch is in a public location instead of on
his local disk. Since IntelliJ keeps a local history of all my edits
even the version control aspects of creating the new repository don't
add much value. Since the blog entry doesn't discuss how his changes
made it back into the "real" repository I still don't know what
advantages this brings. The disadvantage is that there is now a new
repo with forked code that apparently isn't going to be merged back
into the mainline since he "didn't have to stop and figure out
community dynamics" and "if the person who maintains the original
project finds my changes interesting, he or she can pull them into his
own". Does git automatically point you to every forked repository and
magically tell you what they are trying to do there?
I'm not saying git might not be a good thing. I just don't understand
how it is really supposed to work so all these wonderful benefits
everyone talks about actually happen.
Ralph
_______________________________________________
logback-dev mailing list
[email protected]
http://qos.ch/mailman/listinfo/logback-dev
