On Mon, Feb 4, 2013 at 9:58 PM, Derek Gaston <fried...@gmail.com> wrote:
> Yes, I just made up that acronym, but I like it. ;-)
>
> I thought I would bring this discussion (that some of us were having on my
> recent Pull Request) to the list.
>
> If you haven't been following the GitHub conversation... I made an
> off-hand comment about how I fetched, fixed up, rebased on libmesh/master
> and pushed my patch instead of using "pull" (or merging through GitHub) so
> that my patch went in cleanly without any merge commits.
>
> This prompted a bit of discussion... where Ben said he thought that you
> shouldn't rebase public branches. I was going to respond with:
>
> There is nothing wrong with rebasing feature branches. You don't want to
> rebase _master_ (or any long lived multiply shared branch that is going to
> continue to be shared for a long time).
>
> For instance, I rebased my precond_fix branch on master so that I could
> cleanly push it (no merge commit!). I also pushed the rebased branch
> (using --force) back to my libMesh fork. Did the world explode? Did
> everyone instantly die?
>
Haha - not so fast, I'm sure there are a few pillow factories left to
check! :p
Seriously though, if Derek has managed to convince you that rebase is
better then merge. There are a couple of options you can throw in your
.gitconfig so that happens by default. You can manage these options
globally or on a branch by branch basis.
http://viget.com/extend/only-you-can-prevent-git-merge-commits
> Nope. No one cares because the worst that was going to happen is if one
> of you guys had pulled that branch to check my changes you would get a
> forced update next time you pulled that branch again. No one was building
> lots of patches on top of my branch or merging it with other feature
> branches or anything else bizarre.
>
> You don't have to take my word for it though. Look at the diaspora
> development wiki here:
>
> https://github.com/diaspora/diaspora/wiki/Git-Workflow
>
> They are using the model that Roy was talking about earlier on the list...
> and let me point you to this main bullet point:
>
> *Do not merge* the upstream develop with your feature branch; *rebase* your
> branch on top of the upstream develop.
>
> Those bold words are theirs... not mine.... but I wholeheartedly agree.
>
> Our little feature branches should always be rebased before being pushed
> to master... which means no merge commits (with our current repo
> structure). If we ever go to a more involved structure with multiple
> long-lived branches (like a development branch, master, and release
> branches) then we will have merges when we merge back and forth between
> those.
>
> Feature branches should never generate merge commits.
>
> Derek
>
>
> ------------------------------------------------------------------------------
> Free Next-Gen Firewall Hardware Offer
> Buy your Sophos next-gen firewall before the end March 2013
> and get the hardware for free! Learn more.
> http://p.sf.net/sfu/sophos-d2d-feb
> _______________________________________________
> Libmesh-devel mailing list
> Libmesh-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/libmesh-devel
>
>
------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
