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

91–100 of 252 posts

Re: Fossil vs Git

#91

Post by umvi »

Someone1234 wrote: post #53
marktangotango wrote: post #44

Earlier quoted context omitted.

How often dou you actually look at this historic detail you seek to maintain? Daily, weekly, monthly? Is it more for to satisfy a feeling than an actual need? I mean if some junior dev wallows on some branch for 40 commits, I don’t want to see any of that, I just want to see what was finally merged.

Often? When you're trying to see when a specific change occurred you often have to go down to the specific commit, a high level group isn't good enough (particularly when the group could be shared by multiple people).

Then don't squash atomic commits representing single, logical changes. The point is that if you have 3 commits in a row correcting typos, squash those 3 into a single atomic, logical, commit.

Re: Fossil vs Git

#92

Post by jtms »

SQLite wrote: post #72
donatj wrote: post #17

Earlier quoted context omitted.

> 2) Unncessarily complex data model Hmm? It’s just a directed graph of SHA1s under the hood. Seems pretty simple to me once you understand that. My understanding was that Hg’s data model is actually way more complicated with more pointers. As everyone else is chiming in, the reason git won was speed. I haven’t used mercurial in a few years but at the time when I was looking to replace SVN, git did everything seconds…

Perhaps the OP is referring to this: https://www.sqlite.org/whynotgit.html#the_mental_model_for_g...

All these concepts are extremely useful in practice. I do not see them in any way as “needlessly” complex. Difficult to learn... maybe, but not just for the hell of it.

Re: Fossil vs Git

#93

Post by Benjamin_Dobell »

heavenlyblue wrote: post #88
Benjamin_Dobell wrote: post #59

Earlier quoted context omitted.

Are you pushing the commits with errors? Are you merging the commits with errors? If both of those are true then this sounds like a process issue. Git makes it extremely easy to edit history, with the ability to amend any commit; even several commits back with simple CLI tools like `git rebase -i `. However , what it doesn't like you doing is ripping the rug out from other people i.e. editing history team members are…

What if my repository is linked to a CI process that deploys the live code? And tb change needs to be done “now”? If you are working for a larger company where processes are clearly defined, then it’s good for you and that feature is not needed. But you are loosing all of the agile feature of git in the first place. In my situation squashing history takes away my other ability to use git as a wiki of “things that did…

> git as a wiki of “things that didn’t work out”

Wouldn't a wiki be the best solution for that? Git is a software development tool, not a design or project management tool.

Re: Fossil vs Git

#95

Post by bch »

palerdot wrote: post #65

> Push or pull a single branch > The fossil push, fossil pull, and fossil sync commands do not provide the capability to push or pull individual branches. Pushing and pulling in Fossil is all or nothing. This is in keeping with Fossil's emphasis on maintaining a complete record and on sharing everything between all developers. This is a kind of deal breaker if it just pushes all of my private WIP branches to remote.…

Fossil does have private branches[0] and the recommended way to publish private work is to integrate it into a non-private branch and sync as usual.

[0] https://www.fossil-scm.org/xfer/doc/trunk/www/private.wiki

Re: Fossil vs Git

#96

Post by SQLite »

afiori wrote: post #58
pferde wrote: post #52

Earlier quoted context omitted.

There is a difference between squashing together thirty commits of someone working on one concrete thing (I don't need to see all the mistakes and reworks you made, I just want to see the result in a nice, easy to read diff), and thirty commits of someone working on thirty things. The latter is, of course, wrong as it makes the repo history harder to read, while on the other hand the former improves readability.

It would be nice if in the first case one could annotate those thirty commits in a narrative "here I started another attempt", "this solution could not work for X,Y and Z reasons", "these 8 commits are just typos" maybe with also the ability to only select a subset of a commit.

I've recently added the ability to associate a wiki page in Fossil with an individual check-in or with a branch - as additional documentation about that branch or check-in. This is similar to your concept, if I understand you correct. The Fossil changes have worked well enough so far. But only time will tell if this ends up being a good idea or not, I suppose.

An example is the "About branch begin-concurrent-pnu-wal2" at the top of the page https://www.sqlite.org/src/timeline?r=begin-concurrent-pnu-w... - the page shows all check-ins for the branch, and the Wiki at the top gives a summary of what that branch is about.

Another example is the detailed discussion in the "About" section for check-in https://www.sqlite.org/src/info/718ead555b09892f - important information that records the thinking about this commit but which seems too prolix for a check-in comment.

Let me know your thoughts on this idea.

Re: Fossil vs Git

#97

Post by brobdingnagians »

I think it really comes down to preference. Both work well and for different reasons and styles. Including tech notes and docs into the VCS could be nice, if you use it, but like most project management, it comes down to how you work-- that's one reason why there isn't a one-size-fits-all project management product that is infintely better than any other offering. There are plenty of times I wished I had something like the embedded tech notes to explain design decisions. I use git myself currently, but I've wanted to dip my toes into fossil for awhile to see if it matched my workflow. I think storing the whole repo in an SQLite database was brilliant-- self contained and you don't have a problem slicing the data to get things like all parent commits or descendant commits.

Re: Fossil vs Git

#99

Post by bch »

dymk wrote: post #71
eesmith wrote: post #60

Earlier quoted context omitted.

How do you estimate Fossil's general popularity? Most projects are invisible to you, like in-house projects that never see the light of day. If Fossil is used by 1% of those projects, that's still a lot of projects. How can you tell if Fossil is popular in HN? By my reading, only two people in this thread use it. More than that mention having never heard of it before, or make statements where it's clear they don't re…

Fossil is posted to and discussed on HN all the time. It's a novelty, it differs in design from the popular tools that people actually use in their day-to-day jobs. There's really no reason to think that Fossil is used internally at a rate higher than its public-facing usage. And I've literally never seen a project that uses Fossil aside from Fossil examples.

I use it for lots of projects, spanning years of work, including commercial projects with ~20 devs. Those projects aren’t public, and I’m sure lots of other people do use it that way. It’s still not going to rival the install base of git.

Re: Fossil vs Git

#100

Post by pmoriarty »

donatj wrote: post #17
fxfan wrote: post #2

I'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...)

> 2) Unncessarily complex data model Hmm? It’s just a directed graph of SHA1s under the hood. Seems pretty simple to me once you understand that. My understanding was that Hg’s data model is actually way more complicated with more pointers. As everyone else is chiming in, the reason git won was speed. I haven’t used mercurial in a few years but at the time when I was looking to replace SVN, git did everything seconds…

"the reason git won was speed"

It wasn't just speed, it was also that the Linux kernel was developed under git, that Linus created git, and the existence of github, which a lot of people liked.

After a while, it also just developed a critical mass where the attitude of people/companies that weren't using it almost inevitably became one of "everybody else is using git, so we should too".

Post reply on HN