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

181–190 of 252 posts

Re: Fossil vs Git

#181

Post by pseudalopex »

joshka wrote: post #173

> 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, bu…

Git's linear presentation of history encourages rebasing or squashing. Mercurial keeps the branch structure, which has the advantages of both squashed and unsqusahed commits.

Re: Fossil vs Git

#182

Post by jordigh »

atombender wrote: post #174
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…

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

Untangling is what I mostly do. I consider the untangling my own internal code review. I need to read my own diff and figure out what goes where and what each part does and why it's necessary. My commit messages are then my own code review comments.

I figure if I don't carefully read my own diff, why would anyone else? And once it's untangled, I am hoping others will find it easier to read too.

Git doesn't provide as many tools as I would like to make this process easier. It's partly why I don't use git. Mercurial's absorb command helps a lot: it absorbs changes from your working directory into the appropriate draft commit that corresponds to the same context:

https://gregoryszorc.com/blog/2018/11/05/absorbing-commit-ch...

Wait, it appears someone finally ported it to git:

https://github.com/tummychow/git-absorb

Re: Fossil vs Git

#183

Post by LukeShu »

rkeene2 wrote: post #155
LukeShu wrote: post #152

Earlier quoted context omitted.

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

I usually agree with that. The projects I was referring to are either Go (where the norm is to check in code-gen'ed files, so that things are `go get`able), or static websites (where every commit will get rolled out as soon as you push it).

Re: Fossil vs Git

#184

Post by slavik81 »

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…

What I ended up doing before git is having multiple workspaces and copying completed changes from my messy workspace to the clean workspace and commiting from there. Git's partial commit feature just made it a lot easier to do what I was already doing.

Re: Fossil vs Git

#185

Post by owstr »

eesmith wrote: post #136
dymk wrote: post #71

Earlier quoted context omitted.

Fossil is posted to and discussed on HN all the time. It's a novelty, it differs in design from the popular tools that people actually use in their day-to-day jobs. There's really no reason to think that Fossil is used internally at a rate higher than its public-facing usage. And I've literally never seen a project that uses Fossil aside from Fossil examples.

"All the time"? I counted about one HN posting per month. From https://news.ycombinator.com/from?site=fossil-scm.org there are 20 links to fossil-scm.org in the last 2 years. I manually looked at the last 2 years of submissions with "fossil" in the name and found an additional 4 which were not to fossil-scm.org. It's over 50% higher for Mercurial. I counted about 30 postings with the name 'Mercurial' over the last tw…

Also Fresh IDE[0] using Fossil and flat assembler g.[1]

[0] https://fresh.flatassembler.net/fossil/repo/fresh/index [1] https://flatassembler.net/fossil/repo/fasmg/home

Re: Fossil vs Git

#186

Post by slavik81 »

mannykannot wrote: post #180
cryptonector wrote: post #165

Earlier quoted context omitted.

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…

When I worked with VCS that couldn't rebase, my strategy was simply to not commit until everything was perfect. I had a local branch. It was just not version controlled.

When I later started using git, my workflows simply became safer and easier.

Re: Fossil vs Git

#187

Post by pseudalopex »

garmaine wrote: post #112
heavenlyblue wrote: post #86

Earlier quoted context omitted.

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…

There is no theoretical reason you can’t maintain two histories—-e.g. when rebasing have a “rebase-merge” commit that has the hash of the other tree, and optionally keep that history around in the git repo. Then you could do a ‘git blame —orig’ or whatever to switch between immutable and cleaned up history. No VCS I’m aware of supports this. But they COULD.

Your suggestion is more flexible, but a simple way to group commits is to preserve the original branch structure like Mercurial.

Re: Fossil vs Git

#188

Post by StreamBright »

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 cant even remember the last time I was looking at a commit in git or any other source control system. I usually look at pull requests and what has changed.

Example files changed view in Github:

https://github.com/TechEmpower/FrameworkBenchmarks/pull/4311...

Re: Fossil vs Git

#189

Post by markmark »

jordigh wrote: post #120
funkaster wrote: post #115

Earlier quoted context omitted.

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.

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'm not sure about "scale" but Linux, as an open-source project where external actors want their code included, can push arbitrary amounts of work onto those actors with no additional cost to itself.

They can say "to get your code upstream you have to do twice as much work" or 3x or 4x or whatever. It's not their cost to bear.

An internal team pays that cost. They have to consider whether the trade off of having a pristine commit history is worth the additional overhead of doing it.

I personally care more about PR size and am happy to squash all commits in a PR. If that is too big I'd rather see multiple smaller PRs.

Re: Fossil vs Git

#190

Post by joshka »

pseudalopex wrote: post #181
joshka wrote: post #173

> 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, bu…

Git's linear presentation of history encourages rebasing or squashing. Mercurial keeps the branch structure, which has the advantages of both squashed and unsqusahed commits.

I use the following fairly regularly (aliased):

    git log --graph --oneline
I can understand how you could see this as an advantage, but I see forcing this on the developer as more of a disadvantage. I literally never want to see in any history commits with junk attempts to fix something. After the fact, these are the least interesting things to me.
Post reply on HN