Hacker News Reader

Comment by petre | Hacker News Reader

Because it gets the job done without needing to check the manual every time. We use fossil to manage most of our company code. It's stupid easy to set up, it has a web UI, it has a simple bugtracker, a wiki and a bunch of other stuff. It's fully replicated, we have backups on each repo that somebody is working with and is in sync. We don't bother with git unless we publish something on github.

View on HN

Do you use any kind of CI/CD pipeline process at all? Pretty much every significant CI platform that I know of is Git-native, or in some cases MAY have some legacy Mercurial support.

If I'm having to give up CI, or hand-roll my own pipeline system completely from scratch, then that's just an unacceptable trade-off. For a personal toy project, fine. But this seems like ridiculous bikeshedding for a professional shop in the 2020's. "Without needing to check the manual every time"? Sheesh, there are really only a few Git commands that most developers ever have to run on a regular basis anyway, and usually an IDE abstracts those.

It's easy nowadays because it's popularity forced everyone to build integration. Git is a absolute nightmare to integrate with CI tools though if you actually have to develop the integration yourself. Git has no native way to reliably tell you what you actually worked on in a branch. Yes it has git diff but that is not precisely the same, and git log is A. not easy to consume B. unreliable since git has so many methods to rewrite history. If you're using something like GitHub it's obviously much easier to use their API but even that is quirky sometimes.

That's my point. Most shops do NOT want to develop their on CI pipeline systems from scratch. I don't care if Fossil makes that theoretically easier, I don't want to do that at all. I want to use a Gitlab CI, or a Circle CI, or hell even a Jenkins. Git has that available ecosystem. No other serious competitor does.

Theoretically, it might be easier to weave your own cloth and then tailor pants from scratch, if you use some novel synthetic fiber rather than cotton. But I don't want to weave my own cloth and tailor my own pants, so I wear cotton blue jeans.

> Git has no native way to reliably tell you what you actually worked on in a branch. Yes it has git diff but that is not precisely the same

I'm not sure exactly what you mean by "what you actually worked on". If you want the files that changed a git diff between the tip of your branch and merge base of the target branch is usually sufficient.

> and git log is A. not easy to consume

You can customize the log format to make it easier to consume

> B. unreliable since git has so many methods to rewrite history.

I'm not sure what that has to do with CI/CD. But if that is somehow a problem for you, then just don't allow rewriting history. Every git server software I'm aware of supports rejecting pushes that rewrite history.

Reply on news.ycombinator.com