Hacker News Reader

Comment by bsder | Hacker News Reader

> Git has won the vast majority of mindshare and good will by being straightforward, ubiquitous, and well supported.

Thanks for a good laugh. The sheer volume of "No the REALLY right way to think about git's totally brain damaged use of source control concepts. This time we mean it." tutorials shows that "ubiquitous" is true but "straightforward" and "well supported" are a lie.

But you are correct. The vast majority of coders have decided on git. I will happily sit over here on Mercurial while you try to figure out the arcane git command for something that I was done with in Mercurial hours ago.

The Mercurial->git gateways are now quite good and I can do my development in Mercurial and transfer it to git at infrequent intervals. It's not like git people want to see all my intermediate commits anyway--that's the whole point of "rebase" after all.

View on HN

> while you try to figure out the arcane git command for something that I was done with in Mercurial hours ago

I sense a lot of resentment in this statement, but to be honest I have no idea what people are talking about when it comes to their gripes against Git. Little goes wrong, and when anything does, fixing it is a reflog or a reset away. I could understand being frustrated trying to jump right into it, especially with the interface as of the mid-late oughts, but it's fairly straightforward these days. The defaults make sense, and the built-in tools are consistent and plentiful. I doubt I could compose a correct filter-branch from memory, but I don't even think I could find an example for Mercurial, and I doubt the manpage would be as helpful.

> but to be honest I have no idea what people are talking about when it comes to their gripes against Git. Little goes wrong, and when anything does, fixing it is a reflog or a reset away.

I will be happy to call you the next time one of my devs does something that causes git to wedge itself into one of those states. It happens about every 2 weeks--and I suspect that it happens more frequently than that.

Normally I can unwedge git after reading approximately 10 git pages all claiming to fix my problem (they don't but they probably point me at the brain-damaged command I need). Most of the time ... about once every 3 months everything fails and we have to pull a backup.

Fortunately, the devs have now been brainwashed to rsync the repository on at least a daily basis and always before they do anything besides a basic checkout or commit. But, hey, they're using git, and it's what everybody else uses.

As someone who uses Mercurial and does some pretty hairy stuff with it, I have never put the system into a wedged state. NEVER. The only time I saw a Mercurial repo get wedged was when the underlying filesystem barfed on itself.

Yeah, I'm a touch sore about this because I regularly get to fix problems that WOULD NOT EXIST if the team was in Mercurial instead of git. However, as a manager who likes to think of himself as "good", I cannot force tools on a team unless they actually do measurable damage.

I also get sore with the "Well, if you only understood the git model..." I DO understand the git model--much to my horror. The problem is that while a newbie can learn the Mercurial model in about 60 seconds and be productive the git model takes about 60 months to learn and they will still regularly footgun themselves.

So you've repeated your assertion that "people break git" and that fixing it "is hard".

It seems surprising that so many people, familiar with daily use, manage to keep breaking things in your environment, but others here don't.

Have you written bug reports? Or documented the nature of these broken states?

90% of the git users probably just run a handful of commands. ("git status", "git add", "git diff", "git commit", and creating/merging branches). Those commands seem unlikely to cause widespread problems, but perhaps you're doing something else?

Just out of curiosity, which states do your developers put git in? I’ve worked with people that were learning git and the worst they’ve done is committing files with conflicts after a merge or putting in files that should be ignored. Oh, and one guy who force pushed to a repo and made the CI system refuse to pull the changes until I reset the repo there.

> fixing it is a reflog or a reset away

Only for people who have internalized what GP called "git's totally brain damaged use of source control concepts." When you don't understand the structure of the underlying database that Git uses, the error messages that Git returns might as well be in Greek for all the help they provide. Mercurial has mostly the same concepts as Git but the developers have taken the time to translate the error messages that are returned to users into words that actually explain what the problem is and how you might go about fixing it.

In my experience with Git, there's two ways to be productive with it. The first is to go read Git source code and basically understand exactly how each command you issue is changing the data in your repository. I eventually resorted to this strategy the umpteenth time that I managed to get my repo into some bizarre state that I'd never seen before. The other solution is to ensure that the entire team sticks to a very precise subset of what Git provides and be pretty militant about limiting everyone to those blessed incantations. Git flow is pretty useful for this since adherence to the steps generally keeps a Git repo in working order. I generally try to follow this second strategy since following the first means that you become the "Git guy" at work that everyone turns to when they've managed to get in over their heads.

Also, mostly unrelated, but when I work in Git, I miss hg serve. Being able to pull changes from/to colleagues using zeroconf without needing to set them up as a remote was really useful. I know Git has instaweb, but it's an incomplete solution and just another example of where using Git just has a lot more friction than the more pleasant hg experience.

> When you don't understand the structure of the underlying database that Git uses

For me this is totally exactly true for Mercurial. I find git's underlying model way easier to understand. Mercurial with its 3 different branching representations (branches, bookmarks, patch queues..) and "state tracking" is really quite a bit more complicated and I do not find it is easier to internalize; quite the opposite, as a git user I have found it extremely difficult to contribute to hg-based projects for this reason. For me, git is just a tree and pointers to nodes on that tree. I find it hard to see how it is difficult to understand.

Branches are, well branches, bookmarks are pointers, and patch queues are quilt integrated into Mercurial, and not something you need to worry about anyway. And if you need to, it's just a staging environment for commits before you publish them to the immutable branch.

I have now, for 3 teams, migrated them to Mercurial from Git, and all now have zero issues with their DVCS. Every now and then, they would write and ask for help with some issue with Git they need solved.

It seems as the average developer do not want to learn the intricate workings of Git to properly use it, and just want a tool that does what you think it will, and will not shoot them in the foot if they issue the wrong command.

My point is that you can make the exact same argument in the other direction, so that argument is pointless. Hg users seem to take it as granted that it's so much easier to use and understand but I simply don't find it so. It is not an objective point of view.

Case in point,

> Branches are, well branches, bookmarks are pointers,

you say this as if it is obvious and means something. As a git user, "pointers" are branches, and "branches are branches" means nothing at all. Contrary to claims of Hg users, to understand how branches work I need to spend some time understanding the internal representation of branches and experimenting with toy local and remote repositories to make sure I don't step on my own foot in a real project. Just like I did when I was learning git. The claim that it is somehow more natural and requires less learning is unfounded imho.

> just want a tool that does what you think it will, and will not shoot them in the foot if they issue the wrong command.

I'm sure I'm not the only person who has shot themselves in the foot using Hg. Adding files and changes I didn't intend, pushing them, having to go to the repository site and remove that tip, trying to delete the branch locally to redo things, giving up and re-cloning the repository. These are all learning steps that one goes through using Hg. Just like git.

A whiteboard, draw the commits as blobs and draw arrows between nodes and parents. That is all there is to it. You need to do this for Git as well. This is not an argument for or against. But calling Mercurial branching model confusing compared to Git is dishonest IMO.

The major deciding point between the two is that Mercurial see history as an immutable truth. Git does not, and actively encourage changing it. This is also the reason behind Mercurial "push/pull it all", and Git "push/pull what I say". I believe this is the major point of conflict between the two camps. Once you master Git, you get a tool. Mercurial actively discourage this history rewriting, and many from the Git camp get frustrated that they can no longer easily manipulate what is in the repository.

If all you ever do it branch, commit, and merge, then either are fine. If you want ability to modify history, use Git. If you explicitly do not want to modify history, Mercurial is the better choice. And this is the crux of my point of view. If you modify history in either system, you may end up shooting yourself in the foot. But it's significantly harder to do in Mercurial, exactly because the system encourage not doing it.

> The major deciding point between the two is that Mercurial see history as an immutable truth.

That view is quite outdated[1]. It's true for _published_ history though, but that's it. Couldn't help but note Mercurial did it right, _again_ :)

1: https://www.mercurial-scm.org/doc/evolution/

I was only talking about commits in a publishing repository. What happens on a developers machine, and between developers as draft changesets is quite a different story. We use that a lot and I really like it. Git has the concept of remote removing commits and garbage collection.

I guess you haven't read the link posted. Changeset evolution is not about draft commits that a developer changes locally. It's about actually changing the public, pushed history in a way that nothing breaks for other developers who already based commits on those that get altered.

Um, that's not quite true: https://www.mercurial-scm.org/doc/evolution/sharing.html#pub...

The limits imposed by phase are not going anywhere; you still cannot edit published history.

Publishing repository by definition contains public changesets. You cannot alter history for them without force. Again, what happens on and between developers can and should be trimmed before it's pushed to the publishing repository.

It's easy to understand, I just don't get why do I need it for anything but Git development. I mean I was perfectly able to be productive with Mercurial without the single shred of knowledge of it's internals. True, I've learned them anyway, but because I _wanted_ to, not because I've _had_ to in order to be able to do anything beyond these 5 commands mentioned in every git tutorial or understand what git output actually means. And, oh, these internals actually are leaking abstractions, multiple episodes. "You had one job" ©

> It's easy to understand, I just don't get why do I need it for anything but Git development.

I dunno man.. I don't particularly want to implement a macro language compiler these days, but it sure helps to understand how one works when working with the C preprocessor. (Just a dumb example..)

I mean, are you actually arguing that it should be unnecessary to understand the underlying models that your tools use to do what they do?

> When you don't understand the structure of the underlying database that Git uses,...

The directed acyclic graph of commit objects, their associated trees and blobs? After all these years and git tutorials, you would have to be trying really hard to avoid coming across an easy git intro. If someone is a developer, I'd say it's past time to learn it.

Congratulations. You just hit the nail on the head.

"Developer"

Source control should be usable by people other than developers.

And, to be blunt, if the end user has to be a developer to understand a source control system, the source control system is the problem--not the end user.

> Source control should be usable by people other than developers.

Sure, but does that mean that git needs to be usable by everybody? I don't see how that follows. There are plenty of source control tools, they range in ease of use from beginner to advanced. Git was developed to be a source control system for software developers. If you try to shoehorn it into every use case, how are you going to make anyone happy?

The directed acyclic graph is fine.

But that is not really the structure once we start having more than one git repository interacting with remotes. And then there is the staging area and the stash. Tracked untracked and ignored files. There's just a lot of state, and a lot of duplication, where the same result can be achieved in various ways.

Git is a disaster for version control. It excels for one particular use case, and user type. Because of this it has become ubiquitous, and now we need to teach it to everyone.

Part of my work is getting scientists to use version control. I kid you not, there are many here who follow the advice: Before you try to put it into git, make a backup.

And that's sane. Because who the hell knows what will happen once you push the commit and then some changes are merged in, or even worse, the merge fails, etc...

The unwillingness of a large number of HN commentators to see the weaknesses of git is astonishing to me.

> Part of my work is getting scientists to use version control. I kid you not, there are many here who follow the advice: Before you try to put it into git, make a backup.

I know some that won't delete code. If they need to change something, they leave the previous code commented out. They don't merge, either. All changes are manually applied to every branch. They don't trust SVN, despite having used it for years.

I don't know why you think it would be better with hg. You can lead a horse to water, but you can't make him drink.

> The directed acyclic graph is fine.

> But that is not really the structure once we start having....

Well, yes, the DAG of commits with trees and blobs attached to them is still the structure of the underlying database, which is what you were originally talking about. But OK, you want to talk about the complexity that arises from git being distributed and having a staging area. That's totally valid, and it's what simplified wrappers like gitless are here to solve. Maybe try those?

> Git is a disaster for version control. It excels for one particular use case, and user type.

So, because git is excellent at its intended use case, it is a disaster for version control in general? OK...

> Part of my work is getting scientists to use version control.

Well, maybe your scientists should be using some other version control tool if they are having so much difficulty with git?

I am a big fan of gitless. It shows how things could be better with the same underlying structure.

But the standard git interface can not realistically be avoided either. Whether IntelliJ or Atom git plug in, they are all closely modelled on the git commands.

We also have a considerable number of people working on Windows.

The disaster is that because the open source community has entirely embraced git, git is no longer optional. We could try to teach people two tools (pushing git off until later), and it's something we have considered, but that has obvious downsides, too.

It's still something we will investigate, but we are in an extremely resource strapped environment. Time, IT staff, etc...

On a technical note, a single DAG that you append commits to is vastly different from a number of DAGs (technically a directed acyclic forest) that interact in non-trivial ways. So no, the DAG is not the underlying database, it is just a part of it.

Failing to make this distinction is how we end up with millions of tutorials explaining the easy part, and plenty of smart users that still end up with messed up repos.

Yes, the distributed part is hard to wrap your head around. But IMHO, hiding it is even worse because you'll always be wondering what exactly is going on. Whereas with git you just check the status and the current DAG to figure out where you are.

But it's not so easy to just check the status of the repo I am pushing and pulling from. Is there a UI that will show me side by side the two DAGs that are being coordinated through push/pull?

https://magit.vc/

Decided or followed the crowd, absolute most of them probably would defend their choice with teeth and nails (seen that lots of times).

Reply on news.ycombinator.com