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

[Ralph Goers]

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