yes_or_gnome

Your comment is criminally low. Every other comment is 'Git vs. Mercurial' and speculation as to why git has "won". Their not useless, but they are uninteresting technically. So, as a git aficionado, I thank you for a detailed analysis of Mercurial and this proposal.

Personally, I've only used Mercurial to check out some projects that use it exclusively (i.e. (previously) Python and Firefox) and to create a toy repo of no significance (to learn its CLI interface).

Just to highlight a couple things from your comment:

> Therefor, if you value some of mercurials core features, and your primary value from git is the light weight branching model, mercurial with evolve + topics starts to look like a real solution for many shops.

By far the most annoying thing about going from git to mercurial is the overloaded concept of a 'branch'. I couldn't care less about the continued existence of my one-off, topic branch. TBH, I prefer the git concept of the reference pointer being culled in the process. The (git) branch's existence continues on only in the merge commit message. Although this assumes 1) an actual merge was committed (not rebased), 2) the merge wasn't fast-forwarded (--no-ff), and 3) the default merge message format was used.

> With that said, we use mercurial in production for our main repository. We do use evolve + topics for our development and when commits land in production, those commits become “immutable”.

> Developers can rebase their work, if they wish, and they can squash, if they wish. I generally discourage the later as I’m a believer more commits the merrier. I’m also not allergic to merging and I don’t see the value in a purely linear history, so rebasing isn’t as common for us. We also have a single integration branch. When developers are ready, we merge to this branch and the ticket gets advanced to qa. Once the ticket passes qa, we merge to default (therefore advancing the head) and the topic is closed out on its own.

We use Github. IMO, Github made a HUGE mistake when they added the options to Rebase and Squash in-lieu of the only sane option, Merge. I suspect that a lot of users wanted these options because Github (still) refuses to drop the --no-ff from their Merge strategy. I prefer --no-ff, but I do agree that it does make for an ugly log graph; Unlike most people, I couldn't care less about pretty graphs.) Rebase and Squash shouldn't be considered "Merge" strategies. They're for cleanliness, but only prior to sharing changes. Having them in Github has made the process of figuring out what has (and hasn't) been merged just absolutely atrocious. I'll leave it at that, but needless to say my arguments haven't convinced my peers' desire for pretty graphs.

As far as other user comments, I think the most egregious suggestion has been (paraphrasing):

> Mercurial has (had) better documentation.

Which I think is patently false. Git' manpages are (and always have been) fantastic. git-scm.com has been around for as long as I can remember. If you really want to do so, you can get yourself deep into the git's technical documentation which will teach you everything about the file formats and algorithms that are being used. All of this documentation has been around since git maintenance was handed over to Junio Hamano (circa May, 2005); Long before it's popularity explosion.

I'm not a JS developer, so this as much of a question as it is a statement.

`exec` is a system call and doesn't call bash or any other shell. At least, it shouldn't.

If it does, then it would be wrong to assume that bash is even available.

Either way. The single quote sytax is specific to bash (and maybe sh, dash, etc. I'm not certain.) so, don't rely upon it.

Us Cubs fans had a truly awful decompression in 2016. Don't get me wrong, winning the world series was amazing. But, I wish they did it in less dramatic fashion.

And, to stifle the high, there was an absolute (and ongoing) tragedy less than a week later.

Also. There's the minor leagues. Officially, those are (high to low) AAA, AA, high-A, and low-A. Then there's extended spring training, summer leagues, and associated leagues in the Dominican Republic and Venezuela. Independent leagues, college, high school, and youth leagues down to 4 year olds. International major leagues in Japan, Korea, Taiwan, Cuba, and Mexico.

There's a lot of room to test out new rule changes, but it would take a lot of effort to get them adopted every where.

There are some common rule changes that only make sense in leagues to limit length and discrepancies in competition. Limited innings, run limits per inning, mercy rule, home run limits, starting with runners in extra innings.

However, the rules that the MLB are looking into wouldn't make any sense in non-professional leagues. MLB is looking at limiting visits to the mound and pitching clocks.

Your local high school game isn't going to have pitcher-induced piece of play problems because the player's just aren't that good. Or, if they are, then the game will be forfeited early.

I can't imagine MLB fans being okay with rules that stifle competition. Starting an inning with runners on feels 'icky' for lack of a better term.

I remember when the NHL introduced shootouts. As an NHL fan, I was upset, but I understand the reasoning behind it. There's a large constituency that doesn't like games that end in a tie. Penalty shots are exciting, even when they're manufactured. And, it's a common rule in other hockey leagues (and football/soccer). So, not a big change, but disappointing to a lot of fans; myself included.

However, the change from 4-on-4 to 3-on-3. That was excellent, imo.

Just thinking about the number of rule changes in the NHL, since 2005, is pretty amazing. Certainly it is more exciting, but to get back to baseball, it has me thinking of all the room there is to adjust the game of hockey. Eliminate two line pass, adjust equipment size and materials, regulate goalies, regulate defense, regulate fighting, instant icing, concussion testing, etc., etc., etc.

I couldn't even come up with did ways to make baseball "more exciting". And, even if someone did, then I feel that it would be detrimental to the game.

Just for fun.

1. The first batter runner dictates which base is "first" by running left (to "third") or right (to "first"). This would make indeed infield defense more difficult and add an extra degree of thought into the game.

2. Fielders must rotate positions each inning. Now you can't just put the lefty, 250lbs guy at first because he'll have to shag some balls in the outfield and be a nightmare at shortstop.

3. Rescind the "ball in cap", which is a ground rule triple if a fielder catches a ball with his hat. Instead, make it an ground rule double-play. Just for the fun of seeing someone try it and, as a result, for all the dropped balls.

4. Any player that hits a home run may go back up to bat. Why, yes, i would love to see a single player go back-back-back HRs before taking himself out of the game due to exhaustion.

5. The starting pitcher may opt to throw a red/hot ball once per game. If he throws a strike, then it's a strikeout. If it's a ball, a walk. If it's hit, then it can't be caught (else it's a ground rule double). Hit by pitch is a HR. A batted HR is a grandslam. A foul becomes a do over.

6. The opposing team sets your lineup. Starting pitchers must have a minimum days rest. And, the lineup cannot be changed in the first inning except for injury.

This is likely to be said, "`--color=auto` is the default setting, so it's not needed." However, it's good to include it here because some users may have changed their default configuration to disable colors. This way `git log` works as their standard workflow and `git lg` for when they need a bit of color.

Most be a slow day at HN. I've subscribed to this subreddit and the posts there are mostly people discovering lkml.org for the first time and seeing the "Hottest" emails of which some are over 5 years old. (`Re: [Regression w/ patch] Media commit causes user space to misbahave (was: Re: Linux 3.8-rc1)`, `Re: [GIT] Networking`, etc.) In this thread, there's been plenty of more recent examples of Linus's snark, but this particular subreddit is more or less dead. And, I suspect it's dead for a good reason. That is, Linus doesn't really really all that much. Side from the infamous 'Mauro, Shut The F* Up!' email, there's not that many good "rants".

There's plenty of snarky, bad behavior sure. I get that a lot of people don't like it, but none of them bother to understand that these people work together daily and in the most open environment possible. Nobody considers the fact that, in the most infamous example, Mauro has been a contributor since 2006. (I don't know either, not anyone that's a major Linux contributor.) That's right, I wrote 'has' not 'had' because he still contributes to this day. That's not too excuse a behavior, but as a knock against the characterization of a "toxic environment". Maybe for some, but obviously not for others.

I for one, am glad that most of my cringiest, offensive comments were in person and that I was able to walk then back. And, of the stupifying comments that I made in an email, I'm incredibly thankful that they were private.

I take your original comment as an indictment that git is somehow broken by design. Which sure, you're entitled to an opinion, but to bring up SVN in the same breath is absurd.

That's why I replied.

I can't really address p4 because I haven't used it for any real world use cases. Only to prepare for an interview. With that limited use, I can't come with any reason to think it's superior.

The tool that doesn't work with case insensitive filenames is OSX.

Edit: To add, how is git supposed to handle two files with the same name -- as is the case -- with a case insensitive file system? You can't have two files with the "same" name.

    git checkout file1

Is entirely different than

    git checkout FILE1

In any other platform ls file1 FILE1 would show two different files, but on OSX, it'll show the same file twice.

I don't see how that's easier. There's `git checkout -b my-new-branch` which is even easier than the originally proposed solution. Followed by `git checkout master && git reset --hard @{u}` or, if you don't want to switch between branches, `git branch -f master master@{u}`.

Just as an FYI, those will likely live in Github forever. Run `git ls-remote` where ever you have had this problem. You'll see that there are refs for every PR in the form `refs/pull/NNNN/head` and `refs/pull/NNNN/merge`; where `NNNN` is the PR number, `head` is the latest commit and `merge` is the final commit.

If any of those commits with confidential information is reachable from any of those commits, then they'll never be garbage collected from Github.