On Sat, Sep 07, 2013 at 11:37:13PM -0500, Felipe Contreras wrote:
> On Sat, Sep 7, 2013 at 11:18 PM, Jeff King <p...@peff.net> 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

Reply via email to