4 ms·
... That still leaves the question, why use an inferior tool? This assumes that git has no significant practical drawbacks that might outweigh the constrained
by nupark 16y ago
... That still leaves the question, why use an inferior tool?
This assumes that git has no significant practical drawbacks that might outweigh the constrained value of its merging support.
A bad car analogy: I never drive in the winter. I commute 1 hour each day to work. I have the choice between:
- A large SUV that gets 15 mpg but has traction control for handling icy winter roads and 16000 lbs of towing capacity
or
- A 30 mpg commuter car.
If we assume that subversion merging works fine (which, in large organizations, is my experience), then the next question is -- what feature(s), exactly warrants git's additional complexity? Why, in our organization, would we want to encourage people to create out-of-sight branches? What is the actual advantage to having individuals care about n-way merges?
- jshen 16y agoSubversion merging does not work fine. I guess you didn't read my links, so I won't spend more time on this.
- nupark 16y agoI read your links. I also use subversion merging every day while maintaing feature and maintenance branches. It works fine and involves significantly less complexity than git.
- jshen 16y agoI use git everyday. I don't know what this complexity is you speak of. It took me a weekend to learn git, and about the same for subversion, but git gives me more flexibility and power.
- nupark 16y agoFlexibility and power come with complexity, and in his case, provide no practical benefits to most organizations. I use git regularly when interacting with open source projects, but don't see the value in it's added complexity and decentralization in corporate environments.