Hacker News new | past | comments | ask | show | jobs | submit login

To be fair git is junk; it's just the standard so everyone has mostly learned it and it gets the job done, but at least Mercurial is better. Probably bzr too. I have probably 5 more years experience with it than Mercurial and I'm still googling for the correct incantation for things that are just infrequent enough for me to commit them to memory. With Mercurial, the command is what you would expect 90% of the time.



I remember when dvcs really started taking off, I went with bzr because of the simplicity of the UI. I was also on Windows at the time (wow, that was a while ago!), and git didn't have native windows support back then while bzr did. I still much prefer bzr's UI from what I remember of it. It was simple, consistent, and perfectly fine with the occasional typo.

But suddenly "everything" was on git; github was a rocket; bzr just felt slower and slower as my repos grew; launchpad was incredibly confusing; I'd been using git/github for outside projects and finally tried git for one of my own, and then started getting confused between the UIs. I picked the one that had the better trajectory. Also, we (the startup I was with) were starting to hire people and using git was easier than forcing the new people to learn bzr.

Mercurial looks great, and always has. I just never really had an incentive to switch to it.

Edit: Sorry, got lost in my own story. I agree with the siblings here. "junk" is rather strong for something that's so universally used. I don't love git, but it definitely won my support.


I liked your story, and "junk" was definitely hyperbole. Git gets the job done.


Long time user of both bazaar and git here.

> To be fair git is junk;

git's UI could certainly benefit from some simplification ; this doesn't make git junk, especially considering that it's incredibly fast and reliable.

> it's just the standard so everyone has mostly learned it and it gets the job done, but at least Mercurial is better. Probably bzr too.

Bazaar and git actually have lots in common, they both have the advantages of DVCS (which seem to be often confused with "the advantages of git") (like, say, "rename"?)

Here are the main differences I noticed:

Bazaar is definitely slower, but you need an big-open-source-sized repo before noticing the difference.

Bazaar doesn't have "rebase" by default, but you can install it as a plugin and it works.

Bazaar has an optional "automatic push after each commit", which encourages linear history, and which I find to be more appropriate 90% of the time in a small experimented team (small and frequent commits instead of feature-branches).

Bazaar's UI uses revision numbers instead of commit hashes, this makes lots of things easier, like knowing which of two commits came first, telling a commit number to your coworkers, or bisecting without requiring the support from the VCS ( git-bisect ).

Bazaars allows remotely fetching one single revision from a repo, without requiring to download the whole history. You can't do this with git. The best I found was to loop "git fetch --depth N" with an increasing value of N until the "git checkout <commit_number>" succeeds. This is a pain, especially when working with submodules.

Bazaar doesn't have an index (aka "staging area"), and by default, "bzr commit" will commit all the local modifications. Considering that partial commits are dangerous (test suites generally don't track what's in the index, creating a mismatch between "what was tested" and "what's being pushed"), this is a welcomed simplification (of course, you can "git stash/bzr shelve" if needed).

Bazaar doesn't make a difference between a branch, a repo, and a working copy. All of these are repositories (potentially sharing ancestors) accessible through an URL. So there's no need for "remotes", you directly push/pull to/from an URL (no, you don't have to re-specify it each time).

I hope no git user was harmed during the reading of this post :-)


If by "test suites" you mean automatic testing, then I probably don't agree.

The flow goes like this for me:

- Make small amount of new code backed by tests in a feature branch

- Run some tests locally (not all)

- Push to the feature branch

- CI will run all the tests

- If a test fails, I get a notification about it in my IDE and can fix it immediately

I personally enjoy having staging area (and IDE supported local stash) that help me keep small amount of difference to the origin for development purposes.


> Bazaar doesn't have an index (aka "staging area"), and by default, "bzr commit" will commit all the local modifications.

Mercurial works this way too. I strongly prefer Mercurial to git, but I like partial commits and the staging area is one of the few things about git I wish Mercurial had.


> Bazaars allows remotely fetching one single revision from a repo, without requiring to download the whole history. You can't do this with git. The best I found was to loop "git fetch --depth N" with an increasing value of N until the "git checkout <commit_number>" succeeds. This is a pain, especially when working with submodules.

There is also `git clone --depth 1` but you have to use ssh+git protocol


I don't want HEAD, I want a specific commit. How do I specify this from a "git clone" command line, as you're suggesting?


I don't think that's possible. You'd have to `git init`, `git remote add ...`, `git fetch --depth 1 MYREMOTE MYCOMMIT`.

If this is a frequent case for you, you could easily add an alias for this.


$ git init

Initialized empty Git repository in /tmp/phobos/.git/

$ git remote add origin https://github.com/dlang/phobos.git

$ git fetch --depth=1 origin 6e5cdacfa6ac018c6ef42aa9679893676f293f21

error: no such remote ref 6e5cdacfa6ac018c6ef42aa9679893676f293f21

However, the commit exists:

$ git fetch --depth=1000

[... a long time after ...]

$ git checkout 6e5cdacfa6ac018c6ef42aa9679893676f293f21

Note: checking out '6e5cdacfa6ac018c6ef42aa9679893676f293f21'.

[...]

HEAD is now at 6e5cdacf... phobos 0.2


This looks like github configuration. My (probably newer) git tells me:

    $ git fetch --depth=1 origin 6e5cdacfa6ac018c6ef42aa9679893676f293f21
    error: Server does not allow request for unadvertised object 6e5cdacfa6ac018c6ef42aa9679893676f293f21
Note that this works fine and has the same effect:

   $ git fetch --depth=1 origin phobos-0.2
If you want the first command to work, you will probably have to host somewhere other than github.


> This looks like github configuration

This also doesn't work on gitlab.

$ git clone -q --depth=10 https://gitlab.com/fdroid/fdroidclient.git

$ cd fdroidclient

$ git fetch --depth=1 origin 5d2c2bc6e636e40eee80c59d1de6c1eff0ba4472

error: no such remote ref 5d2c2bc6e636e40eee80c59d1de6c1eff0ba4472

$ git fetch -q --depth=200

$ git checkout 5d2c2bc6e636e40eee80c59d1de6c1eff0ba4472

Note: checking out '5d2c2bc6e636e40eee80c59d1de6c1eff0ba4472'.

[...]

HEAD is now at 5d2c2bc... Merge branch 'fix-npe-verifying-perms' into 'master'

Please be honest: did you see it work at least once?

> If you want the first command to work, you will probably have to host somewhere other than github

Please keep in mind that those are generally third party projects. Convincing all the maintainers to move away from github is going to be hard.

It seems we're back to square one.


> Please be honest: did you see it work at least once?

No, I never tried this before. I was just guessing based on the client error message. But a quick look in the source reveals that this is indeed a server setting that defaults to false:

https://git-scm.com/docs/git-config#git-config-uploadpackall...

If fetching non-tagged, non-branchhead commits is actually a frequent use case for you, you could ask github whether they might change their config. You are not the first person to want this: https://github.com/isaacs/github/issues/436

> It seems we're back to square one.

Almost :). You said:

> Bazaars allows remotely fetching one single revision from a repo, without requiring to download the whole history. You can't do this with git.

As it turns out that is not correct – git can absolutely do that. But the two biggest hosters don't allow it.


Extract from the pages you linked:

"However, note that calculating object reachability is computationally expensive. Defaults to false."

"it is off by default and generally advised against on performance reasons."

> > Bazaars allows remotely fetching one single revision from a repo, without requiring to download the whole history. You can't do this with git. > As it turns out that is not correct – git can absolutely do that. But the two biggest hosters don't allow it.

I stand corrected, I should have written instead: "git designs makes this operation so expensive that git disables it by default, which means you can't use it with github and gitlab, and probably the vast majority of git servers in the world, making it unusable in practice".

> you could ask github whether they might change their config.

Yeah, right.


Regarding your fetch issue: you can just specify the Sha/tag/Branch head that you want to fetch


Considering how many people are incredibly productive with Git, calling it junk might be unfair.


People are productive in C too.

C (like git) It's very good at what it was intended for, but everyone and their mother using git on the command line for VCS now is as if everyone had just used C to do every website, game, app etc since 1980.

Git, like C, is a solid core but by now we should have better abstractions to help people be even more productive.


How many people are incredibly productive with git? Or most just kinda productive, as long as an expert isn't too far away from them?


You can become that expert too by reading this tutorial. https://www.sbf5.com/~cduan/technical/git/ It doesn't teach you commands at first because:

> you can only really use Git if you understand how Git works. Merely memorizing which commands you should run at what times will work in the short run, but it’s only a matter of time before you get stuck or, worse, break something.


you shouldn't _need_ to understand how git internally works to use it (and if you did, then it confirms that git isn't good). You should understand the abstract model of DVCS that git presents (just like you'd need to understand the abstract model of a car to drive it).


Understanding the abstract model is exactly what people mean when they say this. It just happens that Git's implementation is incredibly close to the abstract model. This was particularly true in the beginning, before regiments such as pack files were introduced. Those regiments complicate the implementation somewhat, but haven't changed the abstract model at all.


> Git's implementation is incredibly close to the abstract model

which is exactly why a lot of people claim that git is shit. The fact that it "won" makes those people more angry.


Oh well.

OTOH, I'm a kind of guy who just must take everything apart before using it and I like the brutal simplicity of git ;)

The naming of commands could be better, though.


I've never seen anyone complain about Git on the grounds that it _isn't_ full of leaky abstractions.


err, s/regiments/refinements/g. Thank you, autocomplete.


> git isn't good

who cares? git won, you need to use it if you are in this field. Yes, I liked bzr much better, I even liked darcs better but what can you do? git won, good or not. That git sucks is indisputable nonetheless we need to learn it and this tutorial is what made it possible for me to have some peace with git.

Oh and neutering git reset --hard because it's incredibly dumb for a version control system to just throw away shit. Instead, a backup commit is made first (and some other minor goodies): https://gist.github.com/chx/3a694c2a077451e3d446f85546bb9278


> git won,

I really wish people would stop talking about computer tech as "winning" and "losing". I mean, it's slightly better than "X is the new Y Killer from X Corp" bullshit we used to get, but its still ridiculous.

Mercurial, SVN, Darcs etc are all valid tools to use and all are maintained.

> you need to use it if you are in this field.

Wow, cargo culting much?

You should be familiar enough to use it when required, sure.

You don't need to use it if you're starting a new project. My client projects default to Mercurial, and I'll give them help getting up and running with hg if they aren't familiar already.

If you have developers who want to collaborate on your work, who are able to get git to do what they want, but who objecting to using something like Mercurial, you need to question their motives.

They're either not smart enough to actually use git, and instead just memorise commands without any clue what they're doing, OR they are objecting because we all know cool kids use git and they are a cool kid.


1. Git's not "winning" at Facebook: https://code.facebook.com/posts/218678814984400/scaling-merc...

2. Mozilla has also standardized on Mercurial

3. Mercurial’s changeset evolution is awesome: https://www.mercurial-scm.org/doc/evolution/


The implication of which is that git is a leaky abstraction?


https://www.sbf5.com/~cduan/technical/git/ is a treasure! Thank you.


git is not complicated 95% of the time. you really only need to learn a handful of commands and read a blog post or two about branching models and you are good to go.

is there is some set of problems plaguing git users I've just never run in to?


Given that practically every non-beginner git tutorial starts off with "back up your repository", it's quite clear that git gets wedged a lot.

Somehow, I rarely see a Mercurial tutorial give that same advice unless you are doing something really experimental.


If you're writing a non-beginner git tutorial and you feel the need to include advice to "back up your repository" then you haven't done your job. It's incredibly hard to lose data with git - no matter what changes you make, the old commits are still around, because they're immutable. If you lose track of them, there's always "git reflog".

I don't want to pounce on you just because you prefer Mercurial to git, so this isn't really directed at you, but in general this line of argument is always a bit frustrating to me. I've never lost data with git, but I've lost data with Mercurial several times because of the terrible UI of "hg resolve", which throws away your changes without warning unless you remember to type "hg resolve -m". None of git's questionable UI decisions (and there are many) has caused me remotely as much trouble as "hg resolve".


It's way too easy to lose work with git. The easy availability of git reset --hard is a menace. I am using this https://gist.github.com/chx/3a694c2a077451e3d446f85546bb9278 shell script to make it not lose data. And it's a disgrace I need to do this. Disk space is free (within measurement error, especially for 99.99% of codebases) so just put that thing somewhere and if necessary I can use date and pickaxe to dig it up.


I do agree with that; "git reset --hard" should stash the changes in the working copy somewhere. I'm sure you'd agree, though, that backing up your repository is not going to protect you from "git reset --hard" unless what you're really doing is backing up the working copy, and if that's what you're doing, there's a built in feature to do that in git called "git commit". =)


Except that "git commit" isn't sufficient.

You have to use "git add" on a bunch of files that you have used "git add" on before.

As far as I can tell, every other revision control system tracks a file for "commit" once it has had even a single "add". This is the default case and what 99% of people want--"I told you to keep track of the file. Now keep track of it until I tell you otherwise."

git is the only revision control system I know of where I have to "git add" the same file over and over and over and over ... before doing "git commit".

But that is fairly standard git UI practice--"Optimize the 1% case and make the 99% case annoying."


git reflog has the previous refs, git reset --hard does not remove anything that has been committed.

It will however nuke changes that are not committed. Which is exactly what I use it for... But your script sounds like a decent solution if you want also that to be undoable


A revision control system losing data on a bad ctrl+r is, as I mentioned, a menace.


Having to navigate the reflog as a beginner can be overwhelming.


A backup can still be very useful if you perform something non-trivial like e.g. history rewriting. Sure you unlikely lose something but restoring a backup might often be the easier solution to restore the state you started from.


re: hg resolve,

That's like complaining that git threw away your changes because you forgot to commit them before pushing. Yes hg resolve is a little bit confusing the first time you encounter it. But all your losing is the conflict resolution. You didn't lose the two heads that you were trying to merge nor did you lose the conflict markers.

If that's the only place that confused you in hg's interface then it did a way better job than Git in it's user interface.


It's not really similar to forgetting to commit before pushing, but as another poster pointed out it's fair to compare it to "git reset --hard". The difference in my mind is that "hg resolve -m" is part of the workflow you'd use commit the changes in the working copy. It would be like if git threw away your changes if you ran "git commit" with no arguments.


I wished I could back up my repository when I worked with AccuRev or SVN. Knowing with absolute certainty that the worst-case scenario was just reverting to a copy meant that I could try anything in git, even when I barely knew what I was doing. Freedom to experiment without consequences made learning git a much faster process than previous version control systems I'd worked with.


That's too bad for Mercurial. Backing up a repo is just good practice—if you care enough to do version tracking, you should care that you have a backup. I have backups of all of my repos, but I have never once gotten Git into an unusable state.


In Mercurial, you backup in case Mercurial does something it isn't supposed to do and you lose data. With Git, you backup because git is hard to reason about and there's a good chance that the command you're running will put you into a technically-valid state that you don't understand or know how to get out of and you don't want to spend hours Googling git jargon to figure out how to get out of it. This might be detached-head-state for beginners, or an odd rebase that somehow lost your data and your company's git experts can't figure out where it went. Obviously the probability of such a state is inversely proportional to your understanding of git.



Yeah, it was hyperbole. Git does the job.


I agree that the CLI of Mercurial is much more thought out than that of git, but calling git crap is unreasonable.


Fair point. I was exaggerating.


Git did have one big advantage over Hg at the time, which was speed; a relevant criteria for Linux.

I do agree ending up with git was unfortunate. After trying all the popular choices, Monotone was what I would have picked. Fast, secure, portable and simple.

But Linus didn't like it because it supported cherry-picking, which apparently is an anti-feature for a VCS :)


This is bullshit. git had to support cherry-picking from day one and monotone was extremely slow. Some background: https://lwn.net/Articles/574075/


Your link has nothing to do with your argument.

Monotone was slow back when git didn't exist, but later versions greatly improved that.

Also, it's clear Linus didn't like cherry-picking, but other people convinced him to add it to git.


Why should git be junk? Sure its commands may not be the most intuitive but apart from that it's fast, flexible and works well. Git has won, get over it.


The time I spend waiting for my dvcs is trivial compared to the time I spend interacting with it. I use git, and it gets the job done, but I'll still lament that fate chose git over any of the superior alternatives.




Applications are open for YC Winter 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: