[logback-dev] Git as a version control system?
rgoers at apache.org
Fri Aug 7 21:14:28 CEST 2009
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:
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.
More information about the logback-dev