Comment by somat | Hacker News Reader

Comment by somat | Hacker News Reader

Parent Full thread

I use the heck out of fossil and have little idea how it works underneath. I consider fossil the gold standard for a good versioning system ui. I don't think git has any excuse for being as weird as it is.

fossil init repo; make a new fossil repository

fossil open repo; open a fossil repository somewhere

fossil add file; note: very different than git add. in fact I was very confused by git add, in fossil the repository knows what files are managed by it and there is no staging area. so you only use "fossil add" when adding a new file. If you move a file use "fossil mv" to let fossil know what you did. Along with "rm" when you remove a file. The staging area still feels like an unnecessary added bit of friction.

fossil commit

There are others I use often "merge", "sync", "revert" but they tend do what the command appears to do. Speaking of revert, the git equivalent is really strange , even among the rest of the strange git ui. Shit! I messed something up and want to revert back to the last committed change, easy, just run the command "git reset --hard HEAD"

The bad thing is that fossil allows the upstream to make destructive changes to client's copy of code. That's a big no no.

Until you need it. :)

So does git, in fact, without a better explanation of what exactly you mean, I would say upstream making changes to the the clients code is the core useful property of a version control system.

How do you choose which changes go into a commit and which don't without an equivalent of a staging area?

I don't use git a lot, so I am not all that familiar with it's work flow. But I think fossil assumes a change will go into the commit so you use the stash command to hide items you don't want in. while git assumes a change does not go in a commit so you use add on files that you want in.

A bigger question is what to do when you only want specific chunks from the diff in your commit. I tend to faff around with stash, interactive sdiff and hand editing the patch when I need to dissect a chunk, a situation I feel could be better.

Emacs/Magit can do that sort of things easily. You can mark a region in a diff and add that to staging if you want.

Magit is probably the best chrome for Git I personally think.

git init .

git add file

git commit -am "my message"

Pretty simple really. You don't need to think about staging if you don't want to.

Is that a typo or intentional? If you did git add, you don't want commit -a, right?

I believe these were supposed to map to what its parent comment has listed.

"git add" is used in this context to add an untracked file (like the fossil example).

git init .

vi file (initial content)

git add file

git commit -am "first commit"

vi file (make changes)

git commit -am "second commit"

Basically if you use commit -am, you never have to worry about staging - which is most of the time imo. In the rare case where you want to avoid committing something that has changed use git add to stage individual files.

Reply on news.ycombinator.com