Fossil vs Git • Hacker News Board

Re: Fossil vs Git

#211

Post by Joky » Sun, Jan 27, 2019, 12:48 AM UTC

Benjamin_Dobell wrote: post #103

endless1234 wrote: post #49

Earlier quoted context omitted.

I look at git blame (using 'Annotate' as IntelliJ calls it) quite often to figure out reasons for some certain change/implementation logic. It irks me when the result is just some giant squashed commit with 40 lines. Which of these explains this specific line? _History_ itself, yeah, not that much.

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…

> Would it not be significantly more frustrating if you use git blame and you see: [...]

Yes, it would be very frustrating. But you're presenting this as if this is the only alternative, it isn't: I wouldn't approve a pull-request that have commits like the one you mention, I would ask to rework the history of the PR to be a logically sequence, just like exposed in this comment: https://news.ycombinator.com/item?id=19007171

"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 atomic and as small as possible."

Re: Fossil vs Git

#212

Post by raimue » Sun, Jan 27, 2019, 12:52 AM UTC

Groxx wrote: post #199

raimue wrote: post #132

Earlier quoted context omitted.

With multiple clones, you would need to remember to update each clone regulary not only from remote, but also push/pull locally in case you want to compare your state with other branches. A 'git checkout' on a large repository such as the Linux kernel may take a while (bound by I/O performance). Regulary switching between branches with many changed files becomes annoyingly slow. If you keep multiple clones, you actua…

`git clone --local` does hardlinks, space usage is quite low, so I'm not really sure that part holds up. Maybe in Windows? Switching branches can definitely be slow tho, yeah. Do worktrees change that somehow tho? From all I've read so far (quite limited!) they just sound like replacements for `git stash` or making a temporary commit / branch, but with a new set of commands and rules to learn. I don't find `git commi…

git worktrees can also be useful if your build system needs different arguments per branch. For example if you keep multiple release branches installed side-by-side on your machine, it is easier to just run `./configure --prefix=/opt/release-X.Y` only once on a worktree instead of repeating this procedure every time you switch branches. That way you can even keep all your object files around and save the time to compile them again.

The same also applies to languages such as Python or Node.js, where you might have a different set of dependencies depending on the branch and don't want to regenerate your virtualenv or node_modules on every branch switch.

Re: Fossil vs Git

#213

Post by Joky » Sun, Jan 27, 2019, 12:53 AM UTC

randallsquared wrote: post #124

jlebar wrote: post #94

Git: One check-out per repository Fossil: Many check-outs per repository git allows multiple checkouts per repo. Official docs (good luck): https://git-scm.com/docs/git-worktree Random person's blog that explains it more clearly: https://www.saltycrane.com/blog/2017/05/git-worktree-notes/

I have no idea what use case is satisfied by git worktree, based on that blog post. In the case that you desperately needed to have two branches checked out, why not just clone twice?

The main reason I'm using worktree instead of two clones is that you can commit in one and cherry-pick in the other immediately, without pushing/fetching. You can rebase the branch in development in worktree 2 on top of something else in worktree 1.

Re: Fossil vs Git

#214

Post by SQLite » Sun, Jan 27, 2019, 12:54 AM UTC

shawkinaw wrote: post #162

orev wrote: post #145

As someone not versed in either, how much does not being able to track changes forward through the history matter? It sounds like that might be pretty important, but git’s popularity would seem to indicate that it doesn’t really matter in practice?

I have to say, I’ve used Git for many years now and I’ve never, ever, ever wished for this, nor even knew it wasn’t possible. So this seems like a silly thing to claim as an advantage for Fossil.

I never thought I needed bisect, until I had it. Now I can't live without it.

Re: Fossil vs Git

#215

Post by cryptonector » Sun, Jan 27, 2019, 12:59 AM UTC

millstone wrote: post #209

cryptonector wrote: post #202

Earlier quoted context omitted.

I rewrite history (not in the upstream) every day, multiple times a day. I do it to split commits. I do it to squash commits. I do it to reorder commits. I do it to make my commits easier to review by whoever is doing code reviews for me. I do it make my commits logical: bug fixes get their own commits, features get their own commits, tests get their own commits if that's what the upstream wants, ... It's the only wa…

Do you do code review using a formal tool, like Gerrit or Phabricator? If so you already have a "code review history", separate from the repo history. The code review history is at times interesting to review, because it contains discussions, tradeoffs, etc. Given that we have this secondary history, why require a completely different tool to track and access it? That's just pointless duplication. We should track all…

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 one needs things like OpenGrok, cscope, and so on, to find one's way around. And when it comes to history, I could not care less about past code reviews or history internal to a feature branch. When I need to do `git blame` or look through commit history or a large codebase, I want to see clean history with a high signal-to-noise ratio. The more noise, the slower I'll make progress on understanding whatever code/history I'm trying to understand, therefore the slower I'll make progress on bug fixing or feature development -- I might even give up on history, and lose a lot of important information, if the noise level is too high.

For me the ability to rebase, and to require clean history, trumps all the great things in Fossil -- each and every one -- that Git lacks. And this even though I love Fossil's design.

Re: Fossil vs Git

#216

Post by pseudalopex » Sun, Jan 27, 2019, 1:15 AM UTC

joshka wrote: post #190

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.

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.

That doesn't keep the branch names. It also doesn't help bisect complex merges. Git may be better at that now, to be fair. So many projects rebase or squash that I haven't had to do it in a while.

Mercurial can rewrite history in the same ways as Git.

I never want to see junk commits, but I can't force other people to spend time cleaning them up. Squashing cleans them up quickly but loses useful information.

Re: Fossil vs Git

#217

Post by nh2 » Sun, Jan 27, 2019, 1:28 AM UTC

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 don't think this is impractical.

I've been using this approach successfully for 8 years now on tens of open source projects and various company code bases of all sizes.

It does take a small amount of overhead (I measure this, and for me it's around 5%). But that pays off immediately as soon as you or someone else reads it a few weeks later when investigating an issue.

Re: Fossil vs Git

#218

Post by Ajedi32 » Sun, Jan 27, 2019, 1:29 AM UTC

jordigh wrote: post #87

gugagore wrote: post #34

Earlier quoted context omitted.

I'm also a big fan of not deleting data. I don't like squashing commits, for example. But I also want to be able to see high-level intent. If instead of "squashing", it were "grouping", I'd be happy. I could encapsulate a bunch of messy commits that I made while I didn't know what I was trying to do. The intent would be clear at a higher level, but if you want to dig in to see what it actually took me to achieve that…

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 really make sense to create an unused function, so these two changes should really be one commit.

Re: Fossil vs Git

#219

Post by millstone » Sun, Jan 27, 2019, 1:36 AM UTC

cryptonector wrote: post #215

millstone wrote: post #209

Earlier quoted context omitted.

Do you do code review using a formal tool, like Gerrit or Phabricator? If so you already have a "code review history", separate from the repo history. The code review history is at times interesting to review, because it contains discussions, tradeoffs, etc. Given that we have this secondary history, why require a completely different tool to track and access it? That's just pointless duplication. We should track all…

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 accesses the changeset history.

An example where this is useful: sometimes rebasing can inadvertently produce bugs, such as collapsing two identical lines which ought to have been duplicated. `git blame` cannot check if that happened. But the changeset history, by tracking the rebase, can tell you that.

Re: Fossil vs Git

#220

Post by kazinator » Sun, Jan 27, 2019, 1:36 AM UTC

pmoriarty wrote: post #109

kazinator wrote: post #107

Earlier quoted context omitted.

Because git stores sets of files. If you move a file and make a new commit, it's just a new set of files which says "this old set is my parent". There is nothing in there about the renamed file.

Still, at the point you do a "git mv", it can't be said that git doesn't know you renamed a file. It knows. In fact, after a "git mv foo bar", if you do a "git status", you'll see: On branch master Changes to be committed: (use "git reset HEAD ..." to unstage) renamed: foo -> bar If git chooses afterwards to discard that information and do nothing with that knowledge, that's a separate problem.

I don't know enough about Git internals in this regard, but it's possible that in fact the index is just being compared to HEAD to infer that information. Index has a file called "bar" and none called "foo". HEAD is vice versa.