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

91–100 of 118 posts

Re: Things I just don't like about Git

#91

Post by fiedzia »

miohtama wrote: post #5

Git is what a software version control would look like if it were created by kernel devs who only knew C and Perl.

True. However this mix of C and Perl works. I remember early days of git and whenever someone tried to bring Mercurial (or something else), the answer for any non-trivial "how do I do X" in git was "here are some magic commands" and the answer from mercurial guys was "oh... you can't, the plugin for that doesn't exist yet". And that's how git won (well, it was also faster). And later came Github. Latest contender is https://pijul.org/ , which claims easier conflict resolution, ability to work with part of repository and handling of binary files, but so far completely misses social aspect.

Re: Things I just don't like about Git

#92

Post by Guvante »

I think GitHub is half the problem with how people perceive Git.

There are friction points between how Git works and how GitHub wants to do them.

Rebase is a nice compromise between merge which makes reading history and hard and squash which loses intermediate commits (sometimes breaking rename detection). But of course you cannot include a reference to the PR anymore outside the GitHub UI or manually rewriting commits.

Similarly having the type of merge be treated as a last second choice instead of part of the reviewable flow increases "wrong button" incidents a lot.

Re: Things I just don't like about Git

#93

Post by fouc »

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 was using git before github was even a thing. Ruby on Rails community was already moving to git in 2006 & 2007. Github was created by a couple of Rails developers that saw the popularity of git and responded.

I also tried Darcs, Bazaar & Mercurial back then. Those options were slooowww. Git largely won because it was blazing fast, and easy to understand. Probably having the cachet of Linus helped. I personally found transitioning from svn to git was a breeze.

I do have some quibbles about the structure of commands & arguments from an UX perspective with git, but ultimately it wasn't a dealbreaker.

Re: Things I just don't like about Git

#94

Post by fouc »

jonmayer wrote: post #19

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.)

> I'll open source it as soon as I rewrite it in Python.

Realistically speaking, will that happen? Why not throw up the bash code as a separate repository from the python one anyways? As an example. Could throw it into archived mode right after or something perhaps.

Re: Things I just don't like about Git

#95

Post by fiedzia »

UweSchmidt wrote: post #34
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.

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.

You will immediately find that people use version control differently and "undo" means different things for them, therefore you have either: a) 50 variants of "undo" b) one official undo, but "here we use git foo" because reasons c) people operating directly on the repo structure because a) and b) are to complicated and broken for some specific workflow. d) most likely - mix of all those options. What I don't get is why people insist on using git directly. Define your workflow and create aliases named "undo", "save" etc. that work with folders instead of branches if you wish, call it our_git and use it. I've seen people do something like that.

Re: Things I just don't like about Git

#97

Post by funklute »

Buttons840 wrote: post #81
danShumway wrote: post #49

Earlier quoted context omitted.

> e.g. rewriting history, as is necessary for kernel-scale projects, is an unwavering absolute no-no in fossil We could go further, but yeah, this is basically the biggest problem. I know this is a fundamental attribute of Fossil and that's fine, but to me it makes Fossil unusable as a VC system for most serious projects. I don't think of VC as an immutable record, I think of it as a tool for organization and collabo…

Git made the only choice a popular VCS can make. History rewrites will exist, period. If you're opposed to history rewrites, then git gives you the tools to ensure the repos you control are not rewritten, and that's all it can do in a world where people have control of their own computers. If Fossil ever becomes as popular as git, people will create software that allows history rewriting in Fossil. Another user in th…

> then git gives you the tools to ensure the repos you control are not rewritten

I might betray my ignorance here, but what tools are those?

If I host a git repo, then I can obviously ensure that any branches on the origin are never rewritten. But how can I ensure that people who submit pull requests have not rewritten their history?

Re: Things I just don't like about Git

#98

Post by danShumway »

Buttons840 wrote: post #81
danShumway wrote: post #49

Earlier quoted context omitted.

> e.g. rewriting history, as is necessary for kernel-scale projects, is an unwavering absolute no-no in fossil We could go further, but yeah, this is basically the biggest problem. I know this is a fundamental attribute of Fossil and that's fine, but to me it makes Fossil unusable as a VC system for most serious projects. I don't think of VC as an immutable record, I think of it as a tool for organization and collabo…

Git made the only choice a popular VCS can make. History rewrites will exist, period. If you're opposed to history rewrites, then git gives you the tools to ensure the repos you control are not rewritten, and that's all it can do in a world where people have control of their own computers. If Fossil ever becomes as popular as git, people will create software that allows history rewriting in Fossil. Another user in th…

It's more than inevitability to me; on some level I would almost say that "history" in Git is the wrong name. I've had conversations with Fossil devs before where they referred to rewriting history as a "white lie" and I just don't agree with that framing, I don't think it's a lie at all.

Git's history can correspond to actual history in reality and that can be a useful way to add accountability to a project (although of course as you say, you have no control over history coming from someone else's computer). But Git's "history" doesn't have to correspond to actual history in reality, and very often that's not how I'm using it. So I don't think when I rebase I'm lying because I don't believe I'm making any claim at all about the physical reality of how the code was written. I'm organizing feature commits on a timeline.

To me it's a little odd to look at that and to say "you're trying to change history." No, I'm not, I'm not saying anything at all about history when I do a rebase. I am grouping code together into logical units and putting them on a timeline so that they make sense when read sequentially. That's all I'm doing. If I came to you and said "this rebase perfectly represents the development history", sure that would be a lie. But I'm not saying that, and I don't think it's inherently the job of a VC system to claim that. I think the most important job of a version control system is to... well... control versions, and immutably showcasing a record of how the project was built is a secondary concern.

:shrug: At least the way I use VCs, I guess other people's millage may vary.

Re: Things I just don't like about Git

#99

Post by fouc »

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…

>Git's user interface

When I encountered git back in 2006, I was kinda surprised at the choices of git's commands & arguments, it didn't seem nearly as nice as SVN's command-line interface. But git did win out for being usable locally & the sheer speed.

I kinda hoped the command-line interface would get revamped w/ better command names & better argument structure, but that never happened I guess.

Re: Things I just don't like about Git

#100

Post by Buttons840 »

funklute wrote: post #97
Buttons840 wrote: post #81

Earlier quoted context omitted.

Git made the only choice a popular VCS can make. History rewrites will exist, period. If you're opposed to history rewrites, then git gives you the tools to ensure the repos you control are not rewritten, and that's all it can do in a world where people have control of their own computers. If Fossil ever becomes as popular as git, people will create software that allows history rewriting in Fossil. Another user in th…

> then git gives you the tools to ensure the repos you control are not rewritten I might betray my ignorance here, but what tools are those? If I host a git repo, then I can obviously ensure that any branches on the origin are never rewritten. But how can I ensure that people who submit pull requests have not rewritten their history?

> I can obviously ensure that any branches on the origin are never rewritten

That is all I meant. As you say, people can still rewrite their own history on their own computer before submitting it.

We could get philosophical about what "history" is. If I press backspace am I rewriting history? What granularity are we talking here? If I make change X by frequently committing and then squash, have I rewritten history? If I make the exact same change X with one big commit at the end (no squashing), have I not rewritten history? Whether or not I rewrote history the pull request at the end is the same. Or what if I'm using jj which amends a "working commit" hundreds of times, have I rewritten history?

Ultimately the division of changes into commits is a matter of authorship, a creative endeavor. I'd prefer to do this creative work with whatever tools I choose, but if you force me to never squash, I can still achieve the same creative output using other tools or by altering how I work. At no point were commits ever an actual history, they were always a presentation of the history the author chose to present.

(I've rambled on here, most of this isn't meant as a direct reply to you.)

Post reply on HN