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.ht...
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