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.
> 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 :-)
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.
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.
There is also `git clone --depth 1` but you have to use ssh+git protocol
If this is a frequent case for you, you could easily add an alias for this.
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
$ git fetch --depth=1 origin 6e5cdacfa6ac018c6ef42aa9679893676f293f21
error: Server does not allow request for unadvertised object 6e5cdacfa6ac018c6ef42aa9679893676f293f21
$ git fetch --depth=1 origin phobos-0.2
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.
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:
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.
"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.
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.
> 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.
which is exactly why a lot of people claim that git is shit. The fact that it "won" makes those people more angry.
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.
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
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.
2. Mozilla has also standardized on Mercurial
3. Mercurial’s changeset evolution is awesome: https://www.mercurial-scm.org/doc/evolution/
is there is some set of problems plaguing git users I've just never run in to?
Somehow, I rarely see a Mercurial tutorial give that same advice unless you are doing something really experimental.
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".
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."
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
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.
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 :)
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.