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

81–90 of 118 posts

Re: Things I just don't like about Git

#81

Post by Buttons840 »

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…

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 this thread linked to jj [0], an alternative git client that does some pretty weird things. For example, it replaces the working tree with a working commit and commits quite often. I like git and that seems weird to me, but I'm not offended, people can do what they want on their own computer and I have the tools to ensure repos under my control are not affected. That's all I can hope for, and I'm happy that jj makes git more usable for some people.

[0]: https://github.com/martinvonz/jj

Re: Things I just don't like about Git

#82

Post by hotnfresh »

rascul wrote: post #73
hotnfresh wrote: post #3

Earlier quoted context omitted.

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

1) It’s not at feature parity,

And

2) It’s not the official implementation, so using it is committing to debug and work around divergence between it and actual git, probably after production or otherwise in-use data have been messed up.

Re: Things I just don't like about Git

#83

Post by sgbeal »

danShumway wrote: post #79
SQLite wrote: post #71

Earlier quoted context omitted.

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…

> I just personally think that can be in many situations an unhelpful way to think about what a VC is at a fundamental level;

The Devil's Advocate in me feels compelled to point out that git is (to the very best of my fallible knowledge) the _only_ SCM in history to permit rewriting of history. Certainly SVN, CVS, and their predecessors did not get it all wrong by not enabling editing of history?

Admittedly, rebase/squashing/etc. is _necessary_ for a Linux-kernel-scale project, but 99.99+% of software projects are, in terms of the number of contributors/contributions, so far removed from that scale as to not even register on that scale.

Re: Things I just don't like about Git

#84

Post by gavinhoward »

fanf2 wrote: post #72
gavinhoward wrote: post #47

Earlier quoted context omitted.

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?

History diverging is only a problem if the same branch is different across different checkouts. Since Git's branches are a bookmark, this is a problem for Git.

My tool has full branches, and your master branch is considered a different branch than the default master of the origin remote.

And to handle them across branches, each branch will have its own weave file, rooted at a parent. (There will be some optimizations.)

Re: Things I just don't like about Git

#85

Post by sgbeal »

aeurielesn wrote: post #57
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.

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

To summarize, his (Richard Hipp's) definition of freedom is "being able to take care of yourself." That includes reducing third-party software dependencies to the absolute minimum (e.g. libssl is not something he wants to reimplement... though we have (very) idly tossed the idea around ;)).

Re: Things I just don't like about Git

#86

Post by Buttons840 »

sgbeal wrote: post #83
danShumway wrote: post #79

Earlier quoted context omitted.

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…

> I just personally think that can be in many situations an unhelpful way to think about what a VC is at a fundamental level; The Devil's Advocate in me feels compelled to point out that git is (to the very best of my fallible knowledge) the _only_ SCM in history to permit rewriting of history. Certainly SVN, CVS, and their predecessors did not get it all wrong by not enabling editing of history? Admittedly, rebase/s…

Last time I used SVN I rebased all the time, no problem. I was using a git-to-svn bridge though. My point is, people will rewrite history on their own computer whether you want them to or not. Git is the only VCS that doesn't fight against that fact.

Re: Things I just don't like about Git

#87

Post by UweSchmidt »

gavinhoward wrote: post #80
UweSchmidt wrote: post #74

Earlier quoted context omitted.

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.

Probably, yes. Anything that does not require thinking in current Git-logic. I don't mind Git that much in everyday work but if something nicer came along, that would be great.

I do think that Git is very well established, and it would probably take a major player, maybe Azure or AWS with a cloud-based IDE to change paradigms.

Re: Things I just don't like about Git

#88

Post by danShumway »

sgbeal wrote: post #83
danShumway wrote: post #79

Earlier quoted context omitted.

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…

> I just personally think that can be in many situations an unhelpful way to think about what a VC is at a fundamental level; The Devil's Advocate in me feels compelled to point out that git is (to the very best of my fallible knowledge) the _only_ SCM in history to permit rewriting of history. Certainly SVN, CVS, and their predecessors did not get it all wrong by not enabling editing of history? Admittedly, rebase/s…

> The Devil's Advocate in me feels compelled to point out that git is the _only_ SCM in history to permit rewriting of history. Certainly SVN, CVS, and their predecessors did not get it all wrong by not enabling editing of history?

There are a lot of reasons I don't use SVN and CVS, but correct, their branch model is one of them. I do think that Git's restructuring of how commits and branches work and the flexibility around them is one of the reasons its better than older VC systems.

I'm not sure how strict those older VCs actually were, I'm less familiar with them than I am with Git/Fossil, but... yeah I have no problem saying that if they were doing fully immutable history they were wrong to do so (or maybe "wrong" isn't the best term to use, more that it would be an attribute that I think would make them less useful to a lot of developers).

> 99.99+% of software projects are, in terms of the number of contributors/contributions, so far removed from that scale as to not even register on that scale.

I would disagree with this, I think rebasing/squashing is just a really useful tool, even for smaller projects. It's sort of a difficult debate to have because it's mostly going to come down to opinion. What does necessary mean in a smaller project, VC itself is not strictly necessary for many smaller projects.

SQLite gets by fine with Fossil, the developer prefers having an immutable history. But I'm not sure what to say other than that I use rebasing a lot. Different projects have different development styles.

Re: Things I just don't like about Git

#89

Post by danShumway »

martinvonz wrote: post #70
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…

Jujutsu/jj ( https://github.com/martinvonz/jj ) keeps most of Git's data model and tries to improve the UX. It can even be used with existing Git repos.

Thanks, will take a look.

Re: Things I just don't like about Git

#90

Post by fanf2 »

sgbeal wrote: post #83
danShumway wrote: post #79

Earlier quoted context omitted.

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…

> I just personally think that can be in many situations an unhelpful way to think about what a VC is at a fundamental level; The Devil's Advocate in me feels compelled to point out that git is (to the very best of my fallible knowledge) the _only_ SCM in history to permit rewriting of history. Certainly SVN, CVS, and their predecessors did not get it all wrong by not enabling editing of history? Admittedly, rebase/s…

Other version control systems don’t give you tools to manage your work while it is being prepared and reviewed, before it is committed to the shared repository. That is when much of the rewriting happens.
Post reply on HN