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

111–120 of 252 posts

Re: Fossil vs Git

#111

Post by darkwinx »

pmoriarty wrote: post #106
dan-robertson wrote: post #82

Earlier 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?

Yes, Git has "mv". Git also detect file rename. I'm not aware of the method though. I'm talking based on experience. I renamed some file normally, without Git. When I checked the `git status`, Git says it was renamed.

Re: Fossil vs Git

#112

Post by garmaine »

heavenlyblue wrote: post #86
bluejekyll wrote: post #80

Earlier quoted context omitted.

I sometimes go back and “group” commits with a ‘git rebase -i’ and squash commits that are related. Is that similar to what you’re talking about?

No, I believe what author is asking for is to keep those changes in git, but have git manage grouping of history logs for you. E.G. you have worked in a feature branch, and committed 10 times - let those commits be kept in the log, but when running git log there must be a flag that allows for filtering based on how granular the output must be. That can be done with rebase, but then you loose history. I am pretty sure…

There is no theoretical reason you can’t maintain two histories—-e.g. when rebasing have a “rebase-merge” commit that has the hash of the other tree, and optionally keep that history around in the git repo. Then you could do a ‘git blame —orig’ or whatever to switch between immutable and cleaned up history.

No VCS I’m aware of supports this. But they COULD.

Re: Fossil vs Git

#113

Post by paulddraper »

emerongi wrote: post #74
tux1968 wrote: post #35

One of the bullet point advantages listed for Fossil of allowing multiple checkouts per repository is also supported by Git. There has always been a way to do it, but since Git 2.5 or so, the "worktree" sub command was added for this purpose.

Huh. I've just used another git clone of the repo, but the worktree command seems to fit my uses very well. Thanks.

Git clone is still a fine solution, and the one I prefer.

Worktree adds the ability to share config and save disk space.

Re: Fossil vs Git

#114

Post by crankylinuxuser »

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.

I still push for SVN when we're doing work that centralization makes a great deal of sense. For example, I look at SVN+puppet to be an exceptional combination... and I really don't need that puppet repo to be distributed.

Then again, if I'm working with people in different areas, and want them to have a full reproducible copy of the repo, git it is.

I maintain a "use the right tool for the right job". Sometimes the Cathedral wins out, and other times the Bazaar wins out (NO! not the Bazaar source control!).

Re: Fossil vs Git

#115

Post by funkaster »

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…

that doesn't scale. I personally prefer a single squashed commit linking to a full discussion in a PR/MR: do a git blame, even if you get a giant hairball commit, you should be able to trace it to a review process (PR/MR) where it was discussed and thoroughly reviewed.

Re: Fossil vs Git

#117

Post by apazzolini »

dsego wrote: post #108
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…

There is a name for what you are describing, it's called "atomic commits". Every commit can stand alone and at every commit the software should be in a working condition.

Gary has a talk about this: https://www.destroyallsoftware.com/screencasts/catalog/sourc...

Re: Fossil vs Git

#118

Post by paulddraper »

ethomson wrote: post #48
Chyzwar wrote: post #37

Earlier quoted context omitted.

> It has nothing to do with the Windows filesystem; Git simply cannot support a 5 GB working tree on any filesystem. Can you provide a reference? I was searching a bit and only things I found was bugs in windows[1] for git lfs. > You can call this "pathological" but this throws a lot of shade on monorepos without much critical examination of how or when they might be useful. Windows codebase has 3.5 million files and…

> Can you provide a reference? I was searching a bit and only things I found was bugs in windows[1] for git lfs. Apologies, I hastily mistyped, I meant 500 GB , not 5 . (5 GB is about the size of my repository, which is not really so big at all and certainly something git can cope with on its own). This series of articles should illustrate some of the issues that VFS for Git tries to address. ("GVFS" is now called "V…

If you're versioning line-based text, and you have 80 ASCII characters per line, stored as ASCII/UTF-8, a worktree of 500GB has 6.7 billion lines.

That's 3x the source line count of Google's entire monorepo. [1]

So if you're using git for source code, 500GB is beyond pathological.

If you're using git for other purposes, then yes you might need something like Annex/LFS/GVFS.

[1] https://m-cacm.acm.org/magazines/2016/7/204032-why-google-st...

Re: Fossil vs Git

#119

Post by reificator »

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/

Relevant: https://git-man-page-generator.lokaltog.net/

Re: Fossil vs Git

#120

Post by jordigh »

funkaster wrote: post #115
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…

that doesn't scale. I personally prefer a single squashed commit linking to a full discussion in a PR/MR: do a git blame, even if you get a giant hairball commit, you should be able to trace it to a review process (PR/MR) where it was discussed and thoroughly reviewed.

It scales quite well. Linux itself is developed in this way. Or perhaps you think Linux isn't at a large enough scale? (No sarcasm, I know that there projects out there much bigger than Linux.)
Post reply on HN