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

151–160 of 252 posts

Re: Fossil vs Git

#151

Post by rkeene2 »

sigzero wrote: post #61
aboutruby wrote: post #47

Always surprises me how Fossil is popular on HN but very much not outside a few projects (e.g. sqlite)

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.

Re: Fossil vs Git

#152

Post by LukeShu »

randallsquared wrote: post #124
jlebar wrote: post #94

Git: One check-out per repository Fossil: Many check-outs per repository git allows multiple checkouts per repo. Official docs (good luck): https://git-scm.com/docs/git-worktree Random person's blog that explains it more clearly: https://www.saltycrane.com/blog/2017/05/git-worktree-notes/

I have no idea what use case is satisfied by git worktree, based on that blog post. In the case that you desperately needed to have two branches checked out, why not just clone twice?

A workflow in a few projects I work with:

Have a "develop" branch that does not contain any generated files, and a "master" branch that does. Have a post-commit hook that uses a worktree pull every commit from "develop" to "master" and generate any files.

That type of workflow is possible by cloning the local repo, but is kludgey and brittle enough prior to worktrees, I had never considered that workflow viable.

Re: Fossil vs Git

#153

Post by rwbt »

miguelmota wrote: post #121

That comparison table made me dislike fossil even more. Fossil took something that’s not broken, and broke it.

I disagree. I would suggest you to atleast research it more before coming to such strong conclusions.

Re: Fossil vs Git

#155

Post by rkeene2 »

LukeShu wrote: post #152
randallsquared wrote: post #124

Earlier quoted context omitted.

I have no idea what use case is satisfied by git worktree, based on that blog post. In the case that you desperately needed to have two branches checked out, why not just clone twice?

A workflow in a few projects I work with: Have a "develop" branch that does not contain any generated files, and a "master" branch that does. Have a post-commit hook that uses a worktree pull every commit from "develop" to "master" and generate any files. That type of workflow is possible by cloning the local repo, but is kludgey and brittle enough prior to worktrees, I had never considered that workflow viable.

I usually leave release engineering tasks such as denormalizing data (generating derived files) to release time and Fossil has a particular place to keep these bits, as unversioned artifacts (which are optionally synced, on a per repository basis).

Re: Fossil vs Git

#157

Post by cryptonector »

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 want clean, linear history in my upstreams. Always. You can leave pointers to your work branch(es), and even use a second parent commit in commits for this, but no actual merging, always rebasing, and always preserving clean, well-broken-up commit history.

Re: Fossil vs Git

#158

Post by cryptonector »

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…

I don't care about how many typos you made while developing a thing. I only care about your upstream's history not getting re-written, but I don't care to see your dev history -- it's a distraction at best.

Re: Fossil vs Git

#159

Post by pm90 »

Pxtl wrote: post #148
marktangotango wrote: post #44

Earlier quoted context omitted.

How often dou you actually look at this historic detail you seek to maintain? Daily, weekly, monthly? Is it more for to satisfy a feeling than an actual need? I mean if some junior dev wallows on some branch for 40 commits, I don’t want to see any of that, I just want to see what was finally merged.

I'd rather have it and not need it than need it and not have it. Besides, squashing means the identity of the commits changes, doesn't it? So you can't merge the same branch into 2 different branches (like merging a bugfix into both the release branch and the trunk) while keeping the identity of the commits - then when you merge your release branch into your device branch you get wonky duplication of commits in the h…

> I'd rather have it and not need it than need it and not have it.

But squash commits do let you locate the identity of the authors. You just have to look at the PR, where all the original commits are listed

Re: Fossil vs Git

#160

Post by chousuke »

maksimum wrote: post #134
jordigh wrote: post #120

Earlier quoted context omitted.

It scales quite well. Linux itself is developed in this way. Or perhaps you think Linux isn't at a large enough scale? (No sarcasm, I know that there projects out there much bigger than Linux.)

I think the extra work for a single developer to perform atomic commits is justifiable. How does this work with multiple developers working on the same repo? I'm assuming everyone should work on their own feature branch and send PRs once their branch is done? Should the commits also be tagged by the feature branch they're on? Should the CI approval workflow be run against any combination of commits on the feature bra…

With git, I think it helps to think of development in terms of patch series.

An individual commit is a single patch, intended to do one thing (and hopefully do it well), and a feature branch is a patch series.

A pull request is then a request to review the series. If you need to change things, git allows you to rewrite your commits to send in a revised set of patches.

Before merging, your CI would create a temporary branch off the current master, merge your feature branch to that, and run tests against the result. I don't think testing individual commits (fully, at least) in a series makes much sense if you're going to merge all of them to master anyway.

Post reply on HN