On Thu, Jan 3, 2013 at 2:20 PM, Roy Stogner <roystgnr@ices.utexas.edu> wrote:
> But note that periodically rebasing a shared branch should probably be
> frowned upon, since that involves rewriting history (and push -f), and
> may affect others...

This is half of my trepidation.  Before using git, in my imagination
*every* branch was a shared branch.  E.g. suppose I'm futzing with
hierarchic model refinement, Paul is trying to get anisotropic h
refinement working, and I want to periodically check that my stuff
doesn't break his or vice versa.  Doesn't that become harder if our
branchs' revision history isn't actually our branchs' revision
history?

Actually - if we all work in our own cloned repos we shouldn't ever be "sharing" a branch.  "Sharing" implies that there is _one_ branch that more than one person is committing to simultaneously.  Just don't do that.

You should always be working in your own branch and rebase on top of others work.  Essentially, always create a local branch for a remote you want to work with.  The workflow for merging into libMesh's real master branch after checking out someone else's work should always look like this (using GitHub's own instructions against itself ;-)

(again assuming that you've followed the directions here again https://help.github.com/articles/fork-a-repo)


# Create a remote for someone's repo
git remote add cameronmcefee git://github.com/cameronmcefee/Spoon-Knife.git

# Pull down their branches
git fetch cameronmcefee

# Create a _local_ branch that is tracking one of their branches
git checkout -tb cambugfix cameronmcefee/bug-fix

# We've checked their changes and now we want to commit them to libMesh so we do:

# Pull down upstream's (main libMesh repo's) branches
git fetch upstream

# Rebase the new patches on top of master, this will ensure no merge commits and no history rewriting
git rebase upstream/master

# Push the new patches to the libMesh repo's master branch
git push upstream HEAD:master


This is akin to what we did with SVN: Someone emails you a patch.  You apply it.  You do an "svn update" to pull down any changes (this is fetch and rebase in Git).  Then you commit.

If you are working in your own branch in a clone of your libMesh fork and you are ready to push to the real libMesh repo's master just do this:

git fetch upstream
git rebase upstream/master
git push upstream HEAD:master

In this way we won't end up with any merge commits... nor will we have any "parallel universe" history stuff happening.  libMesh's master branch will _always_ be a linear history proceeding through time.... just like SVN.  Those three commands are akin to:

svn update
svn commit

Derek