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 mutable refs around. When you rebase a branch called "master", nothing is rewritten: a new immutable commit history is created, and the ref "master" is moved from pointing at the old history to pointing at the new history. The old history still exists in all its glory at "master@{0}". (And when you change that, it goes to master@{1}, and so on.)
If git didn't have the concept of refs, then this would never even worry anyone. Once you have commit ab387df, it's refers to the same sequence of changes for all eternity. What master points to may change out from under you, but the history never goes anywhere.
The only way to "rewrite history" is to delete every copy of the repository ever made, which is exactly how you would rewrite history with Fossil or Subversion or anything.
(And now, if I may, a digression. I've noticed that the "rewriting history" aspect of Git makes for a good personality test. It's strongly polarizing -- the people that think source control is designed to be documentation love it, and the people that think source control is an audit mechanism hate it. Control freaks hate git, and long-haired hippies seem to love it.)
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.
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 permissions to push things to master that are not fast-forwards.
Scenario #1:
I'm working on a feature branch. I have a number of discrete changes
that I'm making. I attempt to keep each of these changes in its own
separate commit. After completing 10 such changes, I realize that I
introduced a bug in change 3. I commit the bugfix with the same
commit message title as change 3, but with a "squash!" prefixed at
the front of it. Now when I'm finished with my changes on the
feature branch I can run "git rebase -i". git-rebase will
automatically position the bugfix to change 3 next to change 3 and
set it up to be squashed into the change 3 commit. Then when I merge
my changes into master there are only commits for changes 1-12,
instead of 50 commits covering all of the minor bugs that I fixed
with my undeployed code.
Scenario #2:
Rewriting commit messages. This is one that I use all of the time at
work. I use a commit message template that has "Reviewed-by: ???" at
the bottom. When I do all of be topic branch development, I don't
get someone to review each individual commit prior to commiting it
(as that would defeat the purpose of a DVCS... might as well go back
to SVN at that point and managing chunks of changes prior to commits
with something like `quilt`). So now all of my commit messages have
"Reviewed-by: ???" on them. Prior to merging the changes back into
master, I can use git-rebase or git-filter-branch to go back and
edit my history to change "Reviewed-by: ???" to "Reviewed-by: Bob"
on my commit messages.
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.
I don't use rebase and I can't say that I like it, but that doesn't make me hate git. I commit all my crappy and stupid intermediate code (for my personal projects).
When you keep the change history clean, it's a lot easier to answer questions like "why did I do that?", and it's a lot easier to explore topic branches and back out bad design ideas.
If the history is messy, removing bad changes is about as difficult as opening up every file and removing the changes you don't want. In other words -- error prone.
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.
It also backs this point up with yet another abuse of the most misquoted poem ever, Robert Frost's "The Road Not Taken."
The poem isn't actually in praise of making unusual choices — it's about rationalizing the choices we make so that they seem more intelligent and important than they actually were. In the text of the poem, the narrator goes to great lengths to make it clear that he can't tell any difference between the paths in front of him. So he decides to choose one arbitrarily, and tells us that years from now, he'll tell people that he took this little-traveled road and that set the course of his life.
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 the path he took really was less-travelled, or not?
My reading of the last stanza differs from yours: he's not saying that he'll tell people, falsely, that it set the course of his life; he's saying that although he couldn't see any good reason for choosing one over the other, as his life goes on it'll turn out that it made a big difference.
The thing that intrigues me about this poem (which, actually, I don't much care for despite its fame) is the title. "The road not taken". That's not the perhaps-less-worn path he did take, it's the other one. Without that title, if you asked me which path was more the subject of the poem I'd have said without hesitation: the one he took, which "has made all the difference". But no: the spotlight is on that sigh with which Frost will be telling the story, the regret (if that's the right word) that he couldn't try them both. I think.
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 Road; I took the Happy Road."
Then, the key is...
Though as for that the passing there
Had worn them really about the same, ...
This means "both roads were equally traveled". So therefore we must extrapolate into the future. Take a thousand average people. Not entrepreneurs; think more along the lines of Grandma. Now show them a Scary road and a Happy road, then ask them to choose. Which one are they more likely to select?
I'd say the Scary road is the one "less traveled".
I shall be telling this with a sigh, ...
Why would he sigh if he were not lying?
Two roads diverged in a wood, and I—
I took the one less traveled by
This means he claimed to have taken the "less traveled" road, which is the Scary road. But he took the Happy road.
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.
"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.
It doesn't seem like a real contradiction — it can be easily harmonized as an ironic way of saying they were identical, but he wanted there to be some difference. From the description, can you tell me which road he took?
I agree with you on the title though. It puts a really nice spin on the poem.
"following the herd"? Yeah, git's had a lot of adoption (methinks primarily due to github), but I work with loads of people who are just getting up to speed with subversion. VCS of any type gives them a headache - "distributed" is even worse. Some client's I worked with in 2010 had no version control at all. "Following the herd" seems a little myopic. :)
Agreed. Having a small community and not being well-known are not advantages.
They try to say that your voice will be comparatively louder and you'll get more attention from the developers, but in a large community, you get attention from the community as well. The only thing you can get from using an unpopular project is an adrenaline rush from living on the edge.
Having a small community and not being well-known are not advantages. I am not sure I can agree with this. Smaller communities are often nicer. Think of all the talk around here of growing pains, loss of niceness, comparisons to Reddit or Dig, eternal September, etc. that have come about as the community grows.
Open source projects have a very similar problem. When there were 20 people in the Linux community they could all be considered kernel hackers and communicate amongst themselves, now that there are millions they can't assume every member of the community is a kernel hacker, the 'kernel hacker' ability of the average community member has fallen.
Oh no, not another SCM. My head is already bursting from learning Hg and Git...
Also I don't think "lack of rebase" is a feature. If you don't want it in git, just forbid using it for your project. However, if you want to maintain a patch-set outside of a project it's the best thing since sliced bread.
Fossil's solution to that are private branches and stashes. That said, I'm with you in preferring rebasing for this kind of thing. (And I'm not even a Git user; I'm pretty wedded to Mercurial.)
I used to use bzr, then I used git and was blown away by the speed. I switched to it, still learning the (very hairy) commands, but really enjoying the speed.
One day, I tried hg by chance and discovered it was as fast as git and as sensible as bar :( Now I have no idea what to use.
I agree... I think that making the argument "try fossil because no one else uses it" is just as bad as recommending using git because everyone does. Why not judge it on it's merits?
If you know git you can contribute to any project on github more easily. That is an advantage, though it would be utterly foolish to make your choice solely on this point.
The real problem with that statement is that version control doesn't exist in isolation. If you're the only person using Fossil it's useless to you (I hate git but I have to work with others)
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:
"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, documentation, and blog features I want. I don't want my VCS to be a Lotus Notes for software development.
I would argue that Github has many if not all of those features.
Wiki - check
Ticketing & Bug Tracking - Github has 'issues'
Embedded documentation - include a README file in your repo, and Github immediately shows that under your project
News/Blog features - Github has pages, and automatically generates RSS feeds for your commits.
I'd argue that Github does all these things better than Fossil (or I) can ever do - they have a whole design team constantly worrying about ease-of-use.
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..
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.
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?
That's exactly the scenario I had in mind. I have attended some hack fests myself and, besides the general chaos and lack of coordination, there's the particular issue of how people share code, report issues and write stuff down. Everything is everywhere. It's a mess.
When the project allows me to go hosted, then the problem is already solved. Thrice. When it does not, but I still need versioning, a wiki and some issue tracking and I don't feel like sporting my masochist hat, good news for me: there's now a tool that does it all and it's a single binary that needs no setting up.
And I don't know if there's any hosted Fossil service around, easy to use or otherwise.
It is JRuby-based, and they only give you a compiled binary, and it's weeks to months behind the public GitHub site. Aside from those issues, it's really quite nice.
IMO the "Sharding versus Replicating" section sounds a little bit like someone is trying to sell me on a centralized VCS after I've already switched to and enjoy DVCS.
And further down in the same section, it sounds like the author has confused Git itself, with the way Git is used developing the Linux kernel. Just because the Linux kernel devs use Git in a particular way doesn't mean Git encourages any one particular model over another.
Does anyone know of a more technically accurate and less biased comparison?
WRT selling you on centralized VCS after you've switched to and enjoy DVCS:
That was my immediate reaction, but I realized that there is a third thing. In a way, a git-like DVCS in most workflows still retains some of its 'centralized' state - that is, some repositories are the only repositories with certain branches etc. and often there is a specific repository on a server that has all branches "that matter" (such as a github account). As mentioned, Kernel developers need this to reduce clutter/noise and establish arbitrary hierarchies (that are, in a sense, centralized).
This "third thing" is, in a way, even more decentralized than old-school CVS/SVN- in that all repositories truly become equal. I'm not saying it's better than git-style-DVCS- it's certainly not if you need an ad-hoc high branch-volume hierarchy- but I do think that it's an underdeveloped use-case that's neither centralized nor adhoc distributed that might (maybe not as Fossil per se) be very useful to many workflows.
Put another way- how often do git workflows have you push/pull from multiple remotes when you're ready to deploy (or at all)? In the vast majority of workflows that I've seen and used you generally have one authoritative remote. Something like Fossil would make it so that a push/pull to any remote is effectively the same thing.
This is from the author of SQLite, which I would say is pretty bloat free, so I would think that he has applied the same development style to Fossil.
I've stayed away from fossil as an SCM because it doesn't have the traction that others do (I personally prefer mercurial), but I have used it a few times where I needed a wiki and bug tracker, setup is about as simple as you can get.
The bloat in this case is not necessarily dependencies or size of code base. It's features, and compared to other VCS's that don't have a wiki, bug tracking, an entire web server etc on board by default.
The value of having tickets directly (which are fossil artifacts) be able to reference/link-to other artifacts (checkins, events, other tickets) is something that maybe needs to be tried to be fully appreciated. When repos are clones, all that info travels w/ the repository, so there's never a broken record of what's happened. The webserver is also really handy for interfacing the repo. It serves it's purpose well, and I personally wouldn't wish it away. Whether it's something as simple as an ad-hoc "fossil ui" to run the server and load a view into firefox for a quick glimpse at the timeline, or running it fulltime so a dev. team can get a better clue of their branching/merging, it's a nice feature.
I can see calling the wiki, and blog part of it bloat but bug tracking seems like a good thing to keep with the repo. If you are some where without network access, and you commit a bug fix you can update the bug tracker right then and there. No chance of forgetting to do it latter.
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.
"The lack of a 'rebase' function is considered a feature of Fossil, not a bug."
It's not as if rebase is commonly used. It's there for those rare instances when you, say, remove a file that it turns out you don't have the copyright for and need to purge it completely, or that huge binary file some newb (ok, it was me) committed a while back that's not needed and makes cloning take 10 minutes.
Fossil looks really exciting to me- I've used git a ton and like it but don't really delude myself into thinking it can't be disrupted. But, seriously, you're missing a critical feature; instead of trying to patronize your would-be future users by defensively stating that it's a "good thing and we're proud of this missing functionality"- you could simply state something along the lines of "In general we think not having the equivalent of rebase is a good thing, but should you seriously need something like it, this is opensource and we'd love for you to contribute..." etc.
[Edit: I'm referring to git-filter-branch etc. to remove those things, not the rebase command per se, but in context of the original page's "Immutable==good" argument I interchanged the two]
This is widly incorrect. Powerusers of Git use rebase extensively, pretty much every patch that makes it into Git itself has been rebased at least half a dozen times.
I rewrite my history constantly, because when writing code I commit all the time, then I squash commits together later and give them proper commit messages.
I wouldn't use any SCM tool that wouldn't give me this functionality. The result of recording all history permanently is that users will just not commit their incomplete work, meaning that it'll be in their working tree instead of tracked in some form by the repository.
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 keeping garbage like "oops, fix typo" out of history is lying to your fellow developers-- a VCS should be aiding development, not forcing others to see your little mistakes.
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 if the artifact is re-introduced via a pull from some other repo, the shun that was previously applied will still be in effect, and keep the artifact from being further propagated by this repo.
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.
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.
Fossil would have to be much better than Git for me to take a serious look. I'm not interested in micro-optimizing every single piece of my toolkit. Git is the DVCS with all the momentum and mindshare and it does what I need it to do. I have bigger fish to fry.
"I suppose my biggest concern with Fossil and NetBSD is how Fossil might scale. We use Fossil on projects with a 1GB or larger check-out and with thousands and thousands of files. But I didn't really design fossil for truly huge projects."
I'm all for competition, but how do they come across saying that Git is complex while Fossil is intuitive? Is it possible to still be intuitive while still being a "complex" system? I'm not exactly a Git master, but I have had absolutely no troubles using it after getting everything setup.
if you stash everything you're not committing, then the working copy becomes the staging area, and the stash becomes the working copy. how is that any different?
seems to me both systems have a method of choosing what to commit, in git you can choose to stash or stage, in the others you can only stash since they "don't have a staging area". git++ for having both options.
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.
Use case: A commit should only do one thing at a time, but sometimes I'm not as organized. I like to do a whole mess of work and when I'm ready to commit it, I use git add --patch to separate out unrelated bits of work into separate commits--even if separate bits of work end up in the same file. It's amazing how much a load off your mind this is--you don't have to be quite as OCD while you're coding if you're a little fastidious about your commits later on.
I pretty much exclusively commit like that nowadays. I use commit-patch (http://porkrind.org/commit-patch) which is a pretty thin layer around git but also has emacs integration so you can just diff, edit your hunks with emacs hunk editing tools and then commit the patch. I can't imagine using a VC without the capability any more...
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?
There is when they have significantly different properties/workflows. I happen to think Darcs is supremely good for web development (probably not at facebook scale though)--it's the triviality with which you can cherry-pick patches that makes it wonderful to fast track bug fixes up to the live site while sitting on bigger, more untested changes.
I use Git when I'm releasing binaries to people (because I like its tagging better) or when I have to track some upstream code and merge in some local changes.
Fossil is also one of the few options when you're working on windows without admin rights. Saved me from being completely without vcs in a couple of previous job posts.
This is FUD. Git never erases history; it merely moves mutable refs around. When you rebase a branch called "master", nothing is rewritten: a new immutable commit history is created, and the ref "master" is moved from pointing at the old history to pointing at the new history. The old history still exists in all its glory at "master@{0}". (And when you change that, it goes to master@{1}, and so on.)
If git didn't have the concept of refs, then this would never even worry anyone. Once you have commit ab387df, it's refers to the same sequence of changes for all eternity. What master points to may change out from under you, but the history never goes anywhere.
The only way to "rewrite history" is to delete every copy of the repository ever made, which is exactly how you would rewrite history with Fossil or Subversion or anything.
(And now, if I may, a digression. I've noticed that the "rewriting history" aspect of Git makes for a good personality test. It's strongly polarizing -- the people that think source control is designed to be documentation love it, and the people that think source control is an audit mechanism hate it. Control freaks hate git, and long-haired hippies seem to love it.)