Follow

Every now and then I get some "git sucks" comments in my timeline, but never ever have I seen one that actually lists some reasons (that is, facts and not opinions).

I conclude that is the best.

@musicmatze okay I'll bite. It's the UX. The CLI verbiage is unintuitive. EG branches aren't branches. A branch should be called a head, a bookmark, or a leaf.

Moves and renames are not handled well, and can look like files were removed or added.

No immutable commit annotations. Hg branches are labels on commits that cannot be repositioned, if I want certain commits never to be pushed, git doesn't seem to give me options.

All that said, I like git just fine when I use mercurial to clone git repos.

@travisfw what does, in your opinion, qualify as a "branch"? Why are moves and renames not handled well? If you `git mv`, that's a move!
There are immutable commit annotations! They are called "tags" in git!

@musicmatze a branch is a whole unmerged dag of commits. Not just the one at the end.

With git mv, sometimes in the diff, the whole file will be subtracted in its old position and added in the new position.

Would you apply the same tag to every commit? I haven't ever seen tags used that way.

@travisfw @musicmatze

> a branch is a whole unmerged dag of commits. Not just the one at the end.

I'd say a branch is just a mutable pointer to a commit (which represents the unmerged DAG of commits). What's wrong with that and what do you mean with just one at the end?

> With git mv, sometimes in the diff, the whole file will be subtracted in its old position and added in the new position.

Yes but that should only happen if you (significantly) change the content though. AFAIK Git still doesn't track moves (via internal data structures) so that information needs to be computed if necessary (by comparing the content of removed and added files). This isn't ideal but I'm ok with that design decision (I'd say it's even a good thing for the nice and "simple" design).

> I want certain commits never to be pushed, git doesn't seem to give me options.

You can just use a local branch or if you want an old part of the history to remain private you could use git-replace. Not sure what other use-cases there would be.
But I also don't know how branches work in Mercurial.

I guess Git vs. Mercurial mostly comes down to personal preferences/options.

@musicmatze Yes, it is the best! Especially, if you have used other VCS like Microsoft's Team Foundation Version Control or TortoiseSVN.🤢 🤮

MS TFVC:
docs.microsoft.com/en-us/azure

TortoiseSVN:
tortoisesvn.net/

With git, everything Just Works™.

@musicmatze One reason I regularly encounter is that git won't force any specific workflow on you. This means git is little opinionated and allows you to choose whatever suits you best. The thing is: people like (and actually expect) opinionated tools which make on thing work. But if you are not that well familiar with git it can get really hard to "fix" a mistake you did while exercising a git workflow someone else chose for you. This is the point where git usually "sucks".

Sign in to participate in the conversation
Mastodon for Tech Folks

This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either!