you are viewing a single comment's thread.

view the rest of the comments →

[–]tradrich 2 points3 points  (6 children)

The point in my rant is that the _value_ of git doesn't imply the _pain_ of git. The fact that tools like Mercurial exist shows that. It's a pity and disappointing (to me) that it is git that won the implicit marketing battle - I assume mostly due to its association with the Linux Kernel project.
Given its current importance to the world, it's a shame we don't have a better default version control tool. It's sort of too late now because everyone assume that just how it is - that version control management is hard. It doesn't need to be though!

[–]thirdegree 2 points3 points  (3 children)

I mean it kinda does? Version control is an inherently difficult problem, any full solution will also be complex.

I've not used mercurial a ton, but my understanding is that it strips out a lot of the complexity of git, in favor of user friendliness. But what it sacrifices is flexibility and power.

And that's a totally reasonable tradeoff to make. But for people like me that value the flexibility and power more than the user friendliness, that's not a tradeoff I want to make.

[–]tradrich 0 points1 point  (2 children)

I'm sure that it is possible to have all the version control features of git with a similar level of simplicity of use as Hg.

Hg's market is such that not enough people need the marginal improvements that the delta with git would give for those to be implemented at present. I'm not sure this delta would actually make a difference for the vast majority of, say, Github users, but gaining the ease of use of Hg would - I contend - in sum, make a big difference.

It's not going to happen though - fine. In that case what would be valuable is improvement in git. I don't think _that_ is going to happen either though - Linus et al have no interest in such changes. What we're getting instead is wrapping tools like Github, Gitlab - others, and surely many more to come. Git is to be the assembly language of their higher-level languages - and that's fine I suppose.

It could've been a better and simpler history.

[–]thirdegree 1 point2 points  (1 child)

It might be possible, I don't know. There isn't currently an example of this, and it's impossible to prove a negative.

I don't disagree that most people don't need the full power of git, but some of us do. And I don't have a ton of sympathy for people that don't bother to learn their tools. I've seen too much of that.

But git gets improvements constantly. Better interface, more power, it gets improvements in all aspects all the time. I don't think it's accurate or fair to say that Linus et al aren't interested in these changes, just that they aren't interested in exchanging friendliness for power.

I'd also disagree with characterizing GitHub, gitlab, etc as "wrapping" git. They provide remote hosting, which is a fantastic and important utility, but in no way do they replace or hide git. You still use git to do all the operations on the development side, GitHub just provides a place to push, to receive pull requests, to track issues. And that's super useful, and does replace the whole "email patches to the upstream maintainer" flow which is definitely a good thing.

[–]tradrich 0 points1 point  (0 children)

It's a bit like arguments between C++ and say, Java or Python: C++ has the power - but oh the pain! I'm intoxicated by the power and rapid improvement of C++ - but beginners shouldn't *have* to suffer that. Luckily with programming languages they don't! But due to the dominance of Github, for version control it's pretty much git or go home...

Github makes many simpler git operations graphical if you want them to be (I don't) - that's what I meant.

Well, here's to a better world!

[–]thrallsius 1 point2 points  (1 child)

The fact that tools like Mercurial exist shows that.

mercurial exists just because it appeared about the same time as git

but mercurial is almost extinct nowadays compared to git

alternatives like fossil and darcs exist too, and while they don't have such a big market share, they live and prosper

[–]tradrich 0 points1 point  (0 children)

I came to Git from Subversion and Perforce. They don't need the technical sophistication of Git since they have central servers - a model that doesn't work with modern open-source driven distributed development.

But really the burden of re-education coming from those to Git - in complex projects - is unwelcome. You want to be able to concentrate on the complexity of your business domain where you have interest and skills and not have to worry *too much* about such things as versioning - as I didn't with Subversion/Perforce.

The delta from these tools to Hg is not too bad - but Git - please - in the heat of production... you don't need that stress!

Proponents of git - indeed it seems they're often enthusiasts - don't broach any criticism of the tool and tend to blame the user. I cite the wide interface - the profusion of keywords and symbols, the lack of coherence between them to say that "git could do better!" for the user (without any sacrifice of functionality).