HN Theater @HNTheaterMonth

Interesting, I've not ever seen a recommendation for bazaar over git or mercurial. I have heard that mercurial's CLI is a bit more sane than git, and I've also read that it's easier to extend in Python. How would you compare bazaar to mercurial?

I've actually only ever used git for professional and personal development, but I think I'll want to play around with both mercurial and bazaar now. Git's CLI is definitely a bit of a PITA.

I find this video summarises git's frustrations pretty well :) https://vimeo.com/60788996.

⬐ chx

I will be ready to admit I haven't used mercurial much. But ... how does mercurial help the "small" use case?

⬐ ngoldbaum

Bazaar is basically unmaintained at this point. If you look on Launchpad, the trunk branch hasn't seen a commit since December 2014 [0]. There hasn't been a release since August 2013 [1].

Mercurial is very actively developed, with dozens of patches a month [2]. They also keep to a planned rolling release cycle [3] along with deep commitments about backward and forward compatibility [4].

New features like the experimental evolve extension [5] are also really cool. I use it for day-to-day work and find it incredibly useful for editing work-in-progress commits into nice self-contained patches.

[0] https://code.launchpad.net/bzr/trunk

[1] https://launchpad.net/bzr/

[2] http://selenic.com/pipermail/mercurial-devel/2015-March/thre...

[3] http://mercurial.selenic.com/wiki/WhatsNew

[4] http://mercurial.selenic.com/wiki/CompatibilityRules

[5] http://mercurial.selenic.com/wiki/ChangesetEvolution

⬐ chx

Yes. git won, bzr is dead. As I said: I am aware and I switched to git because everyone else did. Just don't expect me to be happy about it.

⬐ ngoldbaum

I'm trying to say if you want a git alternative that's not dying and isn't infuriating, check out mercurial.

⬐ chx

I can't, the world (open source projects and work both) is using git.

Totally agree. At best this rebase talk is navel-gazing, and at worst it's a technique that turns Git into a complicated, scary place for those just want to get work done.

I have introduced git and hg to many people, but I've always tried to tie it into what people do already. Without source control, practically everybody did the same thing: They'd work a little bit, they'd save, they'd work a little bit, they'd save... etc. Using branching for organizing work and a nice cheat-sheet of a few git commands, most non-technical people will be off-and-running.

It all works until the programmers make it complicated with the rebasing. The price of the tidy commit history is the loss of confidence of the rest of the team. I'd rather have the people.

Case in point: https://vimeo.com/60788996

⬐ base698

It's only complicated because people don't realize how it works. Half the people in this thread advocating to use rebase aren't saying when it's ok and when it's not ok and why.

When it's ok: You are working on your own line and the commits you've made are not in a central repo.

Why: Git commits are a hash tree and when you change one commit it changes all the SHAs that come after it. This makes git see your commits pushed remote as different then the ones that are local. The commits have the same changes so it puts duplicate conflict markers everywhere.

Most people love it once they realize how it works.

A lot of people use version control also as a backup in case their hard drive fails. Because of this they are scared of staying on a topic branch for very long, so they push then rebase often leading to conflicts which are scary.

https://en.wikipedia.org/wiki/Hash_tree

⬐ snaky

That's not about git. That's about ``Fool may throw a stone into a well which a hundred wise men cannot pull out''.

⬐ jasonhanley

This video is funny because it's true.

Git is practically unusable for all but the simplest things without a good set of aliases or wrapper scripts.

⬐ migrantgeek

It's true only from your world view. You should have titled the post "Git is hard for me" but it would have attracted less eyeballs.

I'm a daily user of Git interacting with thousands of developers committing against the same repo. Here's my sole alias

l = log --graph --pretty=format:'%C(yellow)%h%C(cyan)%d%Creset %s %C(white)- %an, %ar%Creset'

I'm not saying that "I'm so smart I don't need aliases" or that "you're so dumb that you need them" which is how my post is likely to be interpreted.

I'm saying that your past usage and experience may differ so much that it's hard to change the patterns set in your brain. I work with folks who have used Perforce for a decade and struggle with Git. They're super smart but Git is very different and therefore difficult for them at least at the start.

Generally speaking I would recommend avoiding sugar. I sometimes interview folks with so many Bash aliases on their own workstation they can barely navigate using vanilla Bash.

⬐ snaky

I understand Perforce users you are talking about, but their problems are temporary and that's OK - almost anyone changing main language from Java to Haskell need some time to start feeling comfortable and get productivity to his usual level.

But about Bash aliases - is there any real need to use vanilla Bash (or sh, or ksh, or csh) when he has his settings/aliases file with him?

⬐ darrencauthon

Using Git can be easy to understand, as it takes only a few commands to make it usable. git commit, git add, git push, git pull, etc. That's enough to get most users, including people that would normally be afraid to use a command line, to a state where they can contribute to a git repo.

And if the work is being done in Github, then the person can use the Github apps to just-get-the-work-done. No command line.

What makes git hard are the men "helping" the woman in this video. Devs create these crazy rules around branching and rebasing, which results in:

1.) Hours wasted while people try to comply with a process they don't understand, and

2.) Timid work, as everybody's afraid that stepping on the wrong stone will trip a booby-trap that messes everything up, looping back to (1).

There is a workflow that people were following without git. They'd make changes, save them, and then move on. If someone else made changes, they'd bring those changes in (i.e. merge) and move on. In my experience, most people understand that. All of the rebasing nonsense is getting people nowhere.

A deep understanding of git should not be a requirement to use git anymore than I shouldn't need to know how my car works to drive to work. The goal is to get where we need to go, not to have the perfect vehicle and trip. Your git repo might get messy sometime, shrug, sorry -- development can be messy sometimes. Use the git experts abilities to clean it up, rather than try to get everybody to a git expert level.

Git experts: Keep. It. Simple.