Live data from Hacker News

Things I just don't like about Git

cohost.org

31–40 of 118 posts

Re: Things I just don't like about Git

#31

I wrote my company's git wrapper. It was meant to standardize our workflow and to be communal memory for every lesson learned and sharpened edge shaved. It's now 6000 lines of bash. (Ok, I'm a little proud of it. I'll open source it as soon as I rewrite it in Python.)

How do you reconcile this with the fact that the vast majority of git users, both at small and large scales, do not need to do this? Now you have a massive, proprietary to your company, system for committing code that every person that joins the company has to learn and maintain.

Re: Things I just don't like about Git

#32

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.

Many years ago, when I was looking for a worthy DVCS successor to Subversion for my single-developer projects (just in case they became multiple-developer projects), I evaluated Git, Bazaar, and Mercurial. I don't really remember what were the deciding factors, but I ended up going with Mercurial. I'm sure usability was a big part of it, since that's a major value for me, and I really didn't like git in that department. I think I also read some things that made me distrust git's handling of data, but don't remember the specifics. git just seems messy in other ways as well. I still wonder to this day whether the wrong DVCS won the popularity contest and became an unfortunate default option for developers.

Re: Things I just don't like about Git

#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, especially having as many conversations as I've had with frustrated people about why their repo is in an unhappy state.

Re: Things I just don't like about Git

#34

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.

Scrap the thing entirely and replace it with something that uses intuitive metaphors like "save", "load", "undo", "go back to old version", "update my work with work from colleague", "update the official state with my work" and others. Folders instead of branches. Be 100% language-aware; any merge result has to build obviously.

If this rejects actions and limits possibilities that Git provides, so be it.

Re: Things I just don't like about Git

#35
post #23

I wrote my company's git wrapper. It was meant to standardize our workflow and to be communal memory for every lesson learned and sharpened edge shaved. It's now 6000 lines of bash. (Ok, I'm a little proud of it. I'll open source it as soon as I rewrite it in Python.)

What’s the shellcheck output look like? Sounds marvelous.

Shellcheck clean. But I still want to port it to python.

Re: Things I just don't like about Git

#36

Are there other free (like payment) alternatives to git? The only other one I know of that can be used for large files is https://www.plasticscm.com/ .

Mercurial is still actively developed.

And its interface makes more sense than Git.

Re: Things I just don't like about Git

#37

I wrote my company's git wrapper. It was meant to standardize our workflow and to be communal memory for every lesson learned and sharpened edge shaved. It's now 6000 lines of bash. (Ok, I'm a little proud of it. I'll open source it as soon as I rewrite it in Python.)

How do you reconcile this with the fact that the vast majority of git users, both at small and large scales, do not need to do this? Now you have a massive, proprietary to your company, system for committing code that every person that joins the company has to learn and maintain.

That's a good question. My wrapper isn't meant to insulate the users from git, it's meant to teach git. It shows every git command it runs and gives the user an easier on-ramp.

Re: Things I just don't like about Git

#38
post #29

I'm dying laughing > submodules? they're a file in the repo with a special type inside the trees, git knows when checking out that the file is special, and could run other commands. it then does not run those commands and the person using submodules begins crying. For a while, at my company, we used a git submodule (err, I unfortunately used a git submodule... this was my fault) and it was tradition for every new eng…

Your deploy process says nothing if several (possibly thousands? a submodule can be big) files are missing and this is a complaint you have about git? It sounds like more of a complaint about the deploy process.

Re: Things I just don't like about Git

#39

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…

> the best alternative I've seen is Fossil and (opinion me) I think Fossil makes more mistakes than Git does.

The fossil developers (myself included) would be interested in hearing what those mistakes are. We're open to improvement so long as they don't break backwards compatibility (e.g. rewriting history, as is necessary for kernel-scale projects, is an unwavering absolute no-no in fossil).

Re: Things I just don't like about Git

#40

I wrote my company's git wrapper. It was meant to standardize our workflow and to be communal memory for every lesson learned and sharpened edge shaved. It's now 6000 lines of bash. (Ok, I'm a little proud of it. I'll open source it as soon as I rewrite it in Python.)

Is it easier to learn the simple concepts of git and have transferable knowledge, or to learn your proprietary 6000 line bash script?

It's easier to support a company of users when everybody is using the vcs tool in a consistent way.
Post reply on HN