Ralph Goers wrote:
Ceki wrote: 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.
Yes but that's not the whole story.
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.
In Eclipse, unless I am mistaken, the local history extends to the current Eclipse session. The local history functionality offered by an IDE is simply no match to the functionality offered by a fully-fledged version control system. Dot. (I wrote Dot instead of Period because the latter is devoid of any humor.)
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.
No immediate advantage but read on.
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?
Good question. The answer can be found at http://github.com/mbreese/couchdb4j/tree/master , the the original tree that Tim forked. If you click on the icon with the 3 branches, you'll be taken to http://github.com/mbreese/couchdb4j/network where you can actually see Tom's changes. In light of the above, Tim's statement about "if the person who maintains the original project finds my changes interesting, he or she can pull them into his own" makes a lot of sense. I also like the fact that his motivation was limited to personal utility (scratching his own itch) but the end result is potentially increased community/global utility. Also note that he has 5 distinct commits each of which is separately available from github. As a project maintainer, I find it much more convenient to look at smaller chunks of changes instead of one big patch. The fact that one can easily follow his changes is quite appealing and should facilitate the integration of his changes into the main tree.
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.
I was also wondering if git was merely the hype-du-jour. This critical discussion indicates that there is some added value in git. Adopting git will not increase the IQ of contributors nor of the project maintainer, but it will make interaction between various participants a bit easier. Cheers, -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch