No, merging in git does not make branches disappear.

How is a Mercurial commit tree clearer than a git commit tree?

That seems to be the opposite of useful if a commit is initially pushed to a development branch, which is relatively standard practice; now you’re polluting the tree with data that’s purposefully ephemeral, and even potentially leaking internal information.

Also, I’d argue that such deep details do belong in another tool, rather than asking the source control tool perform triple duty by being a CR and issue tracker as well.

Your claim appears to be that Mercurial binds commits to branches, and I’m explaining how I fail to see the advantage.

A commit all by itself doesn’t mean as much without context.

Why would I not want to be able to apply a commit to any arbitrary branch?

Also, GitHub is not git - it’s based on git. Any shortcomings it may have aren’t necessarily due to a flaw in git.

Oh, that’s not a joke, it’s real.

I just want the box and/or the cacodemon.

That just sounds like an implementation detail.

Can you provide an example of something that’s possible in Mercurial, but not git?

What information is “loosed” when another commit is made to the branch?

What do you mean by “are a thing?” Git has branches.

I think it would be bad form to put their speculation on the headline.

The headline is not misleading in any way. That’s exactly what Nintendo said.

I doubt that “many” of the components are already being produced locally.

Was the guy on the right dooing evilly?

Ahhh, I see. Looks like the magic happens somewhere further down in iostream.

No, there’s no guarantee that in every context \n is translated portably.

Get out

If I’m writing C++, I’m usually optimizing for portability over performance, in which case I would prefer std::endl as it would yield the best results regardless of platform; it also keeps the end-of-line character out of other strings, making code just a little cleaner.

\n is for when I’m done pretending that anything that isn’t Unix-like is OK, or I’m counting the cycles of every branch instruction.

Oh, this isn’t satire.

The problem there is not the directness, but the terseness. This is something I had to learn myself, and fortunately was able to get feedback from colleagues who appreciated my directness and wanted more elaboration.

What’s the alternative to being direct? Being indirect? Dropping hints? Spreading a rumor?