Hi, On Wed, 13 Jun 2007, Bill Lear wrote: > Not completely: they don't want to commit, as this will then "pollute" > the history in their working repository (which is just temporarily > being used to play with a new feature, idea, bug fix, optimization, > etc.). This pollution with a handful of garbage would then have to be > undone were they to say "ok, that's really not a good idea". If a > pull into a dirty tree were possible, that last step could be just a > simple reset, or continuing to explore with the code, etc. Notice that I am _not_ saying that CVS is bad. I am saying that their workflow is likely bad (and yes, they should change that workflow, since they now _can_). Two things do they risk happily, which they should not do: - they test their new feature against different references. For example, it might well be that they tested cases A, B, and C before pull, and D, E and F after that. It is really easy to get lost in what you have, and what not. Now, guess what. Merges are known to break things sometimes. Even the best merge algorithm. Now your developers say "we tested it, and the merge broke it, it's not our fault". But it is. - That new feature will have to be committed at some stage. Either your devs commit at the end, which makes it a monster commit, which is bad. Or they are _already_ using the suggested workflow "commit && pull", which makes your whole complaint moot. Ciao, Dscho - 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
