Once you start adding more than one developer to a Mercurial repo you need to know how Mercurial works, so I don't see how this is much different. In fact adding remotes to Mercurial was a much harder process last time I used it.

The point is, Mercurial is much easier learn. We are a team of 20 developers distributed across globe that transitioned from SVN and it was easy for us to pick up Mercurial and start using it within a couple of days.

We tried git too and lost our changes inevitably. Our git knowledge is to be blamed but blame git CLI too! It is not easy to learn at all. After 12 years of git, I see articles with tips and guides on using git. That kind of hints how esoteric git CLI can be.

I feel like most of the trouble developers have with Git is pretty shallow, and it's a shame. It's not a tool I would want to get non-programmers to use (which may be a problem if you've got design folks on your team as well), but the model should be pretty learnable (in principle) to anyone who can manage to hobble their way through an intro data structures course.

For folks like me, who spent their evenings in high-school screwing around with obscure linux distros and have been scouring badly written man pages trying to fix their computer for half their life, the little stuff is forgivable, and a lot of the big stuff is pretty good. But it's a shame how many inessential hurdles there are. See also:

https://git-man-page-generator.lokaltog.net/

Biggest piece of advice for not losing data: learn about git-reflog and git-reset before doing anything that modifies history. Nothing is destroyed, even by "scary" operations like rebase, so it's always possible to recover something, but you need to know how to find stuff.

I do some contract work for a university, where we have lots of student interns going through. We use GitHub, and we rarely rebase or cherry-pick, basically because while I could spend a bunch of time trying to teach git to new interns that will be gone in 4 months, It seems like a more efficient use of time to just occasionally put up with a messy history.

SmartGit is extremely useful, i'd recommend something like that instead of using the CLI if you have trouble.

"The mental model for Git is needlessly complex and consequently distracts attention from software under development. A user of Git needs to keep all of the following in mind:

    The working directory
    The "index" or staging area
    The local head
    The local copy of the remote head
    The actual remote head 

Git contains commands (or options on commands) for moving and comparing content between all of these locations.

In contrast, Fossil users only need to think about their working directory and the check-in they are working on. That is 60% less distraction."

I don't think about any of this when developing. I check out a branch, work on it, commit to it, and push it back up. If the fix is larger than a few commits i'll make a feature branch. What's so hard about that?

Also, everyone using git isn't a bad thing. It means we finally have at least one standard in development.

You get git. Good for you. A lot of smart people get git. A lot of smart people don't. I'm a smart person. I use git every day, 7 days a week. On my side projects, it's fine. Never a problem. At work, the workflow is more complicated, due to many branches, and many submodules. Submodules are a pain in practice. I think the mental model is too complex. This manifests as frequent unintended results, from simple operations that in my mind need not have unintended consequences. I never had any such problem with Perforce, even though I have used git twice as long. Your mileage obviously varies.

I can run circles around most of my fellow developers working with Git. I know how to recover from almost anything I do with Git. However, I put in a lot of hours to get there. I have nothing but distaste for Git's command line. It's an abomination. The command line flags are inconsistent and require real work to commit the right combinations to memory. Anyone, whose solution to this is "You are an idiot for getting confused by this confusing UI" is just flat out wrong. There are better UI's that are less confusing with the same featureset as Git. Git won not because it was that much better than the others. It won because the Linux kernel uses it.

Right now today, there are developers out there who are putting in the work to learn git. They are smart and dedicated to their craft. They are also losing work because git makes it easy to shoot yourself in the foot and because it doesn't easily surface to you how to recover when you do so. It's not because the developer is an "idiot". It's because git's UI is user hostile and does a poor job of reflecting the core concepts in operation when the user is using it.

To be fair to Git they've put a lot of effort in fixing this. It used to far worse than it is now. But due to backwards compatibility and other concerns there is still a lot confusing and unintelligible options out there and that is even after you get the whole concept of a DAG and the index vs working tree.

>Example?

Most people can get the quickie commands down pretty fast, and as long as there are no complaints or errors, it's all OK. But as soon as you need something that takes several steps, your average git user falls apart. Rebases are the most common example. If you don't block force commits from the get-go on a project used by more than two devs, you'll learn that you need to do that pretty quick.

Exactly. Many users get confused and a quick look at the man page shows them a magic --force command that seems to do what they want. Not to mention that we sometimes encourage the use of --force sometimes when we are doing pull requests since we want them to push a squash of all the different commits. It's like a tragedy of the commons playing out in multiple dev teams the world over and it didn't have to be that way. The problem is no one took the time to devote some UX to the git command line until it was too late.

- https://stackoverflow.com/questions/10099258/how-can-i-recov...

- https://stackoverflow.com/questions/10099258/how-can-i-recov...

- https://www.clearlyagileinc.com/blog/recovering-commits-from...

Everyone of these is an example of the git UI/UX confusing you about what is happening. Reflog allows you to recover if you know about it but if you don't you will feel betrayed by the tooling. Blaming the developers for not knowing what Git was going to do is ignoring git's bad ui/ux decisions. Mercurial for instance doesn't have this problem. In fact it tells you whenever you do something that might lose data that it made a backup and where it put the backup at. Everything the developer needs to know right there after they accidentally shot themselves in the foot trying to do their job.

     Other SCM's had years worth of developer training and interaction with their systems and STILL lost. Years of worth sales connections, demos, networking, you name it and STILL lost.

You are comparing Git to high cost options like Perforce which lost because they were expensive and OpenSource doesn't like expensive proprietary solutions in a field where OpenSource rules. I'm talking about solutions like mercurial which have a similar underlying model and a better user experience out of the gate. Git beat hg not because it was better architecturally. They have the same underlying datamodel. It won because the linux kernel used it and that gave it the necessary cachet and authority by association. This is not bad git is worlds better than perforce or cvs or svn in many ways. I'd rather use git than most of those in most situations. But I also would rather use hg than git any day because it's the same datamodel with a ui that doesn't mislead me.

I would like to hear some examples as well. I hate losing my work.

Please don't be that guy. You saw people having issues with git. Have you tried explaining why they ran into those problems and tried to find out where the misunderstanding came from? It's easy to criticise about what you already know. But everybody's experience is different. There's a practical issue with mapping every command to each copy of the dag, that people sometimes don't get.

If you haven't learned about urbit yet, you could try that for the same "I don't know what you're talking about" experience in your life.

This is why some devs shouldn't design UIs, for many people their source control is simply a UI that they want simple with simple workflows. I know people with PhDs who just don't understand git, not because they can't understand DAG, they simply don't want to have to understand it in relation to a tool. The biggest thing with Git is you have to invest time into understanding it, that alone is one of its failings and hence why there is so so so many guides that try to give advice to people who don't really want to understand it.

The difference is that most other SCM's don't actively lose your work while you are learning.

Git doesn't do that. Perforce and TFS definitely will. The very moment I add something to the index it's basically recoverable. I'm not sure what you're really getting at here.

So I'd like you to prove that git won't lose work. Even smart people who use git have typed stuff that made them lose work.

You can, and will, argue they are morons. That's an excellent way to deal with a poorly designed system.

>So I'd like you to prove that git won't lose work.

It does not "actively" lose work. Losing work in Git is a pretty specific operation and generally requires you to spell out what's going on (either via 'reset' or 'checkout'). And also less likely to happen, since you are regularly using the index to stage changes and should be commiting often (since it's cheap to do, unlike trying to commit in BitKeeper, let's say, where locking problems sometime even require to change the window you're committing in [1]). The moment things are in the index/repository, it's pretty unlikely you're going to lose work.

Say, in other systems, me accidentally clicking something is a surefire way to just wipe it out without a second thought. In TFSVC I can easily undo my active changes with a simple click of a button. Again, the contention was that you actively lose work while working with git. It's hard to do, as deleting work in git requires some fairly specific commands.

Even removing a file requires you to stage the deletion, then commit it. And even THEN, even if you amend some other previous commit with that deletion you can role the entire thing back with reflog and get your file back. If I took that amended commit and rebased onto another branch, rolled that all into one commit via squashing, I'd still be able to go back to where I was with the reflog.

If however, you edit some lines in a file and then tell git to checkout that file again and they're not staged, then sure, you're going to lose work. But that's not something that's common and it certainly isn't a recipe for having git "actively" delete work.

[1] http://www.bitkeeper.org/man/citool.html

> If the repository is locked, and you try to bk commit, the commit will fail. You can wait for the lock to go away and then try the commit again; it should succeed. If the lock is an invalid one (left over from an old remote update), then you can switch to another window and unlock the repository. After it is unlocked, the commit should work.

If you want correctness then you lock the repo when you are updating it. We do that and make it work on NFS, which is not that easy to do.

If you want to live in a world where two people can be wacking the repo at the same time with undefined results, be my guest, you seem like that sort of person. We are not. We like atomic commits.

As for BK being expensive compared to Git, you are so right. 10 years ago. These days we do quite well and we do it correctly.

I dunno why you have a hardon to smear BK, but bring it dude, I'm happy to make you look foolish.

This is fine when you're working on your own project.

However, if you want to send a patch to someone else's project on Github, you have to create a remote fork, download the fork, and push it to your remote fork, then send the pull request. (I have tried other ways but they don't seem to work.)

This is fairly annoying since it's extra steps and it clutters many people's Github accounts with forked versions of projects they contribute to. There's no good reason for these forks to exist.

But this is a problem with Github and not git itself.

On the other hand, do you really want random people on the internet to be able to inject objects into your git repository by creating a branch or whatever? Especially after SHAttered, that's a huge liability that sort-of justifies the "you take yours and go over there" approach.

Of course not. You want to send them a patch and have it show up in their "inbox" on Github as a pull request. There's no reason to put pull requests into the git repo.

I feel like everyone using git is like everyone using C.

Fortunately for us C programmers then that not everyone has come to their senses.

I normally use git commit -a. I use git diff to preview my commit. However, recently I had to git add a file. After that, git diff didn't show the file, even though git commit did include it in the commit.

So, it doesn't take long to realise that you need to understand the index after all. You need to learn git add -N, or use "git diff HEAD" instead of git diff.

A majority of VCS users don't use them in a write-only way.

This is the original https://www.youtube.com/watch?v=5pFX2P7JLwA

Can't you just use a tablet and DRAW the graph like it was hand-made?

I don't understand...

For the same reason no one hand-codes the HTML on each individual Hacker News thread?

Writing code makes repetitive tasks easier: if you want to pump out hundreds or thousands or millions of variations on a graph (using different data, etc...) then drawing it by hand is infeasible.

What if the data changes every day?

ie: plotting the number of bugs fixed over time