Fossil vs Git • Hacker News Board

Re: Fossil vs Git

#81

Post by marktangotango » Sat, Jan 26, 2019, 4:57 PM UTC

afiori wrote: post #58

pferde wrote: post #52

Earlier quoted context omitted.

There is a difference between squashing together thirty commits of someone working on one concrete thing (I don't need to see all the mistakes and reworks you made, I just want to see the result in a nice, easy to read diff), and thirty commits of someone working on thirty things. The latter is, of course, wrong as it makes the repo history harder to read, while on the other hand the former improves readability.

It would be nice if in the first case one could annotate those thirty commits in a narrative "here I started another attempt", "this solution could not work for X,Y and Z reasons", "these 8 commits are just typos" maybe with also the ability to only select a subset of a commit.

Do you require this functionality and for people to write meaningful comments? I just question if version control is where any of this should happen.

Personally, how I tend to work is if there’s some link between commit and ticketing system I can refer to, it’s about the best you can expect.

Re: Fossil vs Git

#82

Post by dan-robertson » Sat, Jan 26, 2019, 5:01 PM UTC

u801e wrote: post #73

dan-robertson wrote: post #39

Earlier quoted context omitted.

I think git and hg are both pretty bad in different ways. Both have pretty terrible UI but so long as one uses magit, git comes out way on top. The data models are different and suffer different problems. A main issue with git is that it is stupid about file copies and renames. An issue with hg is that it doesn’t work well with long running forked histories (i.e. like git branches) because it stores the set of revisi…

> A main issue with git is that it is stupid about file copies and renames. Could you elaborate on this? As far as I know, file copies and renames will still use the same blob, but the tree referencing the blob can reference it using a different path in the case of a rename or reference it more than once in the case of a copy.

If you tell hg to rename a file, e.g. hg mv foo bar, it will generate a patch which essentially just says “foo was renamed to bar”, and when you look at the diff the only thing that has changed is the name.

If you merge this with a patch that changed foo then hg will do something sensible (ie either merge the changes into bar or give a merge conflict).

Git has no first-class concept of file name changes. Instead it tries to use heuristics to spot renames and sometimes they work and sometimes they won’t. Maybe if you merge a patch renaming foo to bar with one that changes foo the second patch will be applied to bar, but maybe it will behave as if you are merging changes to foo with deletion of foo.

Merging is already hard, dangerous, and non associative. The danger is less that you get lots of annoying merge conflicts than that you don’t get a merge conflict when you should (and therefore you risk accidentally changing the meaning of the merged files without knowing), e.g. if you merge “rename foo to bar” with “delete foo” and git didn’t spot the move then the merge might leave bar untouched when really there should be a conflict between keeping/deleting bar. Having wrong merges happen automatically can be a big risk when software is supposed to be very reliable.

Re: Fossil vs Git

#83

Post by nharc » Sat, Jan 26, 2019, 5:03 PM UTC

As someone currently working in a project where parts are managed with git and others with fossil, I have a strong preference towards git. One major issue with fossil is the non-existent ecosystem. It simply does not integrate well with other frameworks and tools (e.g. Yocto/OE). Migrating to git entirely would be much better for the team and workflow as a whole, but unfortunately the seniors who are using fossil are quite hostile towards git, for mostly political reasons. The irony is that they have big performance issues with fossil, precisely due to the fact that fossil records everything and the push/pull commands sync the entire repo, not just one branch.

Fossil also lacks an equivalent to git submodules, which should be added to the list of features found in git, but not in fossil.

Re: Fossil vs Git

#84

Post by SQLite » Sat, Jan 26, 2019, 5:04 PM UTC

kurtisc wrote: post #76

git-worktree seems to give git the multiple-checkouts feature. Also, this page seems to do the common but frustrating thing of advertising how something is implemented as a feature. I'm sure it's very interesting to the developers that it uses a database in the backend or that your side-project is written in a niche language but, as an end user, I just don't care.

Here is an attempt to clarify why I think implementation does matter: https://www.sqlite.org/whynotgit.html#git_makes_it_difficult...

When the design of a system makes something difficult, people tend to avoid doing that thing. The Git data design makes extracting some kinds of historical information difficult, with the result that many common tools (ex: GitHub) don't bother. This reduces the information available to users, resulting in reduced situational awareness.

I make no claim that Fossil is perfect in this regard. My only claim is that Fossil is better.

Whether you use Fossil or not, I don't much care. But I really would like you to understand some of the features of Fossil that (I think) make it better than Git, and perhaps start adding some of those features to your favorite VCS, be it Git or something else. Understand the general concepts, then port those concepts to other systems.

Re: Fossil vs Git

#85

Post by stavros » Sat, Jan 26, 2019, 5:10 PM UTC

anilakar wrote: post #9

Funny how they say that Git uses a "Bazaar-style development" process when Bazaar literally is another VCS. I'm also not convinced it's a good idea to merge your bug tracker and version control.

They don't mean bzr the VCS, they mean Cathedral/Bazaar.

Re: Fossil vs Git

#86

Post by heavenlyblue » Sat, Jan 26, 2019, 5:10 PM UTC

bluejekyll wrote: post #80

gugagore wrote: post #34

Earlier quoted context omitted.

I'm also a big fan of not deleting data. I don't like squashing commits, for example. But I also want to be able to see high-level intent. If instead of "squashing", it were "grouping", I'd be happy. I could encapsulate a bunch of messy commits that I made while I didn't know what I was trying to do. The intent would be clear at a higher level, but if you want to dig in to see what it actually took me to achieve that…

I sometimes go back and “group” commits with a ‘git rebase -i’ and squash commits that are related. Is that similar to what you’re talking about?

No, I believe what author is asking for is to keep those changes in git, but have git manage grouping of history logs for you.

E.G. you have worked in a feature branch, and committed 10 times - let those commits be kept in the log, but when running git log there must be a flag that allows for filtering based on how granular the output must be.

That can be done with rebase, but then you loose history.

I am pretty sure you can implement something like that in git based purely on commit message content.

Re: Fossil vs Git

#87

Post by jordigh » Sat, Jan 26, 2019, 5:13 PM UTC

gugagore wrote: post #34

jordigh wrote: post #13

I'm a big, huge fan of recording what should have happened instead of recording every typo and forgotten semicolon in your history. There's a difference between draft commits and published commits. When I'm reading published commits, i.e. history, I just want to know your intent, not your typos. So what are the tools that Fossil offers to make sure I don't have to see your typos in the history?

I'm also a big fan of not deleting data. I don't like squashing commits, for example. But I also want to be able to see high-level intent. If instead of "squashing", it were "grouping", I'd be happy. I could encapsulate a bunch of messy commits that I made while I didn't know what I was trying to do. The intent would be clear at a higher level, but if you want to dig in to see what it actually took me to achieve that…

You misunderstand me. Almost everyone does. I do not think you should squash all of your changes into a giant hairball commit, and I don't think first parent (which is effectively the same thing) solves this problem either.

I think each of your commits should be individually rewritten until each commit makes sense and tells a single, indivudal story that makes sense on its own, while at the same time be completely atomic and as small as possible.

You created a new function? That's one commit. Take a moment to explain why this function is going to be useful in future commits.

You called that new function from several new spots? That's another commit. Explain why each of these calling sites requires this function.

You decided that there had to be some style and whitespace changes? That's another commit. This one can go without explanation.

You found an old bug along the way that can be fixed with a one-line change? That's another commit. Hey, nice catch. Perhaps a few lines about this bug and why your small change fixes it?

Together, these are all individual scenes of a larger story. But the larger story doesn't need the behind-the-scenes of how you came up with these scenes. I don't need to see all your drafts of each scene. I just want the final scenes that make up the final story.

Re: Fossil vs Git

#88

Post by heavenlyblue » Sat, Jan 26, 2019, 5:15 PM UTC

Benjamin_Dobell wrote: post #59

nobody271 wrote: post #55

Earlier quoted context omitted.

I tend to commit, read my commit, and then find all kinds of mistakes and have to amend or redo the changes on a separate branch. If those options aren't available I just have a messed up commit history. This is all because git makes modifying your commit history very difficult to do. I think this immutable feature makes git worse because I have no intention of lying to myself or my team about my commit history. I wo…

Are you pushing the commits with errors? Are you merging the commits with errors? If both of those are true then this sounds like a process issue. Git makes it extremely easy to edit history, with the ability to amend any commit; even several commits back with simple CLI tools like `git rebase -i `. However , what it doesn't like you doing is ripping the rug out from other people i.e. editing history team members are…

What if my repository is linked to a CI process that deploys the live code? And tb change needs to be done “now”?

If you are working for a larger company where processes are clearly defined, then it’s good for you and that feature is not needed. But you are loosing all of the agile feature of git in the first place.

In my situation squashing history takes away my other ability to use git as a wiki of “things that didn’t work out”. It’s important to keep that.

Re: Fossil vs Git

#89

Post by Benjamin_Dobell » Sat, Jan 26, 2019, 5:23 PM UTC

Nullabillity wrote: post #78

nobody271 wrote: post #64

Earlier quoted context omitted.

Hmm, okay, I should learn how to rebase then. The biggest part of my problem is a total lack of commit discipline but there are times when I'm working on a branch where my commits don't tell a clear story (changed something then changed it back because I decided to do it a different way). That's when I most wish for better ways to tell that story. I feel like an idiot for not knowing rebase could solve some of this f…

That back and forth is the most important part of the story! It shows that you thought through multiple approaches to the problem, (hopefully) why they didn't pan out, and they give someone else a starting point for returning to that approach in the future. It isn't exactly rare that I go through the blame history on some project to find out why something was done in a way that seems stupid at first glance, just to g…

"back and forth" is not the same thing as "all kinds of mistakes".

No-one cares about stray keystrokes other developers make, it's just noise.

Yes, we absolutely care about the design of the software we're working on, and that's what commit messages, self-documenting code, comments, issue trackers and project management (planning session etc.) are all for.

When you squash commits in Git the default generated commit message is even to merge together all your previous commit messages. Now is your chance to look at those old messages and change "Did X" to "Attempted X, but didn't work because Y".

When I'm investigating when and why some code was implemented the way it is; I don't want to look at a Git blame trying to find when something was changed, just to see that the most recent change was reverting some earlier messing around. Just to git blame again starting from just prior to said messing around, just to see the same thing again - noise is bad!

Re: Fossil vs Git

#90

Post by jtms » Sat, Jan 26, 2019, 5:23 PM UTC

fxfan wrote: post #2

I'm surprised git caught on despite mercurial being much superior (hadn't heard of fossil before). Git has the following shortcomings which are major (some shared by other VCS too) 1) UI- terrible, terrible UI 2) Unncessarily complex data model 3) Doesn't scale well to large repos (until Microsoft's VFS- windows only) (and many others...)

>Unnecessarily complex data model

I have been using git since it was released and have never needed to think about its underlying data model in order to accomplish dev tasks. Also I suspect that any complexity in the data model was quite necessary to implement its api and features in a performant way.