Re: [PATCH 0/3] Reject non-ff pulls by default

On Sat, Sep 07, 2013 at 11:37:13PM -0500, Felipe Contreras wrote:

On Sat, Sep 7, 2013 at 11:18 PM, Jeff King [off-list ref] wrote:

quoted

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.

quoted

  $ 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