[kingkongrevenge]

> create a branch, hack for a while

$ cp -R project testbranch

> then either pull the changes into the trunk or abandon them

diff or rm -rf. And none of the nuisance of explicitly telling the VC system when you're adding, deleting, and renaming files.

[rcoder]

I'm not arguing with the value of a filesystem as a general-purpose organizational tool. However, it's a strictly weaker tool in terms of structure and semantics than a proper VCS. Also, not only does using a raw filesystem put the burden on you to remember the associations between branches and versions, it also gives you zero support for merging once those branches are made.

Git is pretty good about following renames, moves, and other changes to the underlying filesystem, while still maintaining a proper graph structure to relate revisions to each other. Fast network replication and mirroring is just another benefit, as is the ability to quickly merge changes from multiple branches.

Finally, as another commenter has already suggested, it's really just about establishing good habits as part of your workflow early. It's much like testing: if you start out with a decent test suite, you're much more likely to maintain and use it than you are if you have to overlay testing onto an established project. Similarly, if you have full version history from day 1, things will be much easier further down the road.