Fossil Versus Git • Hacker News Board

Re: Fossil Versus Git

#61

Post by billjings » Sun, May 08, 2011, 6:06 AM UTC

jrockway wrote: post #41

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…

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 sure that git was never designed for me to do this, but it can be done pretty safely, in a way that I can recover from.

Now, is this method of going back and fixing things in the past a good idea for general software development? Absolutely not! If I wrote a bug in march, it serves the team rather poorly to go back and replace every commit in the master branch with a new one that doesn't have the bug. And that's why I feel it's accurate to call it rewriting - sure, git keeps enough data around for you to recover from any boneheaded edit you may make to a branch, but from the perspective of a teammate you're still going back and modifying history. It's still confusing. You're still creating new commits out of their commits that have the same name, but different contents.

Re: Fossil Versus Git

#62

Post by lucisferre » Sun, May 08, 2011, 6:20 AM UTC

billjings wrote: post #61

jrockway wrote: post #41

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…

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.

Re: Fossil Versus Git

#63

Post by nimrody » Sun, May 08, 2011, 6:31 AM UTC

swaits wrote: post #54

pyninja wrote: post #21

This does not make me interested in Fossil.

That's too bad. Though I mostly use mercurial, when it's appropriate and I get to choose, I've played with fossil and it is quite a nice package. Super easy to setup, fully featured, easy to use, and does what I want. Before you shitcan the whole idea, why not play with it for a few minutes?

It would help if at least Fossil could use a Git repository (similar to the git plugin for Mercurial).

No point in having different projects using multiple version control systems.

Re: Fossil Versus Git

#64

Post by zbanks » Sun, May 08, 2011, 6:53 AM UTC

bch wrote: post #47

shasta wrote: post #40

Earlier quoted context omitted.

It's not just "oops, typo", but also "oops, someone checked in something proprietary." Being able to scrub the version history before you publish it is more or less is almost a requirement in certain environments.

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?

Re: Fossil Versus Git

#65

Post by ttjervaag » Sun, May 08, 2011, 7:15 AM UTC

andos wrote: post #34

philwelch wrote: post #11

"Git provides file versioning services only, whereas Fossil adds an integrated wiki, ticketing & bug tracking, embedded documentation, and News/Blog features. These additional capabilities are available for Git as 3rd-party user-installed add-ons, but with Fossil they are integrated into the design." Am I the only one who's actively suspicious about this kind of thing? With Git, I can use whatever wiki, ticketing, do…

Have you ever tried to set up a Gitorious box? Not that it's difficult (it is) but it is a complete waste of people's time. If I want to fiddle with every aspect of my development tools, maybe I'm not Fossil's target. Next time I need to set a small coding project (I attend a few OSS hackfests every year), I'll definitely consider Fossil instead of git.

> Have you ever tried to set up a Gitorious box?

Yes! :'(

Complicated to set up and complicated to maintain. And its black box approach to storing the repositories on disk - using UUIDs as folder names, doesn't inspire confidence if the complicated card house should fall over.

I'm not saying Gitorious is a house of cards, but it didn't fit the bill for me at all as a person with limited time to fiddle with a source control setup but still want some self hosted repos. Gitolite ftw.

I'd also be suspicious of the integrated features of Fossil, which from a quick look on their site wouldn't be enough to cover what I need anyway. I'd be curious to know what the thought behind integrating everything is. Could be handy for a hackathon or such I suppose?

Re: Fossil Versus Git

#66

Post by jamii » Sun, May 08, 2011, 7:27 AM UTC

TheBoff wrote: post #10

The fact that fossil has "Versioning, Tickets, Wiki, and Blog/News", really puts me off this, actually. I'm not massive into the unix philsophy, but this seems like bloated: they should be separate things, even if they're interconnected imo.

The idea is to version control not just the code but the entire state of the project: bugs, documentation, discussion etc. I do think the implementation in fossil is a mistake though. If they had tied it to the code dag then you would be able to go back to any point in the project history and see the exact state of the project at that time.

Re: Fossil Versus Git

#67

Post by schrototo » Sun, May 08, 2011, 8:44 AM UTC

aconbere wrote: post #60

Scaevolus wrote: post #39

Earlier quoted context omitted.

Agreed, without rebasing the history for projects with lots of developers quickly becomes a mess. > Fossil deliberately avoids rewriting history. Fossil strives to follow the accountants philosophy of never erasing anything. Mistakes are fixed by entering a correction, with an explanation of why the correction is needed. This can make the history of a project messy, but it also makes it more honest. I'm not sure how…

How do you get arround issues with sharing branches between devs while using rebase. The oddness of pushing your history over other devs makes rebase extremely backwards for me.

That's why you never rebase something that's already been pushed to a public repo or some other shared "master" branch. Rebasing is for making a clean history before you merge into master or make your changes public.

It's really a magnificent tool because I never have to worry about the cleanness of my work-in-progress commits.

Re: Fossil Versus Git

#68

Post by etherealG » Sun, May 08, 2011, 9:01 AM UTC

hammerdr wrote: post #44

prodigal_erik wrote: post #33

Earlier quoted context omitted.

Git has many commands which allow fine-grained manipulation of the staging area; stashes are a crude afterthought in comparison. The problem is that highly encouraged workflows like "git add --patch" inevitably lead to toxic commits which were never tested because they never truly existed in the workspace.

Commits aren't dangerous until you push them. You can very easily rebase out a committed patch after you've tested it.

with great power comes great responsibility :)

Re: Fossil Versus Git

#69

Post by Auguste » Sun, May 08, 2011, 9:09 AM UTC

philwelch wrote: post #53

andos wrote: post #34

Earlier quoted context omitted.

Have you ever tried to set up a Gitorious box? Not that it's difficult (it is) but it is a complete waste of people's time. If I want to fiddle with every aspect of my development tools, maybe I'm not Fossil's target. Next time I need to set a small coding project (I attend a few OSS hackfests every year), I'll definitely consider Fossil instead of git.

Have you ever tried to set up a Gitorious box? No, I just use GitHub. Is there a hosted Fossil service that's as easy to use?

The only hosted Fossil service I've seen so far (only been investigating Fossil since I read this article) is Chisel: http://chiselapp.com

I have not tried it yet, however, and have no idea how easy it is to use.

Re: Fossil Versus Git

#70

Post by gjm11 » Sun, May 08, 2011, 9:17 AM UTC

palish wrote: post #48

gjm11 wrote: 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…

"Less traveled by" could mean (1) less traveled at the time he made the decision or (2) less traveled at the (later) time when he's telling the story. I think #1 is the obvious meaning; your argument depends on taking it to mean #2.

As for "Why would he sigh if he were not lying?", I hardly know what to say: what do sighing and lying have to do with one another? He expects to feel some regret, some sense of a missed opportunity, at never finding out what was down the path he didn't take. At least, that's my reading and it has the advantage that regret does sometimes make people sigh, whereas lying doesn't.