[logback-dev] Git as a version control system?

[Ceki Gulcu]

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

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