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

111–118 of 118 posts

Re: Things I just don't like about Git

#111

Post by professoretc »

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…

I use fossil as my daily driver VCS and I feel like it doesn't go far enough in it's ability to non-destructively amend history. The canonical justification for git-style rewriting is taking all the commits that make up some feature and smashing them down into one "implemented feature X" commit which, as far as I know (?), does not have an analogue in Fossil. Even something like forgetting to add a file to a commit requires an additional commit (and shows up as such on the timeline) with a silly "forgot to include file foo in commit whatever" comment.

Ideally there'd be some kind of "virtual commit" capable of (visually) bundling up a range of commits, with its own message and tags; maybe these could be nested so that you could have a hierarchical view of the timeline: initially you see "release X, release Y" but then you can expand any of those to "implemented feature A, B" which can be further expanded into the actual commits.

Re: Things I just don't like about Git

#112

Post by yowzadave »

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…

If this is true, do you think it would be possible to write a new UI for git that is compatible with git repositories, but more accurately (and intuitively) exposes those underlying concepts?

Re: Things I just don't like about Git

#113

Post by professoretc »

plorkyeran wrote: post #109
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…

History is only immutable once it's committed to Fossil, and anything not committed is lost forever. This may sound banally obvious, but I think it's fundamentally the problem with Fossil's approach. With git I essentially commit my entire undo/redo stack. I end up discarding most of that later, while with Fossil I would never have committed those intermediate versions in the first place. Without history rewriting, t…

Only if you choose to use it like that. I commit every minor detail in Fossil, even little things like "added TODO comment".

Re: Things I just don't like about Git

#114

Post by rstuart4133 »

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…

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

Many git users agree, including the kernel from memory. By that I mean there is often some git tree (maybe called "production", "main" or "master") were "fast roll forward" is the only style of commit accepted. Ie, on that tree, you can't change history. But when you're using git to built a commit to that tree, you are allowed (and in the kernel's case expected), to clean the history up, removing all your mistakes and experiments, so the people following the main branch don't have to wade through all that crap.

So the difference is git allows it to be a policy setting, whereas I take it Fossil forces it to be turtles all the way down.

Re: Things I just don't like about Git

#115

Post by rstuart4133 »

fouc wrote: post #99
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.

Linux seemed to loath svn with a passion. I really some comment from him like "they simply don't get it". With the benefit of hindsight, he was right.

But he did throw the baby out with the bath water. They got the data structures wrong, the overall concept skew whiff (a commit is the code at a point in time; how you got there is just meta data), but the higher level interface wasn't bad. He could have done worse than to base the porcelain command names on svn.

Re: Things I just don't like about Git

#116

Post by argulane »

danielovichdk wrote: post #68

Seems more like a rant where the author does not even show how he gets himself into the trouble is tries to describe. Rebase, merge, and submodules being good examples. Show what you are trying to do and it becomes a whole lot easier to understand. Who uses rebase often anyways ? Poorly written also imo.

I use rebase every day because fix typo commits are not useful and having good commit messages helps a lot with code review

Re: Things I just don't like about Git

#117

Post by begoon »

I’m always puzzled when people say than git is hard, confusing etc. Is English hard to learn? Russian? Chinese? It depends, as always.

Yep, it’s a learning curve, and as deeper understanding comes, in more ways you start bending this great tool (git).

There is an endless ocean of toolings, helpers etc of all kinds, for all levels.

I’m not saying git is the best. There is no the best tooling in general. Fossil is great, git is great, and some other VCS. Pros and cons are everywhere.

git is a battle tested software. Who argues?

Re: Things I just don't like about Git

#118

Post by pseudalopex »

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…

Subversion had plans to let administrators remove files or commits. Git inspired Mercurial's history editing.
Post reply on HN