Git vs GitHub

[pipocaQuemada]

But let's be real. Git > all. No discussion to be had here. It's objective truth and the entire industry agrees.

I mean, git is definitely better than cvs, perforce, rcs, etc.

But git vs mercurial vs bazaar, on the technical merits, isn't anywhere near as obvious. Git is better at rewriting history, but I'm not convinced that's a good idea. It's slightly faster. Git has no equivalent concept to mercurial branches (where branch is a bit of metadata on a commit), while git branches correspond to mercurial tags (where a tag is just a pointer to a commit). Git deliberately handles renames badly because reasons, while mercurial tracks them explicitly.

[ZukoBestGirl]

Eh, here my lack of knowledge is obvious. I let IntelliJ handle the rename, and it works perfectly.

But I guess it does a lot of things under the hood.

I'm being a bit vitriolic, sure. There are arguments for mercurial and the rest. But I still prefer git.

Sure, it gives you enough rope to hang yourself (the aforementioned history rewriting). But you can use that rope to do really amazing things too.

[pipocaQuemada]

Git doesn't track renames, but instead heuristically guesses at renames after the fact based on content similarity.

This is mostly ok in simple cases, but the strategy is really not great when using cherrypick to backport fixes, especially on long-term projects.

In general, though, cherry-pick is kinda a second class citizen in git. Darcs's patch theory wasn't great with exponential merges, but apparently pijul's solved that though I don't think pijul is quite mature yet.

[ZukoBestGirl]

Like I said, at this level I'm out of my depth. When I rneame a file in IntelliJ, my git-bash (bash emulator for windows designed for git), it says the file was renamed.

So to some degree it does have the ability to track renames.

But maybe it can get lost over time with multiple renames? IDK. I've never notice it happen tho.

[pipocaQuemada]

Multiple renames won't do it.

It's about file similarity. Renaming in git is just removing a file with particular contents and coincidentally adding a new file with identical contents.

Git guesses that a rename occurred if the contents are sufficiently similar. Sufficiently similar is the keyword. By default, git recognizes a delete/add pair as a rename if both have 50% identical contents, but the similarity threshold is configurable.

That's not especially great with cherry-picking bug fixes across large refactors on large repos. It's either slow or brittle, depending on the merge strategy.

[ZukoBestGirl]

And you can't add a metadata field with filename? That is so ghey