Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Is Git Irreplaceable? (2019)

fossil-scm.org

Post reply on HN
Print view View original

341–350 of 559 posts

Re: Is Git Irreplaceable? (2019)

#341

Post by rkangel »

coldpie wrote: post #331
rkangel wrote: post #325

Earlier quoted context omitted.

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 _e…

Mercurial does absolutely not require you copying at the fs level. You're not the first person to be caught out by that tutorial, which I think would serve us best by being deleted.

The 'original' branching method for Mercurial is called Named Branches. The big difference with Git is that every commit is labelled with what branch it is on. This has advantages - if you imagine looking at the train track of 'master' in git with it's divergence for a few commits and then merge, you can see that the 3 commits were on a branch called 'performance', whereas with git that history is completely lost. See: https://www.mercurial-scm.org/wiki/NamedBranches

As usage of git grew, the git branching model gained popularity and so the Mercurial bookmarks extension was created (https://www.mercurial-scm.org/wiki/Bookmarks).

It can be seen as a downside that there are two branching options that you have to choose between.

Re: Is Git Irreplaceable? (2019)

#342

Post by brachi »

kccqzy wrote: post #152
comex wrote: post #48

Git's biggest flaw is that it doesn't scale. If a new system can fix that without sacrificing any of Git's benefits, I think it can topple Git. It's ironic that Git was popularized in the same era as monorepos, yet Git is a poor fit for monorepos. There have been some attempts to work around this. Google's `repo` command is a wrapper around Git that treats a set of smaller repos like one big one, but it's a (very) le…

Mercurial is probably that competitor. Only slightly slower than Git. Works on very large monorepos (as large as Facebook's or Google's monorepo). Very similar workflow as compared to Git, with some minor differences in terminology.

> Only slightly slower than Git

That's interesting. In your examples isn't it fast because monorepos are network-based, as in, you only fetch what you need when you need it?

Also reminded me of discussions around CPython's startup time and how one use case where milliseconds matter is in small cli utilities such as Mercurial.

Re: Is Git Irreplaceable? (2019)

#343

Post by baud147258 »

mschaef wrote: post #322
baud147258 wrote: post #294

Earlier quoted context omitted.

If its interface is not simple and elegant, I don't see how you can call git simple and elegant, since it's how all users will interact through the interface. And personally I prefer a VCS with less ways to shoot myself in the foot than git.

> If its interface is not simple and elegant, I don't see how you can call git simple and elegant, since it's how all users will interact through the interface. At least in my experience, the interface makes a lot more sense if you understand the underlying data structure, which does have a certain elegant simplicity. (Even if it doesn't work quite the same as traditional source code control systems. Failing to work…

>the interface makes a lot more sense if you understand the underlying data structure

Except that I don't have to understand the underlying data structure to use a more basic VCS like Mercurial. What makes git so special that I would have to do that before being able to use it?

And for recovery from mistakes, I meant stashing the changes somewhere, deleting the repository and downloading a clean copy to start again, which I had to do a few times with Git and never with Mercurial (I might had to do it once or twice with SVN, though).

Re: Is Git Irreplaceable? (2019)

#344

Post by ldiracdelta »

baud147258 wrote: post #343
mschaef wrote: post #322

Earlier quoted context omitted.

> If its interface is not simple and elegant, I don't see how you can call git simple and elegant, since it's how all users will interact through the interface. At least in my experience, the interface makes a lot more sense if you understand the underlying data structure, which does have a certain elegant simplicity. (Even if it doesn't work quite the same as traditional source code control systems. Failing to work…

>the interface makes a lot more sense if you understand the underlying data structure Except that I don't have to understand the underlying data structure to use a more basic VCS like Mercurial. What makes git so special that I would have to do that before being able to use it? And for recovery from mistakes, I meant stashing the changes somewhere, deleting the repository and downloading a clean copy to start again,…

You also don't have to understand the underlying structure for a similarly powerful DVCS like bitkeeper. Yes, it isn't open source, but git was a major step back in usability for my group from bk to git.

Re: Is Git Irreplaceable? (2019)

#345

Post by ivanbakel »

adrianmsmith wrote: post #339
saurik wrote: post #279

Earlier quoted context omitted.

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 we…

You can set up custom merge drivers for different file types.

More importantly, if you've got stuff in your decentralised repo that shouldn't be decentralised, that's not the fault of the DVCS you're using, it's your fault. That everything looks like a nail does not speak against the value of a hammer.

Re: Is Git Irreplaceable? (2019)

#346

Post by quadrifoliate »

I find it amusing that the author mentions Git and Excel in the same breath. One is a GPLv2 piece of software that you can submit patches to, fork, or build your own copy and sell it (so long as you release the source); while the other is a closed-source piece of software that provides largely static utility to many people, yet keeps increasing in price (latest is ~$100/year for an "Office 365" subscription if I remember correctly).

Imagine if you had to pay $100/year to use Git. I would probably hand it over, begrudgingly. But the fact that I don't is probably one of the more important triumphs of Free Software over proprietary in recent years.

Re: Is Git Irreplaceable? (2019)

#347

Post by coldpie »

rkangel wrote: post #341
coldpie wrote: post #331

Earlier quoted context omitted.

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 _e…

Mercurial does absolutely not require you copying at the fs level. You're not the first person to be caught out by that tutorial, which I think would serve us best by being deleted. The 'original' branching method for Mercurial is called Named Branches. The big difference with Git is that every commit is labelled with what branch it is on. This has advantages - if you imagine looking at the train track of 'master' in…

It's not just that tutorial, see also [1,2]. I think this is/was really an "official" way to do branching, and it seems utter madness to me :)

[1] Sadly the popular hginit.com seems dead, this was my first introduction to Mercurial. https://web.archive.org/web/20180722012242/http://hginit.com...

[2] https://stevelosh.com/blog/2009/08/a-guide-to-branching-in-m...

Re: Is Git Irreplaceable? (2019)

#348

Post by baud147258 »

coldpie wrote: post #326
mschaef wrote: post #322

Earlier quoted context omitted.

> If its interface is not simple and elegant, I don't see how you can call git simple and elegant, since it's how all users will interact through the interface. At least in my experience, the interface makes a lot more sense if you understand the underlying data structure, which does have a certain elegant simplicity. (Even if it doesn't work quite the same as traditional source code control systems. Failing to work…

> At least in my experience, the interface makes a lot more sense if you understand the underlying data structure, which does have a certain elegant simplicity. Yeah. Take an afternoon to read through gittutorial(7), gittutorial-2(7), and gitcore-tutorial(7). Git is a tool, and just like any other tool (car, tablesaw), you will be much better off if you take the time to learn to use it properly. Once you see "The Mat…

The fact that you put Git in the same category as tools having a potential of inflicting grievous bodily harm if misused is telling. And why does Git require this whereas other VCS don't? Mercurial was incredibly easy to use nearly right out of the gate, not after an afternoon of work.

Re: Is Git Irreplaceable? (2019)

#349

Post by jerf »

_ZeD_ wrote: post #133
jerf wrote: post #60

Earlier quoted context omitted.

Speaking personally, definitely no. Even before I heard of git, I did not like SVN. In particular, it made an error I don't hear many other people mention where directories were checked out to revisions, rather than entire repositories. Consequently it was very easy to accidentally update just a subset of your repository, and have your whole repository in a state that didn't exist in the version control system at all…

>>> [SVN] made an error I don't hear many other people mention where directories were checked out to revisions, rather than entire repositories. that is a feature! You don't know how I miss that! (that, and the handling of blobs)

I would check, double-check, and triple check whatever use case you miss that for. It is a serious misfeature, and I find any workflow that critically depends on it to be very likely a process smell.

Handling of blobs I can at least see preferring the differences, though git-lfs mostly acceptably shims that for me. The need to use git-lfs is definitely an annoyance, but it's another place where it's probably not a fatal flaw.

Or, to the extent that it arguably is, it would be when you're using git as something that it really, really isn't... it's a source code management tool. It's a good enough source code management tool that it's useful for many other things as well, like the way some people directly drive their personal websites with it. But it isn't a tool for managing lots of large files that can't be textually diffed, not a generic "content" management tool. I wouldn't expect git to necessarily store terabytes of video files, but then, it's not like Fossil is going to do that either from the sounds of it. git-lfs shims content blobs well enough to make it just an annoyance for source code management.

Re: Is Git Irreplaceable? (2019)

#350

Post by jerf »

bhaak wrote: post #284
jerf wrote: post #60

Earlier quoted context omitted.

Speaking personally, definitely no. Even before I heard of git, I did not like SVN. In particular, it made an error I don't hear many other people mention where directories were checked out to revisions, rather than entire repositories. Consequently it was very easy to accidentally update just a subset of your repository, and have your whole repository in a state that didn't exist in the version control system at all…

None of the other big VCS had fatal flaws. If they had fatal flaws, they wouldn't have been used. Sure, not being able to rename a file easily in CVS was quite an annoyance but nothing that made it completely useless. There were always workarounds. But exactly those areas were workarounds or better tooling patches over stuff Git doesn't do are the areas that a possible successor will address.

"None of the other big VCS had fatal flaws. If they had fatal flaws, they wouldn't have been used."

That's just quibbling about definitions in fuzzy English. If you want to insist they weren't "fatally flawed" at the time, fine, but they certainly are relative to 2020 even by your definition.

Post reply on HN