6 ms·

Seems like a textbook example of NIH to me. By the time you understand git well enough to design a good replacement, you’re bound to be an expert and ought to a

Seems like a textbook example of NIH to me. By the time you understand git well enough to design a good replacement, you’re bound to be an expert and ought to appreciate more the design of git. If you don’t like the lack of a good GUI or web application, you can just build one that works the way you want and still works with git.

tootie 3y ago
Not to be whiny, but we had better versions of git before git was the standard. I'm thinking specifically of Mercurial.
- zeroimpl 3y ago
  I thought they both started at the same time? Unless you are implying early versions of git were worse, which wouldn't surprise me. I know git has a learning curve, but the only times I really see junior people have issues is when they are trying to do things that wouldn't have been easy with earlier VCS systems either. And it seems like git isn't going away, so it's worth putting the time into learning it.
- happymellon 3y ago
  As someone who used Mercurial for many years when I worked at a company that used because they used BitBucket, you are overblowing the situation. The CTO was very vocal about how Mercurial was better, but all the use cases he toted weren't really that meaningful. Eventually when BitBucket removed Mercurial support we switched to git. I'd used git previously and hadn't really understood the advantages of hg, and after we switched to git there was no difference in productivity. Mercurial wasn't better, it's just slightly different enough to have a holy war over.
- nwallin 3y ago
  Git came before Mercurial. Both git and Mercurial were spawned by the same event; BitKeeper revoking its free license for Linux kernel development. Git development began 2005-04-03, and was self hosting on the 7th. The next minor release of Linux used git as its SCM. Mercurial was announced on 2005-04-19, and has been self hosting since 2005-05-03. Original git commit: https://github.com/git/git/commit/e83c5163316f89bfbde7d9ab23ca2e25604af290 https://github.com/git/git/commit/e83c5163316f89bfbde7d9ab23... Original Mercurial commit: https://repo.mercurial-scm.org/hg/rev/9117c6561b0b https://repo.mercurial-scm.org/hg/rev/9117c6561b0b
somat 3y ago
I always refer to this as stockholm syndrome.
JaDogg 3y ago
IMHO, only problem with NIH is if it is not open. (Example create your own closed sourced - version control system, build tool, etc) Reinventing is how I learn, and there is no harm in that.
- zeroimpl 3y ago
  That’s true for personal projects, which is essentially the case here. If this was a business, not so much. I was probably too harsh in my initial message, but when I read the article and see reasoning along the lines of “git lacks a good UI for X, I hear there may be 3rd-party solutions to this problem, but then that’s too many things to install, so I’d rather build a custom solution from scratch which does everything”, it reminds me of stuff I see at work ;)

tootie 3y ago

Not to be whiny, but we had better versions of git before git was the standard. I'm thinking specifically of Mercurial.

zeroimpl 3y ago
I thought they both started at the same time? Unless you are implying early versions of git were worse, which wouldn't surprise me. I know git has a learning curve, but the only times I really see junior people have issues is when they are trying to do things that wouldn't have been easy with earlier VCS systems either. And it seems like git isn't going away, so it's worth putting the time into learning it.
happymellon 3y ago
As someone who used Mercurial for many years when I worked at a company that used because they used BitBucket, you are overblowing the situation. The CTO was very vocal about how Mercurial was better, but all the use cases he toted weren't really that meaningful. Eventually when BitBucket removed Mercurial support we switched to git. I'd used git previously and hadn't really understood the advantages of hg, and after we switched to git there was no difference in productivity. Mercurial wasn't better, it's just slightly different enough to have a holy war over.
nwallin 3y ago
Git came before Mercurial. Both git and Mercurial were spawned by the same event; BitKeeper revoking its free license for Linux kernel development. Git development began 2005-04-03, and was self hosting on the 7th. The next minor release of Linux used git as its SCM. Mercurial was announced on 2005-04-19, and has been self hosting since 2005-05-03. Original git commit: https://github.com/git/git/commit/e83c5163316f89bfbde7d9ab23ca2e25604af290 https://github.com/git/git/commit/e83c5163316f89bfbde7d9ab23... Original Mercurial commit: https://repo.mercurial-scm.org/hg/rev/9117c6561b0b https://repo.mercurial-scm.org/hg/rev/9117c6561b0b

somat 3y ago

I always refer to this as stockholm syndrome.

JaDogg 3y ago

IMHO, only problem with NIH is if it is not open. (Example create your own closed sourced - version control system, build tool, etc) Reinventing is how I learn, and there is no harm in that.

zeroimpl 3y ago
That’s true for personal projects, which is essentially the case here. If this was a business, not so much. I was probably too harsh in my initial message, but when I read the article and see reasoning along the lines of “git lacks a good UI for X, I hear there may be 3rd-party solutions to this problem, but then that’s too many things to install, so I’d rather build a custom solution from scratch which does everything”, it reminds me of stuff I see at work ;)