Andre Poenitz wrote: > On Fri, Mar 06, 2009 at 07:29:54AM -0600, Bo Peng wrote: > > > Not quite true. In a git world, a bug fixing would _always_ happen in a > > > specific branch and be merged to the main repo when it's done; > > > > This is not that useful if we keep the one developer - one feature > > developing model. Right now, when you work on a feature, all others > > are forced to check it out and test for you. If you use git, your > > feature is unlikely to be well tested (if no one else check out your > > branch) before merge and bigger merges just increase the chance of > > conflict and decrease early review. > > [I never thought I might become a git advocate *sigh*, anyway...] > > There's nothing wrong with treating the centralized repo pretty much > the same way as LyX svn trunk is currently treated. You can push your > work pretty much in the same chunks as you would today.
but the flamed point was not about _pushing_. rather it was about commit identification and further orientation (hash vs commit number). > _On top of that_ you _can_ have branches that are far, far easier to > handle than svn branches. I'd even argue that (to come back on this > Friday's topic) some of the past losses like the XML branch would > not have occured as switching between branches is fast and cheap > and people are more likely to "have a quick look". arrrgh ... branches switching is not fast and cheap! i got so frustrated with the perpetual waiting for recompilations because somebody touch this and that header that i started using more git trees in the same way as in the old days of svn. pavel
