Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Things I just don't like about Git

cohost.org

Post reply on HN
Print view View original

51–60 of 118 posts

Re: Things I just don't like about Git

#51

Post by CableNinja »

miohtama wrote: post #6
gavinhoward wrote: post #2

I love these posts. I bookmark all of them. I feel strongly that VCS's could have much better UX and reliability. I'm trying to design one myself instead of implementing it in a weekend. (Though I do understand the constraints Linus was under when he made Git.) I'd love to hear more about what people hate about Git.

Back in a day, late 00s, early 10s, Git had alternatives. - Bazaar - Mercurial (Hg) Both had superior user experience compared to git, including command line and GUIs. They were not as fast, but no slow either if you came from Subversion world. They were not as flexible, but still very very flexible. What caused Git to win was not rants of Linus Tolvards, but Github. Github gave Git a semi-understandable web user int…

git gained popularity way before github/gitlab. Its popularity stemmed from the features that CVS and SVN were severely lacking. Github just made it easier to share and discover projects, and it happened to use git. It also helps that github was not a target for foss, instead it was started as a business. Before then, git, cvs, svn, were all foss projects and hosted (usually mostly) by the project owners.

Re: Things I just don't like about Git

#52

Post by rileymat2 »

PurelyApplied wrote: post #33

There are so many things to dislike about git, but I feel like so much of this post is reaching for cause to be offended. Sha1 is a hashing function. As a hashing function, it's fine. Why does your identifier need to be cryptographically secure? I agree with the name and email issues, but laughed at the ideal that a URL is somehow more robust. Who claims that git is a database? I agree with the broad strokes, especia…

> Why does your identifier need to be cryptographically secure?

There are many use cases where people are using the hash to guarantee no actor has inserted different code than they expect in a dependency, so the dependency is pinned to a hash. Not being secure, would be catastrophic for some use cases that people are currently using if widespread.

We could make a claim this is a misuse, but this is what people are doing.

Re: Things I just don't like about Git

#53

Post by recursivecaveat »

Yajirobe wrote: post #22
danhab99 wrote: post #7

I wish git would stash changes when I checkout uncommitted code

I thought git complains and doesn't allow you to checkout uncommitted code? Something along the lines of 'please commit or stash your changes before checking out'

You can do it as long as your changes are only to files that are otherwise identical on both ends of the checkout (meaning there's 0 possibility of conflict).

Re: Things I just don't like about Git

#54

Post by domador »

miohtama wrote: post #6
gavinhoward wrote: post #2

I love these posts. I bookmark all of them. I feel strongly that VCS's could have much better UX and reliability. I'm trying to design one myself instead of implementing it in a weekend. (Though I do understand the constraints Linus was under when he made Git.) I'd love to hear more about what people hate about Git.

Back in a day, late 00s, early 10s, Git had alternatives. - Bazaar - Mercurial (Hg) Both had superior user experience compared to git, including command line and GUIs. They were not as fast, but no slow either if you came from Subversion world. They were not as flexible, but still very very flexible. What caused Git to win was not rants of Linus Tolvards, but Github. Github gave Git a semi-understandable web user int…

I wish I lived in an alternate timeline where a delightfully unpronounceable service called HgHub had won the day instead. But on a more open-minded note, would Github been just as successful if they had used something other than Git for the backend? Or was Git already popular enough that Github had essentially no other choice but to use it instead of another DVCS if they wanted to become the dominant player in their space?

Re: Things I just don't like about Git

#55

Post by danShumway »

BoiledCabbage wrote: post #45
danShumway wrote: post #25

Comes up in every conversation I have about Emacs, Git, CSS, etc: Just because a tool is the best at what it does, that doesn't necessarily mean it's good at what it does. Those are two different metrics. There's no danger of me dropping Git, the best alternative I've seen is Fossil and (opinion me) I think Fossil makes more mistakes than Git does. But Git definitely still has flaws; a lot of this post rings true to…

That's fundamentally the issue with git. It's underlying concept is good - probably still a tad bit more convoluted than it needs to be with the benefit of hindsight, but that's fine. It's hard to design software. But it's overall user experience - the way you interact with it is horrific. It's is so incredibly convoluted. So much inessential complexity. Half of learning to use git is learning to look past the convol…

When I teach Git in mentoring situations, I start with the underlying concepts before I even touch the user interface. And that's kind of wild, it's a testament to how bad the user-facing interface is that I'm thinking about it through the lens of "understanding the internals will make the UI easier", not "understanding and working with the UI will make the internals clearer."

Re: Things I just don't like about Git

#56

Post by gavinhoward »

IshKebab wrote: post #27
gavinhoward wrote: post #2

I love these posts. I bookmark all of them. I feel strongly that VCS's could have much better UX and reliability. I'm trying to design one myself instead of implementing it in a weekend. (Though I do understand the constraints Linus was under when he made Git.) I'd love to hear more about what people hate about Git.

Yeah I think the point about monorepos vs submodules is probably the biggest non-usability issue with Git. In a very large project you can have a monorepo, and then everything is slow and you can't easily use and work on a subset of the code. Or you can use submodules and then testing, refactoring and making commits all become a nightmare. Binary files is another crap area of Git. LFS is useless. Lots of people have…

> Yeah I think the point about monorepos vs submodules is probably the biggest non-usability issue with Git.

As a lone developer, I admit that this is what surprises me the most about the experience of other people.

But I'm going to solve it. Partial checkouts, fully-transactional cross-submodule commits, the works.

Really, these problems are easy with a good design. It's unfortunate that Linus didn't have time for design.

> Binary files is another crap area of Git. LFS is useless. Lots of people have Stockholm syndrome and think that Git doesn't support large/binary files well because it's immoral rather than just because it's not something Linus ever needed.

Yeah, I don't get this either.

I am implementing a general plugin system for creating format-aware operations. This will include source code and binary files.

> I'm still a bit sad that most of the attempts at replacing Git focus on the poor conflict resolution story (which is poor but tolerable) rather than these more fundamental issues.

I fully agree. I'm going to the doing UX studies, and that's my first priority.

I am going to handle conflict resolution better, though.

Re: Things I just don't like about Git

#57

Post by aeurielesn »

anonyme-honteux wrote: post #20

https://fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki git doesn't suck. It's the best possible version control system in the context where it was produced, i.e. the Linux Kernel, i.e. an ultra large bazaar style project with hundreds of developers gifted at getting the low level details right. It was not however designed for the kind of projects I work on, more Cathedral style, a few people who know and trust e…

There was a podcast with the author of SQLite explaining pretty much why he doesn't use anything by anyone else.

Re: Things I just don't like about Git

#58

Post by charcircuit »

rebolek wrote: post #36
kstrauser wrote: post #17

Earlier quoted context omitted.

Mercurial is still actively developed.

And its interface makes more sense than Git.

And with sapling, a fork of Mercurial, it is network compatible with git so you can get around git and github's network effect

Re: Things I just don't like about Git

#59

Post by fanf2 »

PurelyApplied wrote: post #33

There are so many things to dislike about git, but I feel like so much of this post is reaching for cause to be offended. Sha1 is a hashing function. As a hashing function, it's fine. Why does your identifier need to be cryptographically secure? I agree with the name and email issues, but laughed at the ideal that a URL is somehow more robust. Who claims that git is a database? I agree with the broad strokes, especia…

Git was using SHA1 as a cryptographically secure identifier right from the very first month of its existence. https://github.com/git/git/commit/65f0d0ee4627dd0f0468ceded3...

Re: Things I just don't like about Git

#60

Post by Forge36 »

kelseyfrog wrote: post #13

Yep, ran into the "don't change your name" edge case. I have the choice of rewriting history and coordinating that amongst team members, dealing with it, or switching companies and never working on the project again. So far, I just deal with it, even though it chips away at my soul each time it comes up.

Is there a reason .mailmap doesn't work in your case?

https://git-scm.com/docs/gitmailmap

>If the file .mailmap exists at the toplevel of the repository, or at the location pointed to by the mailmap.file or mailmap.blob configuration options (see git-config[1]), it is used to map author and committer names and email addresses to canonical real names and email addresses.

Post reply on HN