Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fossil vs Git

fossil-scm.org

Post reply on HN
Print view View original

171–180 of 252 posts

Re: Fossil vs Git

#171

Post by cryptonector »

SQLite wrote: post #72
donatj wrote: post #17

Earlier quoted context omitted.

> 2) Unncessarily complex data model Hmm? It’s just a directed graph of SHA1s under the hood. Seems pretty simple to me once you understand that. My understanding was that Hg’s data model is actually way more complicated with more pointers. As everyone else is chiming in, the reason git won was speed. I haven’t used mercurial in a few years but at the time when I was looking to replace SVN, git did everything seconds…

Perhaps the OP is referring to this: https://www.sqlite.org/whynotgit.html#the_mental_model_for_g...

The Git index is one of its most powerful features. Try doing a `git add -e` sometime. You get to do a bunch of work in the workspace then split it up usefully at commit time.

Re: Fossil vs Git

#173

Post by joshka »

> Git puts a lot of emphasis on maintaining a "clean" check-in history.

This seems like an inaccurate phrasing of this. Git (the tool) doesn't specifically emphasize this, but it does support this as a possible approach without excluding the other approach. Many teams have settled on development approaches with git that do indeed emphasize this, but not every team does. If you want to show your work, you sure can, but unlike fossil, git does not force this upon developers. Like the article, I don't see either approach as right or wrong, but know that I prefer the clean history approach rather than every typo commit ever.

Re: Fossil vs Git

#174

Post by atombender »

jordigh wrote: post #87
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…

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

Ideally it should be this way, but it's impractical in reality.

It requires that you either stop your development workflow to commit as you go along, or that you untangle all the pieces after they're already entangled.

If you commit as you go, it's an expensive mental switch to fire up git and also run all the tests (since surely part of this workflow is to apply the principle that no commit should ever break the build). You also take an extra productivity hit every time you change your mind about something a little later (e.g. you added the function getFoo() but realize it should have been called findFoo()).

If you work for a while and then try to bundle up small, atomic changes, that can also be very difficult. Tools like git group together contiguous chunks of changes when committing, and prying them apart later can be difficult. I often do this with a combination of "add -p" and then "stash save -k" to temporarily get rid of things unrelated to what I'm committing, but it's a chore. During a selective "add -p" session you have to mentally keep track of what belongs together, thus what dependencies are between every chunk you're adding.

Committing as you go is easier, but it's slow, and doesn't work well when you're working across many files with a big change that introduces new semantics in a lot of places. Both techniques require that you keep track mentally of which parts are related, of course.

Re: Fossil vs Git

#175

Post by sigzero »

rkeene2 wrote: post #151
sigzero wrote: post #61

Earlier quoted context omitted.

Yeah, it's probably not "widely" used. I know the Tcl dev team uses it for Tcl and Tk. That's pretty much the only one I know. There is a online hosting service: http://chiselapp.com A list of public projects (I was kind of surprised there were so many): http://chiselapp.com/repositories/

I run ChiselApp.com if there are any questions about it. I inherited it from James Turner, the creator of it.

Are all the user projects running version 1.34 (2.7 is the latest) or just the fossil hosting itself?

Re: Fossil vs Git

#176

Post by patsplat »

funkaster wrote: post #115
jordigh wrote: post #87

Earlier quoted context omitted.

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

that doesn't scale. I personally prefer a single squashed commit linking to a full discussion in a PR/MR: do a git blame, even if you get a giant hairball commit, you should be able to trace it to a review process (PR/MR) where it was discussed and thoroughly reviewed.

Not sure why this was down voted. Squash’n’Merge on Pull Request keeps master history clean while tolerating sheninagins on feature branches.

If important things are lost then perhaps the PR was too large.

Re: Fossil vs Git

#177

Post by joshka »

> The ability to show descendents of a check-in.

This is interesting. I wonder if the same thing could be achieved fairly simply in git though by keeping an extra area in the .git folder that handles reversing / denormalizing the DAG for some of the things that these reports show.

Microsoft are innovating in this area (bringing the improvements that they have in VSTS to the client). There's a good series of blog posts on this at https://blogs.msdn.microsoft.com/devops/tag/git/ (first article https://blogs.msdn.microsoft.com/devops/2018/06/25/superchar...)

Re: Fossil vs Git

#178

Post by jordigh »

peteforde wrote: post #146
jordigh wrote: post #87

Earlier quoted context omitted.

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

While I am following this conversation closely, I wanted to politely make a suggestion about something you said: "You misunderstand me. Almost everyone does." That sounds really frustrating. It's not clear from your post whether you mean this as "everyone who reads this comment does not understand me" or "people frequently misunderstand me"... but typically, someone who feels this way experiences this in the latter,…

Yes, I know I'm not communicating effectively. I shouldn't have implied that everyone is wrong but me. I know that there are people who understand me, but in a world of github and pull requests, it's really hard for me to explain what the world looks like otherwise.

Re: Fossil vs Git

#180

Post by mannykannot »

cryptonector wrote: post #165
mannykannot wrote: post #42

Earlier quoted context omitted.

One should not have to choose - the history of complete units of work should be an abstract view of the detailed history.

So the abstract view should be useful and free from noise, but you want to be able to get at the noise anyways. But to what end? What's it to you if I typo and make other silly errors during development? What if I never commit until I'm done? If I never commit until I'm done you will not see my mistakes, but if there's nothing like `git add -e`, then I won't be able to split up my commits logically and so the upstrea…

I haven't looked into Fossil into enough detail to know if your objections are valid complaints about the way it does things, but they are not objections to the principle that I set out in in my original post.

If you have to rewrite the actual history to get what you call a 'clean' history, rather than just overlay the detailed history with a sparse abstract lattice joining the key points, then it is not a history at all. This could be a problem if you need to do a post-mortem analysis, or if you make a mistake in the rewriting of the history.

I tend to regard frequent extensive rebasing as a process smell - not necessarily a problem, but a warning that there might be one.

Post reply on HN