On Sat, Sep 07, 2013 at 11:37:13PM -0500, Felipe Contreras wrote: > On Sat, Sep 7, 2013 at 11:18 PM, Jeff King <peff@xxxxxxxx> wrote: > > By "svn-like", I mean the people whose workflow is: > > > > $ hack hack hack > > $ git commit > > $ git push ;# oops, somebody else pushed in the meantime > > $ git pull > > $ git push It's possible that some teams at work may be using this workflow. It's more likely that there would be a rebase if the push failed, but some teams might do a merge. I don't know because we don't dictate workflow to individual teams for the reasons I get into below. Regardless, merges are our typical workflow, so forcing rebase mode all the time wouldn't be appropriate for us. > > $ hack hack hack > > $ svn commit ;# oops, somebody else committed in the meantime > > $ svn update > > $ svn commit > > > > Those people would now have to learn enough to choose between merge and > > rebase when running the "git pull". > > But that's only if they don't care about the shape of history. In my > experience the people that cling more to centralized VCS do not like > merges, so they rebase everything to make it a straight line. That is > much more "svn-like". > > So chances are they are already doing 'git pull --rebase' (or > similar), so their workflow wouldn't be affected. We end up squashing each project branch into one commit (usually using git reset --soft), so we don't care about the shape of history. Over the course of a project branch, in fact, there may be many merges from the main release branches (including other projects), so history is going to be very messy otherwise. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
Attachment:
signature.asc
Description: Digital signature