Live data from Hacker News

Fossil Versus Git

fossil-scm.org

81–89 of 89 posts

Re: Fossil Versus Git

#81
post #57

Earlier quoted context omitted.

But if I want private repositories at github I have to pay!

And if you want Fossil hosted on a web-accessible server you have to pay for that somehow anyway.

If you want to access it from home, you'll need to somehow pay for an internet connection, but you're probably already doing that. :)

Most developers I know are already paying for hosting already -- for pet project sites, personal sites for self/friends/family, for running proxies or experiments, hosting offsite backups, etc. etc..

Re: Fossil Versus Git

#82
post #17

Fossil is a great little SCM, written by the author of SQLite. This is probably the most controversial page on the fossil-scm.org site. It is intended, I think, to be provocative - don't take the bait. :) Instead, explore the other documentation on the site and see whether it's an SCM for you. Zed Shaw wrote a perfectly reasonable post about why he uses it: http://sheddingbikes.com/posts/1276624594.html Discussion: h…

When did Zed Shaw write that? I can't see a date tag on the entry; He uses Fossil "these days", is that 2011 or 2006?

Re: Fossil Versus Git

#83
post #17

Fossil is a great little SCM, written by the author of SQLite. This is probably the most controversial page on the fossil-scm.org site. It is intended, I think, to be provocative - don't take the bait. :) Instead, explore the other documentation on the site and see whether it's an SCM for you. Zed Shaw wrote a perfectly reasonable post about why he uses it: http://sheddingbikes.com/posts/1276624594.html Discussion: h…

When did Zed Shaw write that? I can't see a date tag on the entry; He uses Fossil "these days", is that 2011 or 2006?

Looks like the blog url is a timestamp, 1276624594.

  ruin:~$ date -r 1276624594
  Tue Jun 15 13:56:34 EDT 2010

Re: Fossil Versus Git

#84
post #48
post #18

Earlier quoted context omitted.

He kinda contradicts himself. "Then took the other, as just as fair, / And having perhaps the better claim, / Because it was grassy and wanted wear;" seems to imply that the one he took was indeed "less traveled"; but then, immediately, "Though as for that the passing there / Had worn them really about the same,". It doesn't seem to me that there's any Right Answer to the question: Are we supposed to understand that…

TWO roads diverged in a yellow wood, ... [Road "First", aka "Scary Road"] And looked down one ... To where it bent in the undergrowth; ... [Road "Other", aka "Happy Road"] Then took the Other, as just as fair, And having perhaps the better claim, ... Oh, I kept the First for another day! In other words, "I didn't take the First road; I took the Other road." Substituting, this brings us to, "I didn't take the Scary Ro…

Why would the first road be "scary" and then the other be "just as fair"? "Fair" is a positive description.

If both roads are just as fair as each other, there isn't one scary one and one happy one, there's either two scary ones or (more likely) two happy ones.

Anyway, shouldn't it be ONE road diverged in a yellow wood? If TWO roads diverged, that would make four.

The poem is about a man who, "years and years hence", will be remembering his life, and up there near the top of his memories to tell people about is how he chose which of two almost identical paths he took when walking in a wood, once, and they were roughly the same. Does that sound like the sort of memory someone who would pick a scary road would choose to reminisce about? Does it sound like the sort of tale a habitual liar would tell? No to both. It sounds like the sort of tale a really boring person with no interesting memories would tell.

He was walking through a wood, not trying to get anywhere in particular and not caring where he went. It was probably quite pleasant, and it wasn't the hundred acre wood or the Lord of the Rings evil forest, both roads came out the other side of the wood and then he went home.

Re: Fossil Versus Git

#85

Git features the "rebase" command which can be used to change the sequence of check-ins in the repository. Rebase can be used to "clean up" a complex sequence of check-ins to make their intent easier for others to understand. From another point of view, rebase can be used to "rewrite history" - to do what Winston Smith did for a living in Orwell's novel 1984. This is FUD. Git never erases history; it merely moves mut…

Git gives you granular control of every aspect of itself. When you REALLY need it, it works out. Insane history rewrites make the full team have to propperly sync. Rebase is an amazing tool for getting your repo up-to-date and not making someone else when looking through history have to worry about mix-matching commits to see exactly how one branch turned out. Its personal prefernece. In the end of the day, git will not let you cover your tracks.

Anecdote:

I fucked up some commits. I put in wrong conmiter names and so on, omitted some data in some of my commits. With git I could clone my repo, experiment with rewriting commits to fix conmiter names, and then merge it to everything. Yes history is changed, but end of the day this is not about hiding shit. This is about keeping the repo information useful and simple. If you want to blame shit on people, there are external systems which will ensure that people will get blamed for their own shit. VCS is not for that, VCS is to version your code, be able to un-fuck yourself up, and figure out why someone did something and how they did it exactly at some point in time. Nowhere in the is "blame people for mistakes" seen.

I've seen people not want to get blamed or use VCS. They used a word document to version their source. Yes. And I assure you it took people lots of time to realize wtf is going on.

Re: Fossil Versus Git

#86
post #72

Earlier quoted context omitted.

I'm not familiar with other DCVS tools, but I have delved pretty heavily into the history rewriting capabilities of git. Git is just a power tool. It won't ruin your day like rm -rf will, but it will give you enough rope to rappel your way down into ontological horror. I have been using it to write extended tutorials on my local system. I may find a bug at step 45 that needs to be fixed back at step 2. I am pretty su…

You're not looking at the possibility that someone may do a bunch of development locally, then use rebase to clean it (the local changes) up before pushing it out to a central repository (or merging it into master). If you're really paranoid that someone will use rebase to screw up master, you can use a tool like gitosis or gitolite to manage permissions on a central repository. You can say that no one has permission…

Often when pairing we'd commit with messages like "WIP: 1" "WIP: 2" etc. push pull switch machines (remote pairing) get checkpoints in there. Then before pushing to the main branch we'd roll all that up into one commit with a very helpful message. Boom solves a great workflow problem.

Re: Fossil Versus Git

#87
post #64
post #47

Earlier quoted context omitted.

This is actually solved in fossil via "shun". The case of publishing a password or credit card numbers or $seriousMistake will be attributed to an artifact. Applying "shun" to that artifact will prevent it from being pushed to remote repos, and, on repo rebuild (a local operation), that artifact will be completely removed from the repository (locally). The list of shunned artifacts is maintained forever however, so i…

So fossil does have rebase?

I'm not a git expert, but iiuc, git rebase is a way to re-present a subtree as a single checkin, or otherwise re-work the commit tree to clean it up. It's also a big part of git culture.

In fossil, there is such a thing as a private branch that will not be pushed/pulled when repos sync w/ ea. other, but the owner of that private branch can ultimately merge the work, and it will appear as a single atomic commit (ie: a single checkin, not all the multiple artifacts describing the whole of the work in the private branch). I'd think that's the closest thing to rebase that fossil has. Even in that case, though, there's no explicit moving of artifacts; when the work is merged to a public branch though, all the work appears as the condensed net change, in a single checkin.

Otherwise, culturally speaking, re-working of the tree is -not- the way the repository is handled. Errors are fixed w/ corrective checkins, and both will show in the history.

jrockway sheds some light on git rebasing here (http://news.ycombinator.com/item?id=2524993) though, which I'll look into myself to come to understand. Before, I thought rebase was more 'destructive' than what that description indicates.

Re: Fossil Versus Git

#88

Earlier quoted context omitted.

I'm not familiar with other DCVS tools, but I have delved pretty heavily into the history rewriting capabilities of git. Git is just a power tool. It won't ruin your day like rm -rf will, but it will give you enough rope to rappel your way down into ontological horror. I have been using it to write extended tutorials on my local system. I may find a bug at step 45 that needs to be fixed back at step 2. I am pretty su…

The scenario you describe (a bug in march) is not what rebase is designed for at all.

Absolutely not. Yet that's what I'm doing locally, effectively. And for my particular case, it's working.

That's the kind of tool that git is.

Post reply on HN