That comparison table made me dislike fossil even more. Fossil took something that’s not broken, and broke it.
Fossil vs Git
121–130 of 252 posts
Re: Fossil vs Git
#122Earlier quoted context omitted.
That back and forth is the most important part of the story! It shows that you thought through multiple approaches to the problem, (hopefully) why they didn't pan out, and they give someone else a starting point for returning to that approach in the future. It isn't exactly rare that I go through the blame history on some project to find out why something was done in a way that seems stupid at first glance, just to g…
"back and forth" is not the same thing as "all kinds of mistakes". No-one cares about stray keystrokes other developers make, it's just noise. Yes, we absolutely care about the design of the software we're working on, and that's what commit messages , self-documenting code, comments, issue trackers and project management (planning session etc.) are all for. When you squash commits in Git the default generated commit…
> No-one cares about stray keystrokes other developers make, it's just noise.
Sure, and `git commit --amend` is fine for those cases.
> When I'm investigating when and why some code was implemented the way it is; I don't want to look at a Git blame trying to find when something was changed, just to see that the most recent change was reverting some earlier messing around. Just to git blame again starting from just prior to said messing around, just to see the same thing again - noise is bad!
I guess that depends on your setup. My Emacs is set up so that `b` is "reblame from before this change". GitHub's blame UI has a similar button (though that, sadly, doesn't preserve in-file context).
At that point the cost of the "noise" is more or less zero.
Re: Fossil vs Git
#123In my experience, feature sets tend to converge within product categories, but I'm happiest in the long term with the program whose original design decisions I'm most sympathetic with.
In fossil's case this was architectural simplicity, an easy-to-use basic set of commands with a discoverable set of expanded commands that always seemed to meet my needs as they cropped up, collaboration features in the pre-GitHub era were killer. There are a few discrete layers of hackability for customization with minimal risk of blowing your project away.
Fossil still meets my needs admirably, and I stick with it even though it's harder to make the case for it in the current era of feature convergence.
Re: Fossil vs Git
#124Git: 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?
Re: Fossil vs Git
#125Earlier 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…
I would prefer not to have these errors in the first place. They should be caught during review, and then fixed in the commits that introduced them with an interactive rebase. If this type of error is consistently getting through your review process, you should probably consider revising that process.
...and maybe consider adopting atomic commits -- the main reason I like them is not actually because they make it easy to look at history, but because they're easy to review and catch these types of errors. If each commit stands on its own, it's obvious when one doesn't.
Re: Fossil vs Git
#126Git: 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?
Disk space?
Re: Fossil vs Git
#127Git: 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?
Shitty monorepos that measure hundreds of GB.
Re: Fossil vs Git
#128From the features in Fossil and not in git:
> Branches in Fossil have persistent names that are propagated to collaborators via push and pull. All developers see the same name on the same branch. Git, in contrast, uses only local branch names, so developers working on the same project can (and frequently do) use a different name for the same branch.
Since the default is to use the name from upstream when checking out a branch, the vast majority of the time devs working in git also use the same name for a branch. Given that, this seems better stated as a feature for git (Easily Renamed Branches, perhaps).
Re: Fossil vs Git
#129I'm surprised git caught on despite mercurial being much superior (hadn't heard of fossil before). Git has the following shortcomings which are major (some shared by other VCS too) 1) UI- terrible, terrible UI 2) Unncessarily complex data model 3) Doesn't scale well to large repos (until Microsoft's VFS- windows only) (and many others...)
Fossil is made by the same gentleman (D. Richard Hipp) that gave us SQLite.
Yes indeed, and he comments here as "SQLite".
Re: Fossil vs Git
#130Earlier quoted context omitted.
If you tell hg to rename a file, e.g. hg mv foo bar, it will generate a patch which essentially just says “foo was renamed to bar”, and when you look at the diff the only thing that has changed is the name. If you merge this with a patch that changed foo then hg will do something sensible (ie either merge the changes into bar or give a merge conflict). Git has no first-class concept of file name changes. Instead it t…
"Git has no first-class concept of file name changes. Instead it tries to use heuristics to spot renames and sometimes they work and sometimes they won't." Git has the "mv" command. If you "git mv" a file, why would git have to guess or use heuristics to figure out that the file was renamed?
As the Git FAQ [0] says:
> Git has a rename command git mv, but that is just for convenience. The effect is indistinguishable from removing the file and adding another with different name and the same content.
git diff, merge, and related tools have heuristics for detecting file moves (off by default, turned on with e.g. git diff -M) but they tend to break if a file is both moved and modified in the same commit.
[0] https://git.wiki.kernel.org/index.php/GitFaq#Why_does_Git_no...