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

221–230 of 252 posts

Re: Fossil vs Git

#221

Post by pseudalopex »

cryptonector wrote: post #205
pseudalopex wrote: post #181

Earlier quoted context omitted.

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.

Merge commits stop being interesting when you have thousands of people working on a codebase and you have tens or hundreds of thousands of branches. At that point clean, linear history is much, much simpler to understand.

If you mean a squashed history, I agree. At that scale I think the advantages outweigh the disadvantages.

Re: Fossil vs Git

#222

Post by jordigh »

Ajedi32 wrote: post #218
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…

I mostly agree with you, but I think this might be going a little too far: > You created a new function? That's one commit. Take a moment to explain why this function is going to be useful in future commits. > You called that new function from several new spots? That's another commit. Explain why each of these calling sites requires this function. In my opinion each commit should make sense on its own. It doesn't rea…

Maybe. I think both ways can make sense, and if you insist on having the function and the calling sites in the same commit, that can make sense.

I think my proposal can also make sense because (1) it splits up the commits into two units that still keeps the codebase in a stable state [this is my rough metric for what "atomic" means] and (2) defining a function requires some independent contemplation about why that function is defined that way. Inserting that function into calling sites can be a logically distinct operation if the calling sites are varied and distinct enough to each have a different reason to now require this function.

Thus the two commits can be semantically distinct.

Re: Fossil vs Git

#223

Post by blahblahblogger »

Groxx wrote: post #198
Benjamin_Dobell wrote: post #103

Earlier quoted context omitted.

Would it not be significantly more frustrating if you use git blame and you see: > Revert: Some WIP didn't work out. Git blame again from prior to that commit. > Added missing semicolon. and again : > Fixed spelling. and again: > Stupid typo, wrong method call. and again: > WIP, going to see if X can work. Before running git blame once more, finally getting to the commit message that actually pertains to the current…

fwiw this is largely what `git log -L` (and maybe `--follow`) solves. You can log changes to a file or lines in the file and have it follow through moves. Granted, most tools don't make that easy to do. But most Git tools are rather blind mimics of simple CLI commands with a nice UI (which can be a huge help), rather than being value-adds in terms of behavior or understanding.

Can you explain this a bit more?

Re: Fossil vs Git

#224

Post by cryptonector »

millstone wrote: post #219
cryptonector wrote: post #215

Earlier quoted context omitted.

I very much like features like built-in wiki (which is trivial to do in Git anyways, using either a separate branch or a separate repo with a named derived from the base repo), built-in issue tracker (this is harder to do in Git, though there exist projects that do it), built-in code review, ... Still, I've worked with codebases sized in the hundreds of millions of lines of code. To deal with that level of complexity…

Is it really true you never want to refer to a code review history? It can provide important context missing from even a well-commented commit. Regardless it's possible to have both. An example is hg's changeset evolution. With changeset evolution, each commit has two histories: the repo history and the changeset history. Commands like `blame`, `log`, etc. show only the repo history; a separate set of commands access…

Yes, it is. In my many years in this business I have never gone back to any code review -- of my code, my reviews of others' code, or anyone's review of anyone's code.

EDIT: I suppose I might look at past code reviews when evaluating a candidate for employment. Still, there is no need to store those along with code. And if a code review comment needs to be recorded for posterity, it gets recorded in the code or in the commit comment.

Re: Fossil vs Git

#225

Post by zzzeek »

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…

I use gerrit for everything and this workflow is exactly what it gets you (well, to be clear, my workflow is commit-per-issue resolved, not commit-per-function added, though you could use it that way also). I highly recommend it or a similar tool.

I wrote a post three years ago about my switch:

https://techspot.zzzeek.org/2016/04/21/gerrit-is-awesome/

Re: Fossil vs Git

#226

Post by judge2020 »

bensummers wrote: post #50

I choose fossil at a time when it wasn't clear which one of fossil, Mercurial, or git would "win". I choose it because it had a very clear and easy UI, guided you towards a way of working that is suitable for small teams (ie 99.99% of all projects), and had an approach to history which made it unlikely you'd ever accidentally lose work. The only thing which has ever made me sad about my choice is pressure from people…

For what it's worth, Git has a command for an instant web server https://git-scm.com/docs/gitweb

Re: Fossil vs Git

#227

Post by slavik81 »

mannykannot wrote: post #194
slavik81 wrote: post #186

Earlier quoted context omitted.

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.

Could you give an example of where it is necessary (in principle, not just because that's the way the tool works) to rewrite the detailed history in order to get the history you want? I realize that we generally have to work with the available tools, but it is also useful to think about how things would optimally work. When I wrote that frequent rebasing looks like a process smell, that could because the tool is not…

No. I worked for years with software that had no way of changing history. It was never required.

Re: Fossil vs Git

#228

Post by mewse »

pseudalopex wrote: post #191
palerdot wrote: post #67

Earlier quoted context omitted.

Interesting ... One sane thing about git is, it is very difficult to lose data. You have to work out of your way to lose data like delete your local and remote histories. Even if that is the case, if someone else has branched meanwhile, it can be restored without any fuss.

Git makes it difficult to lose committed data. It's easy to lose uncommitted changes. Also, someone can know that changes are in the reflog but not how to recover them without making a bigger mess.

That's a really interesting criticism to make.

Can you specify a version control system which doesn't make it easy to lose uncommitted changes?

Re: Fossil vs Git

#229

Post by slavik81 »

cryptonector wrote: post #200
slavik81 wrote: post #186

Earlier quoted context omitted.

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.

Yup, and then you had no real history. And one big commit. Super useful, not.

You're just assuming that. And, despite your snark, you are completely incorrect about what my commits looked like.

Re: Fossil vs Git

#230

Post by stevekemp »

war1025 wrote: post #70
sys_64738 wrote: post #26

Earlier quoted context omitted.

Linus definitely helped and he pretty much killed cvs (not the drug chain).

You mean git killed SVN right? SVN killed CVS in my understanding.

People used SVN, but I'm not sure enough people switched that it killed CVS.

SVN seemed like it didn't go far enough to be honest. It wanted to be "atomic CVS", but there were many long-standing issues with SVN.

Post reply on HN