"Ed S. Peschko" <esp5@xxxxxxx> writes: > We've been trying out git here for a while now, and we've noticed two > things that we both like and dislike: git's flexibility, and git's > flexibility. > > > Git's flexibility is great in the sense that power users can basically > bend git to their will, but its' flexibility is also causing workflow > issues in our environment, where beginning users can get lost in all > the options that it has, and this is causing communication issues for > these folks with the rest of our team. [...] > gvs update: > > Takes the latest changes, from all branches, that everyone > else has committed into the centralized git repository, and merges > them onto the current branch. [...] > We basically want this for managing related changesets - we want > to be able to switch from one patch branch to another and commit them > separately - but we don't want to sacrifice the automatic integration > that you get from cvs by doing: > > cvs update > > on a given branch. 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. Working on branches is much nicer IMVHO. And it allows to separate changes into series of small, incremental commits[*1*]. If you want to work in centralized or semi-centralized way, you probably would want to use rebase based workflow, with "git pull --rebase" (which just got implemented). Footonotes: =========== [*1*] I'd like to point to LKML post about creating perfect patch *series*, but I have forgot to bookmark it, and canot find it again (IIRC somebody posted link some time ago here on git mailing list). -- Jakub Narebski Poland ShadeHawk on #git - 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
