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.

While the details of that case are fascinating, that's not the purpose of this comment. The tie-in to OP's comment is this, the Innocence Project was started by Barry Scheck[2] and Peter Neufeld[3] in 1992. Both Scheck and Neufeld were instrumental members on Simpon's "Dream Team"[4] responsible for discrediting the DNA evidence. If you remember the constant media coverage of the trial, Scheck was the attorney responsible for questioning forensic experts and the LAPDs collection practices. Again, I don't want to get into particulars of the case, but their arguments are very convincing (to me).

Obviously, the project was started prior to the OJ Simpson trial (in 1995) and regardless of one's opinion of Simpson's innocence, I think that most people will agree that single case led to increased scrutiny of forensic evidence and a reduction of importance placed on unreliable eyewitness testimony are a net positive to the world.

[1]: https://en.wikipedia.org/wiki/Innocence_Project

[2]: https://en.wikipedia.org/wiki/Barry_Scheck

[3]: https://en.wikipedia.org/wiki/Peter_Neufeld

[4]: https://en.wikipedia.org/wiki/Dream_Team_(law)

Additional Links:

https://en.wikipedia.org/wiki/O._J._Simpson_murder_case

https://en.wikipedia.org/wiki/O._J._Simpson

`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.

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

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 rule" seems a lot like the "skinny triangle" rule. I recently ran across it on Wikipedia after going through astrophysics articles. Specifically, to my understanding, the parsec could be calculated without using a trig function thanks to the skinny triangle rule. (To a certain level of error, of course. And, the parsec is now a defined value so the original trig-derived definition is invalid.)

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

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.

> Explanation of Responses:

> 1. Transactions reported on this Form 4 were made pursuant to trading instructions adopted by the reporting person on October 30, 2017 that are intended to comply with Rule 10b5-1(c).

https://www.sec.gov/Archives/edgar/data/50863/00011276021703...

https://en.m.wikipedia.org/wiki/SEC_Rule_10b5-1

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.

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

    git checkout FILE1

Unrelated topic (falling cats), same logical fallacy: http://www.radiolab.org/story/102525-vertigo/ (Starting around 14:20)

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

    $ git status --short
    ## master...origin/master
    M include/uapi/linux/netfilter/xt_connmark.h
    M include/uapi/linux/netfilter/xt_dscp.h
    M include/uapi/linux/netfilter/xt_mark.h
    M include/uapi/linux/netfilter/xt_rateest.h
    M include/uapi/linux/netfilter/xt_tcpmss.h
    M include/uapi/linux/netfilter_ipv4/ipt_ecn.h
    M include/uapi/linux/netfilter_ipv4/ipt_ttl.h
    M include/uapi/linux/netfilter_ipv6/ip6t_hl.h
    M net/netfilter/xt_dscp.c
    M net/netfilter/xt_hl.c
    M net/netfilter/xt_rateest.c
    M net/netfilter/xt_tcpmss.c

The first tag (?) points to a tree.

  $ git cat-file -p v2.6.11-tree
  object c39ae07f393806ccf406ef966e9a15afc43cc36a
  type tree
  tag v2.6.11-tree

  This is the 2.6.11 tree object.

  NOTE! There's no commit for this, since it happened before I started with git.
  Eventually we'll import some sort of history, and that should tie this tree
  object up to a real commit. In the meantime, this acts as an anchor point for
  doing diffs etc under git.
  -----BEGIN PGP SIGNATURE-----
  Version: GnuPG v1.2.4 (GNU/Linux)

  iD8DBQBCeV/eF3YsRnbiHLsRAl+SAKCVp8lVXwpUhMEvy8N5jVBd16UCmACeOtP6
  KLMHist5yj0sw1E4hDTyQa0=
  =/bIK
  -----END PGP SIGNATURE-----

  $ git cat-file -p v2.6.12-rc2
  object 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
  type commit
  tag v2.6.12-rc2

  Linux v2.6.12-rc2 release
  -----BEGIN PGP SIGNATURE-----
  Version: GnuPG v1.2.4 (GNU/Linux)

  iD8DBQBCbW8ZF3YsRnbiHLsRAgFRAKCq/TkuDaEombFABkPqYgGCgWN2lQCcC0qc
  wznDbFU45A54dZC8RZ5JxyE=
  =ESRP
  -----END PGP SIGNATURE-----

This is due to the fact that those tags pre-date the tagger header which came a short while later.

  $ git cat-file -p v2.6.13
  object 02b3e4e2d71b6058ec11cc01c72ac651eb3ded2b
  type commit
  tag v2.6.13
  tagger Linus Torvalds  1125272548 -0700

  Linux 2.6.13 release
  -----BEGIN PGP SIGNATURE-----
  Version: GnuPG v1.4.1 (GNU/Linux)

  iD8DBQBDEkvwF3YsRnbiHLsRAp5tAKCEK1XmOropxvWp+k9eiTcafNMXXACcDAVb
  +hOwdKI+bi84SSNNSGnSXGg=
  =cnNS
  -----END PGP SIGNATURE-----

Just to reenforce the "First Commit" claim, here's the rev-list for the commit and the commit contents. (Notice it has no "parent" commit.

  $ git rev-list 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
  1da177e4c3f41524e886b7f1b8a0c1fc7321cac2

  $ git dump 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
  tree 0bba044c4ce775e45a88a51686b5d9f90697ea9d
  author Linus Torvalds  1113690036 -0700
  committer Linus Torvalds  1113690036 -0700

  Linux-2.6.12-rc2

  Initial git repository build. I'm not bothering with the full history,
  even though we have it. We can create a separate "historical" git
  archive of that later if we want to, and in the meantime it's about
  3.2GB when imported into git - space that would just make the early
  git days unnecessarily complicated, when we don't have a lot of good
  infrastructure for it.

  Let it rip!

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

Clone (--no-checkout):

    $ git clone --no-checkout https://github.com/Katee/git-bomb.git
    Cloning into 'git-bomb'...
    remote: Counting objects: 18, done.
    remote: Compressing objects: 100% (6/6), done.
    remote: Total 18 (delta 2), reused 0 (delta 0), pack-reused 12
    Unpacking objects: 100% (18/18), done.

[1] Thanks to Jim Weirich and Git-Immersion, http://gitimmersion.com/lab_23.html. I never knew the guy, but, ~~8yrs~~ (corrected below) 3.5yrs after his passing, I still go back to his presentations on Git and Ruby often.

Edit: And, to see the whole tree:

  NEXT_REF=HEAD
  while [ -n "$NEXT_REF" ]; do
    echo "$NEXT_REF"
    git dump "${NEXT_REF}"
    echo
    NEXT_REF=$(git dump "${NEXT_REF}"^{tree} 2>/dev/null | awk '{ if($4 == "d0" || $4 == "f0"){ print $3 } }')
  done