Hacker News new | ask | show | jobs
by andi999 1835 days ago
Will read it, until now, for me,git feels like it tries to get in my way (probably because I think differently). I heard about fossil,(https://fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki) does anybody have experience with it? Does it suck less?
2 comments

I think there are 2 core principles governing fossil:

1) It wants to be the only tool you need to bring with you if you and your fellow developers are going to be stuck on a desert island. It’s not only version control, but also an issue tracker, and more recently a chat app.

2) It preserves everything you commit to it. Whereas git lets you polish your commit history before pushing, fossil keeps everything. You can’t alter your local history. All your messy scratch work can’t be cleaned up. It’s visible forever.

That second point is what turns me off to it, so I’ve stuck with git for personal projects. When I push up my local code, I like to have a very clean history.

Thanks. They really seem to have a bias against deleting (and not so good rationalizations):https://fossil-scm.org/home/doc/trunk/www/shunning.wiki

Apart from that, did you try it, and was it smooth?

I tried it just for an afternoon, but I did find it easy to work with.

I find git easy to work with too though, as long as everyone sticks to a well-defined workflow and doesn’t do anything weird.

Maybe that is the problem here, we do not have a defined workflow. Do you know of any good workflow sheet for git we can lift ideas from?
So if I understand correctly there’s no equivalent to git squash merging branches?
My experience with git is it's organically grown, and regularly a mess. It works reasonably well and in fact is better than a lot of alternatives, but can become a monster quickly and unexpectedly. My experience with mercurial was better than with git.

But none of this matters, as git/github/gitlab is today the industry standard, or even the category killer for version control. You will have to deal with it in one capacity or another. So my advice is to deal with git, learn at least up to medium level. As industry standards go, things could be a lot worse than git.

The main thing to know for newbies is as long as you don’t force push to a remote branch, it is safe. You are creating new state only, not destroying. All errors are Recoverable.
Even force pushing is not really a problem. If you don't want to keep every typo and braindead approach in history, force push is a required tool.

Naturally things go wrong occasionally, but garbage collection is not run often. You only need to know the SHA-1 and you can fetch "lost" commits again.

Old SHA-1s can be found in reflog. We also have all pushes automatically announced all in chat, so you can look up previously pushed SHA-1s in chat history (we use gitlab and zulip and those support it out of the box).

Of course you still need a mental model how git history (including history rewriting) works, othwerwise you cannot understand what exactly went wrong. And without knowing what went wrong fixing it gets awkward trial and error, which unfortunately many less experienced git users seem to do.

And don’t expect the command details to make sense. What you want to do is some simple thing in terms of a graph of states, and just google the command if you aren’t sure it it is origin/branch or origin space branch.
You can still easily lose uncommitted local state, which is unrecoverable, and also put the checkout into a state from which a newbie finds it hard to escape.