On Tue, 29 Jan 2008, Ed S. Peschko wrote: > > One thing (besides horrible branching and even worse merging) which I > > hated in multi-user CVS is the "cvs update", namely the fact that if > > you want to commit changes, you _have_ to rebase them on top of > > current work. So when you are ready to commit, when you have tested > > everything, you are sometimes forced to resolve a merge to be able to > > commit... and have to test resolved merge... and perhaps again, and > > again. > > Yeah, I realize that it's not exactly the best solution for every > project, but for projects tied to a piece of hardware (ie: a database, a > particular box, etc), its much more important to be in sync, to have > 'one true view' of the world rather than to have the freedom to have > multiple views. Actually, it's a simpler concern: with CVS (and most version control systems), you can't make a permanent record of your state without resolving conflicts. With git, you make the permanent record first, and then resolve conflicts in order to get a state that includes your changes and can be pushed to the shared location. With git, you can still have "one true view" of the world; it's just that git really really doesn't want to lose your work, so it refuses to overwrite your files unless you've put them in its storage, where it can give them back if it does something wrong with your working tree. Of course, your "gvs update" could do a local git commit of the current state, fetch the remote changes, and rebase the local commit onto them, so it's not necessarily a workflow change. But note that, if the user fails to do a manual merge, the user can try again, or try working on a different branch, or fork at that point, depending on how hopeless the situation is. -Daniel *This .sig left intentionally blank* - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
