On Thu, Jan 3, 2013 at 2:20 PM, Roy Stogner <royst...@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
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122712
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
