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

71–80 of 118 posts

Re: Things I just don't like about Git

#71

Post by SQLite »

danShumway wrote: post #49
sgbeal wrote: post #39

Earlier quoted context omitted.

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

> 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…

Yeah - I'm very much about maintaining an immutable record. That is why, back in 2006, I started designing Fossil to control SQLite, instead of just switching to Git.

I think that proper version control should be immutable. If history is changeable, what's the point in having history at all? It ceases to be "history" and becomes just a fable or hagiography.

Mistakes happen, and it is important to be able to correct them, which Fossil does do. In many ways Fossil's mistake-correction logic is far better than Git's. If you make a check-in to the wrong branch, you can move it after the fact in Fossil. If you check-in with the wrong user-id, or a with a goofy check-in comment, you can edit those too. Was your system clock wonky when you did the commit, resulting in a bad timestamp on the check-in, that too can be fixed. I say "edit" - really you are not modifying the original check-in at all. The original check-in is immutable. But Fossil supports the ability to add correction records (tags) on top of check-ins. The original history is preserved and you can always drill down to find out exactly what happened. But for routine day-to-day usage, only the corrected values are shown on displays and reports. So it is like being able to change history, except that you are left with an audit trail.

This is how accounting and legal systems work. You never erase - you only add corrections.

Re: Things I just don't like about Git

#72

Post by fanf2 »

gavinhoward wrote: post #47
codetrotter wrote: post #9

Earlier quoted context omitted.

Will your VCS be compatible with git pull, git push, and the file format on disk used by git?

No. I'll be using SQLite and weave files in order to handle massive amounts of data (terabytes or more) while having full transactions.

How do weave files cope with history diverging across copies, moves, and deletes? How do they handle file/directory conflicts across different branches?

Re: Things I just don't like about Git

#73

Post by rascul »

hotnfresh wrote: post #3
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.

> I'd love to hear more about what people hate about Git. It's not implemented as a single portable library. This makes embedding or driving git from other programs—a thing I've wanted or needed to do several times in my career, so I'm pretty sure it's really common —suck a lot more than it needs to.

Have you looked into libgit2?

https://libgit2.org/

Re: Things I just don't like about Git

#74

Post by UweSchmidt »

gavinhoward wrote: post #43
UweSchmidt wrote: post #34

Earlier quoted context omitted.

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.

I agree. You laid out my current design in a nutshell, actually. Except for folders. But my branches will be more than a bookmark.

In your design, can I go to the other "branch/folder" and look around / copy over that binary to my current "branch/folder" in a file explorer without a "checkout"?

Re: Things I just don't like about Git

#75

Post by fanf2 »

Forge36 wrote: post #60
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.

Not all git commands consult .mailmap when they should, so it’s a very leaky and incomplete way to address the problem.

Re: Things I just don't like about Git

#76

Post by rwmj »

x0x0 wrote: 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…

Just wait until you bisect in a tree that contains a submodule, forget the mandatory manual update step, and your day long bisection is wasted.

If you have to bisect across commits that added or removed a submodule you might as well give up now.

Re: Things I just don't like about Git

#77

Post by Macha »

CableNinja wrote: post #51
miohtama wrote: post #6

Earlier quoted context omitted.

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.

Define popularity? SVN was still the majority platform because Sourceforge and Google Code were the most popular publicly accessible project hosting platforms. A lot of the self-hosted projects were still on CVS repos, often without anonymous access, so you'd just get tarballs of the source code with releases as a non-contributor. My memory is definitely that github adoption drove git adoption by basically its code first approach being more appealing to developers than Sourceforge/Google Code's project first approach.

Later on stuff like git-flow came along which also helped people have a process to migrate to (even if it's poorly suited for the development patterns software projects were already migrating to at the time).

Re: Things I just don't like about Git

#78

Post by paradox460 »

domador wrote: post #54
miohtama wrote: post #6

Earlier quoted context omitted.

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…

When GitHub was the new kid on the block, it's competition was largely Google code and source forge.

Google code was svn and git. Source forge was the same, but also had CVS.

Re: Things I just don't like about Git

#79

Post by danShumway »

SQLite wrote: post #71
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…

Yeah - I'm very much about maintaining an immutable record. That is why, back in 2006, I started designing Fossil to control SQLite, instead of just switching to Git. I think that proper version control should be immutable. If history is changeable, what's the point in having history at all? It ceases to be "history" and becomes just a fable or hagiography. Mistakes happen, and it is important to be able to correct t…

Which is fine for someone to have as a perspective, I just think that philosophy is far too limiting for a universal VC system and misses the point of what many people use VC for.

It's not so much "the people who are designing Fossil are bad at designing it" as much as it is "I disagree with their starting premises and their goals for the thing they're building." If someone comes to me and asks why they would want to use Git over Fossil, the primary thing I would point at is:

> This is how accounting and legal systems work. You never erase - you only add corrections.

I just personally think that can be in many situations an unhelpful way to think about what a VC is at a fundamental level; I don't think a VC is inherently an accountability system or a legal system, and I think that having that rigidity can get in the way of certain workflows. Again, opinion me, I know you're quite happy with Fossil for SQLite, and that's great and I'm sure it works great. It's not like it's bad to have opinionated tools, I just think that it gets in the way of treating Fossil as something I would recommend as a general Git replacement for everyone.

It comes down to: is the ability to rewrite "history" (which is not even really history at all in Git, it's just a collection of ordered changes) a feature or a problem? Fossil thinks it's a problem, I think it's a feature. Fossil looks at repository history like a historical record, I look at repository "history" as purely an organizational tool for checkpointing/documentation.

Re: Things I just don't like about Git

#80

Post by gavinhoward »

UweSchmidt wrote: post #74
gavinhoward wrote: post #43

Earlier quoted context omitted.

I agree. You laid out my current design in a nutshell, actually. Except for folders. But my branches will be more than a bookmark.

In your design, can I go to the other "branch/folder" and look around / copy over that binary to my current "branch/folder" in a file explorer without a "checkout"?

Not in a file explorer, sadly.

However, I was going to make a browser UI from the start. I could implement a branch and file explorer in that UI, which would allow you to do the same thing.

Would that be good enough or not? I'd love to know because I want to build this tool for humans first.

Post reply on HN