Comment by harryvederci
4 years ago
Nice, I hope you won't get an avalanche of comments here by grumpy old devs that are afraid this will somehow mean they'll have to learn something new.
I think it's great to look into possibilities of doing things in a better way, even if the majority of people think the current way is the only correct way.
I don't think of myself as old, but certainly grumpy and this comment rubbed me the wrong way.
In my time as a dev I've worked with CVS, SVN, Mercurial, and then git. I can confidently say that no dev I've worked with ever kicked up a fuss when they switched, because each iteration brought improvements.
I would however say that modern devs carry with them modern baggage. There are far too many bootcamps churning out devs who say "this is git, everyone uses it, heres the minimum you need to know". These are the devs who will struggle with this sort of change, it would literally change a magical system they don't fully understand for reasons they may not fully understand.
I would have fussed going from Mercurial to git. Mercurial is arguably superior, much like Fossil, but unfortunately mindshare / marketshare is everything.
The layering model of merging in both those systems is superior to the standard git merge (rebase is close though). they also made cherry picking a trivial operation compared to git
Yeah, I was gonna say exactly this. When I switched from SVN to hg that was a bit of a shock, but I got over it and saw that DVCS was superior.
Going from hg to git has been fairly annoying and... I'm not really convinced it's any better. Or maybe even at parity.
I willingly switched from Mercuial to Git due to, at the time, lack of in-repo branching and lack of history editing. IMO Mercurial shot themselves in the foot with some of their early decisions.
Both POV here can be reconciled with an experience-dependent exploitation-exploration tradeoff.
For everyone,
Eg., suppose t is the reward for exploitation, and r for exploration, and xp is your experience.
Then as xp -> inf, t -> inf and r ->0.
As xp -> 0, the reverse happens: t -> 0 and r -> inf.
"no dev I've worked with ever kicked up a fuss when they switched"
Wow. I don't think your experience is the common one. I've been on teams switching to git, and there was always much fussing. Even if the benefits of switching were clear and it was worth it, doesn't mean there won't be pain along the way.
I've seen whole teams kick and scream about migrating, even when their preferred system was taking minutes to do basic operations because the repo was too large.
I think I qualify as an old developer.
I love learning new exciting things that I know I’ll use for the rest of my live. C, Vim, Bash, HTML, CSS, JavaScript will all outlive everyone here. It’s a pretty safe bet. I hate the amount of useless knowledge I accumulated for obsolete unexciting things.
I feel like Git is not the final answer to version control, it had a lot of great ideas, but it’s not even good enough for some things and too complicated for most others. My hope is that it becomes like SVN, mostly legacy stuff, and that we can build something new with the lessons learned from Git. I wish Jamsync luck, it looks interesting and I freaking love rsync.
I guess Git suffers from a similar problem as (La)TeX: it's a truly great prototype which sadly wasn't thrown away to build something better.
Don't get me wrong, I like both TeX and Git _very_ much. (I even co-authored a LaTeX textbook.) I also have a lot of respect for DEK and LT. But they were trailblazers (especially DEK), and so they did a lot of things not knowing their true impact – and sometimes this means these decisions were far from optimal. (The case of TeX is even worse because the machines of the time were very limited compared to what we have today.)
That's a very interesting take. Both were also developed mostly by one person to do one job. Knuth for his “The Art of Computer Programming” masterpiece and Linus for the kernel. There may be similarities that arise from such histories and constrains.
What do think are the shortcomings of Git?
That it's build on snapshots rather than patches, see darcs or pijul.
I'm not using either, because of the git momentum. Only having to know one is nicer than using one for work and one personally.
In a nutshell, terrible end user UX and naming. Can't deal with largish files well.
Thanks! Haha yeah my plan is to certainly not try to replace any existing tools but provide options for working faster, especially for new developers.
Grumpy old dev here. I make my money cleaning up messes caused by ill-considered attempts to use something new. Thank you. :-)