Live data from Hacker News

Is Git Irreplaceable? (2019)

fossil-scm.org

331–340 of 559 posts

Re: Is Git Irreplaceable? (2019)

#331

Earlier quoted context omitted.

> way better tools I work with a group of people who all know enough git that we're productive, and a few of us know enough git to solve complicated problem. I've not seriously considered fossil or mercurial -- what are the top three tangible benefits I'd get from them getting our team to switch?

I have never used Fossil, but I used to be a strong proponent of Mercurial. My advice is don't - Mercurial lost, git has won, and fighting against the current is just going to make your life harder. The main advantage Mercurial has over git is a command line syntax that makes consistent sense. The operations you want to do are easy and as you try and do more complicated things, the new commands will be unsurprising a…

I know Git inside and out, but I had to use Mercurial for a client a couple years ago. I found it to be the most baffling and nonsensical source control experience of my life. It might be a case of cross-contamination. Like you said, each SCM uses similar terms for different concepts, so my Git knowledge may have unfairly colored how I expected similar terms to work in Mercurial.

But stuff like: "hg log" gives you _every commit in the repo_?? When is that ever useful? How do I get only the commits that lead to the current state of the repo? Mercurial doesn't have branches; instead you're supposed to _copy the whole directory_[1] at the filesystem level?? Of course this is ridiculous, so they invented "bookmarks" which are actually Git branches. The extensions thing you mention is also a ridiculous chore. Just have sane defaults. I also found hg's output very dense and hard to understand and read, poorly suited for human consumption.

I dunno. I'm sure Mercurial is fine, many people use it every day, and likely my strong Git bias was affecting my ability to learn Mercurial. But I found it far easier to just clone into Git, use Git to do source control, and then export back to Mercurial when I'm ready to share my work.

[1] https://www.mercurial-scm.org/wiki/TutorialMerge

Re: Is Git Irreplaceable? (2019)

#332
post #199

> I worry that Git might be the last mass-market DVCS within my lifetime. The possibility of git being the last mass-market DVCS within my lifetime leaves me with warm fuzzy feelings. Git is simple and elegant, though its interface might not be.

I think it's simple and elegant as a data structure, when what people need and want is something that is (at least also) simple and elegant in its UX and most importantly VERY simple and elegant for the 80/20 use cases. For example a typical question on Stackoverflow is "How do I answer which branch this branch was created from", always has 10 smug answers saying "You can't because git doesn't really track that, bran…

As a very basic git user, about once a month my local git repository will get into a state I cannot fix. I cannot revert, cannot reset, cannot make it just fucking be the same as origin/master. Usually I accidentally committed to local master and then did a couple other things and it's just easier to blat and re-clone than work out how to resolve.

Git is hard for idiots imo, and there are a lot of us

Re: Is Git Irreplaceable? (2019)

#333
post #280

Earlier quoted context omitted.

I was happy with SVN because I used CVS before. I was even happy with CVS, because I had nothing before. It's hard to imagine now. Software development has seen massive improvements in the past 20 years. I see no reason why that would stop now.

Asymptotes. Sometimes it turns out we can solve a particular problem so comprehensively that "solve this problem better" is never a reasonable step. You can try it anyway, of course, but you're unlikely to get acknowledgement much less praise. The answer to "Why doesn't my music sound as good as I wanted?" isn't going to be "CD's 44.1kHz and 16-bit PCM isn't enough". It might be "This cable has been chewed by a dog"…

> The answer to "Why doesn't my music sound as good as I wanted?" isn't going to be "CD's 44.1kHz and 16-bit PCM isn't enough".

Yeah, try telling this to a fan of 1960s or 1970s rock. You'll get an earful about rich guitars and fat synths, which only a 100% analog, tube-amp process from studio to ear is capable of replicating.

Re: Is Git Irreplaceable? (2019)

#334
post #199

> I worry that Git might be the last mass-market DVCS within my lifetime. The possibility of git being the last mass-market DVCS within my lifetime leaves me with warm fuzzy feelings. Git is simple and elegant, though its interface might not be.

>> The possibility of git being the last mass-market DVCS within my lifetime leaves me with warm fuzzy feelings.

Agreed. Technology should converge on a best solution so we can stop chasing things and get work done. Stable open source standard solutions are what we need more of.

Some anti-pattern examples are C++ and Vulcan.

Re: Is Git Irreplaceable? (2019)

#335

Earlier quoted context omitted.

I think it's simple and elegant as a data structure, when what people need and want is something that is (at least also) simple and elegant in its UX and most importantly VERY simple and elegant for the 80/20 use cases. For example a typical question on Stackoverflow is "How do I answer which branch this branch was created from", always has 10 smug answers saying "You can't because git doesn't really track that, bran…

As a very basic git user, about once a month my local git repository will get into a state I cannot fix. I cannot revert, cannot reset, cannot make it just fucking be the same as origin/master. Usually I accidentally committed to local master and then did a couple other things and it's just easier to blat and re-clone than work out how to resolve. Git is hard for idiots imo, and there are a lot of us

> Git is hard for idiots imo, and there are a lot of us

Then let the idiots end up screwing their own local repo, instead of doing some magic and making it easy to screw up upstream or someone else repo.

Re: Is Git Irreplaceable? (2019)

#336
post #320

The problem with Git is that the software and API aren't separated. Like all modern software, there should be an API or interface to which all distributed source control engines comply, allowing the specific DVCS engine to an implementation detail. Want the old-school one written in C by Linus? Fine. Want a revamped version of Mercurial that uses the same commands and creates the same repository format? Cool! Want to…

Of course it has, the other implementation that comes to mind now is JGit [1], a git implementation in Java. A lot of IDEs, build plugins are using it for interfacing with git without the mess that is JNI

[1]: https://www.eclipse.org/jgit/

Re: Is Git Irreplaceable? (2019)

#337
post #320

The problem with Git is that the software and API aren't separated. Like all modern software, there should be an API or interface to which all distributed source control engines comply, allowing the specific DVCS engine to an implementation detail. Want the old-school one written in C by Linus? Fine. Want a revamped version of Mercurial that uses the same commands and creates the same repository format? Cool! Want to…

Git has a low level plumbing layer and a high level porcelain layer. The design allows for writing alternative porcelain layers. I believe magit is an example of this.

Re: Is Git Irreplaceable? (2019)

#338

Earlier quoted context omitted.

> way better tools I work with a group of people who all know enough git that we're productive, and a few of us know enough git to solve complicated problem. I've not seriously considered fossil or mercurial -- what are the top three tangible benefits I'd get from them getting our team to switch?

That is exactly the point. For git you need the ecosystem to cope with it's shortcomings and in addition some experts to help you out of the pickles this software gets you into. I mainly use fossil for personal projects. Whats nice about it is that it not only is a very capable VCS but also a complete project management tool with tickets/issues, wiki, blog, mailing list and user management. The setup is ridiculously…

>Whats nice about it is that it not only is a very capable VCS but also a complete project management tool with tickets/issues, wiki, blog, mailing list and user management.

That seems like feature creep.

Re: Is Git Irreplaceable? (2019)

#339
post #279

Earlier quoted context omitted.

I think it's simple and elegant as a data structure, when what people need and want is something that is (at least also) simple and elegant in its UX and most importantly VERY simple and elegant for the 80/20 use cases. For example a typical question on Stackoverflow is "How do I answer which branch this branch was created from", always has 10 smug answers saying "You can't because git doesn't really track that, bran…

Another simple tracking thing that git doesn't do that would easily make git much much better is if it tracked when you did a cherrypick of another commit in the commit graph (not just as some kind of metadata comment in the commit message, but as a kind of soft parent); then if you did a rebase, you could actually "reverse engineer" the rebase (if and only if you absolutely needed to, such as to track what happened…

Another thing Git does not and cannot even attempt to do - file locking.

The assumption behind Git is, everyone develops on their machines and/or branches, and then things are merged. This only works for files which can be merged.

There are plenty of things pretty much any project wants to track which cannot be merged, for example Word documents (documentation), Photoshop files (source of graphics), PNGs (icons in webapps), and so on.

With a centralized system, that's easy, just go over to using file locks ("svn lock") for those files. With a distributed system, that's impossible.

Re: Is Git Irreplaceable? (2019)

#340
post #199

> I worry that Git might be the last mass-market DVCS within my lifetime. The possibility of git being the last mass-market DVCS within my lifetime leaves me with warm fuzzy feelings. Git is simple and elegant, though its interface might not be.

To me it's proof that we as an industry finally arrived at a consensus over something.
Post reply on HN