Mozilla Firefox Development Finally Moving Entirely To Git

[microcode]

Too bad for them. Mercurial is far superior.

Is it really "far" superior? I mean... I understand liking it but it's not really different enough to be "far superior" lol.

[rogerx]

Significantly easier to understand interface. Doing anything in git is typing in dark magic voodoo incantations. Mercurial is much simpler to grasp. Though I'd say git is more powerful. But unleashing that power, as I said, dark magic voodoo.

Ditto. As many others have stated, I too have used CVS/SVN etc... and my efforts for understanding git is usually greeted with failure after failure, and continually after many years. Even after reading many Git books. Again, as another have stated, I too keep copies of my repositories in the event of git merge failures. Simply delete and start again, rather than wasting time resolving conflicts.

I wouldn't say the problem or failing command line incantations are solved with voodoo magic, more specifically, the developer or developers seemingly have a warped perception of what is easy within reality. As if they were under the influence of psychotropic drugs or have had significant head injuries. Designing a tool for easy user intuitiveness is extremely desirable, however requires a little bit of thinking before software coding. There's an entire books written concerning proper coding, Practice of Programming, Kerningham; the beginning of the book is a must read. Fundamentally with git, just design something so stupid people can use the tool within one or two executions!

There is one rational for designing a confusing tool... for selling more books instructing usage of the software tool! Plenty of Git books nowadays, however none make Git any easier!

[skierpage]

I wouldn't say the problem or failing command line incantations are solved with voodoo magic, more specifically, the developer or developers seemingly have a warped perception of what is easy within reality. ...
<then some Innacurate insulting ranting>

git exposes an intentionally complex set of features that solve the fundamentally complex problem of distributed version control of multiple overlapping series of commits. I won't pretend to understand, for example, the subtle differences between the working tree, the index, HEAD, and the current files in the directory tree, but I trust that Linus had reasons for it and knew what he was doing when he exposed the differences in commands like `git reset`. Wishing for something simpler is wishing for a tool that does less; it's not going to happen. It's easy to wish for a simpler git subset that doesn't allow you to shoot your foot off, and it's probably possible if you're the only developer working on a local file system, but the moment the "distributed" in DVCS appears, other developers can upset your simple linear history, and I don't see how you make the tool simpler.

When I maintained a long-lived branch to add a big new feature to a rapidly evolving project, I needed a lot of help, and two senior developers told me they didn't really understand git until they read its source code. !!! The rest of us just have to cast around for "voodoo incantations" that match what we're trying to achieve, and slowly over time it gets clearer.

[dlq84]

GIT is BAD, Microsoft OWNS IT

Why do people confuse GitHub with git? They are two different things...

[Termy]

I actually disagree. I think it might be true for somebody who worked with cvs and svn before. (And maybe some other tools)

Personally, I only really started with git, when it came up, around 2008 and I never had big issues with its usability. On the other hand, I found svn to be very complicated

I agree - i also had my first VCS-contact with git and found svn to be very annoying. Can't speak for hg though.

But i really don't get why people have trouble with git's staging, cloning, merging. Sure, once you manually fiddle around with HEAD or multiple remotes and the like, it can get more involved. But the basic functions are pretty straight forward imho. And i'm far from a "seasoned developer".

[skierpage]

Should of moved to jj smh (sarcasm obviously) but it is an interesting project! https://github.com/martinvonz/jj

*should have

Thanks for the pointer, jujutsu is really interesting, thanks. As a counterpoint to what I wrote above, it drops git's distinction between "index" and "staging area" and has interesting ideas about each save as a commit, treating conflicts as managed objects, automatically rebasing when previous commits are modified, etc. But is it conceptually simpler than git and easier in all situations? hmmm...

Its Related work page is excellent, covering several other DVCS projects.

[back2未來]

they could keep (~at least) a read-only, most current main repository on mercurial, being updated from git main repository (for to keep testing work flow for mercurial users), being automated that should not be a noticeable difficulty or demand (while repository reading from servers would be on distributed systems/organizations/maintenance/licenses)

Why do people confuse GitHub with git? They are two different things...

maybe, bcse it's an equal command 'git' from command shell for accessing it (while one is attached to Microsoft (~94M users), git is maintained on GNU GPLv2 license, gitlab MIT license commercial&community based (~32M users), gitee ~5M users 'Chinese github' version, openhub, bitbucket (~5M users), Launchpad (~3.9M users), mercurial or svn, SourceForge (~3.7M users), GNU Savannah (~100k), etc.)

svn

AFAIR, big advantage from shell console with svn ('export') is accessing single files without fetching/cloning a whole repository (?)

[dlq84]

maybe, bcse it's an equal command 'git' from command shell for accessing it (while one is attached to Microsoft (~83M users), git is maintained on GNU GPLv2 license, gitlab MIT license commercial&community based, gitee ~5M users 'Chinese github' version, openhub, bitbucket, mercurial or svn, etc.)

I mean, Github is a host for git repos, of course you're going to use the git command, what else would you use?... The same way all browsers are using HTTP doesn't mean google owns HTTP just because it's the biggest browser by marked share MS doesn't own git just because Github has the most amount of users. The confusion still doesn't make sense to me.

[back2未來]

I mean, Github is a host for git repos, of course you're going to use the git command, what else would you use?... The same way all browsers are using HTTP doesn't mean google owns HTTP just because it's the biggest browser by marked share MS doesn't own git just because Github has the most amount of users. The confusion still doesn't make sense to me.

from one other POV: Github (Inc.) and git-scm (no number for users/devs found, yet, edit: for 2014 numbers there's a ~43% to 33% preference for professional developers for git-scm compared to Github_2014 (~10M reg. user accounts) ) confusion happens with a reduced labeling like 'git' (protocol) server (previously mentioned .com#s are probably the most famous for open source developers (~2023), preference depending on OS dependencies for Windows or Linux systems and flavor/interest on license and corporate philosophies with ~comparable access commands/tools )

[orzel]

(...) but I trust that Linus had reasons for it and knew what he was doing when he exposed the differences in commands like `git reset`. Wishing for something simpler is wishing for a tool that does less;

That's what most people that like git think. I'd like to put it without offense, but words don't come easily (i'm not native):

It's a mix between 'devotion' (gods know, i trust them), and the common feeling that hard-to-use tools are probably very powerful. Some people are kinda proud of using a complicated tool, that makes them feel superior. You know, the common adage that drugs SHOULD taste bad to be efficient. And it raises the barrier for newcomers, it 'protects' their reputation/jobs/whatever.

imho, source control should not get in my way. Mercurial was out of my way after several minutes of using/testing. Git still keeps hurting me.

it's not going to happen. It's easy to wish for a simpler git subset that doesn't allow you to shoot your foot off, and (...)

It already happened, it's called mercurial and it's not a subset, it's not less powerful. Yes, dvcs is a rather complicated concept, but the tool doesn't need to make it even more complex.
Some mentionned mercurial could sometimes be slow. I've never felt that. It happened long ago, at the beginning (both for hg/git), but it's been fixed, for both. I manage some repositories the same size of the kernel and it's ok. But i dont use such big repositories in git to make a fair comparison, tbh.