On Thu, Jan 3, 2013 at 3:20 PM, Roy Stogner <royst...@ices.utexas.edu> wrote: > > On Thu, 3 Jan 2013, John Peterson wrote: > >> It's an alternative to doing periodic merges (as e.g. Ben did with his >> recent meshfree interpolation branch). > > > Yup. And even with things like "git log --no-merges", the result of > those seems to be slightly annoying. When experimenting with "master > adds A, branch adds B, then we merge" the other day, I ended up with a > final history that looked to git diff something like "add A, then > remove A and add B, then add A again". It looks like a simple rebase > of the form Derek suggested would fix that. > > >> 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? > > >> I looked at this diagram for a while, and I like it, other than I >> probably wouldn't make such a big distinction between the yellow and >> green dots... > > > I like separating development vs. release-candidate branches. It > seems like an improvement over our traditional "okay, nobody commit > any big new features for a month while we get everything ready for > release" announcements. Of course, as long we can afford to regularly > buildbot/trac every test we have then there's not much of an issue > because we'll be able to keep development continuously at maximum > "readiness", but I've got some long-term ideas for increasing our test > coverage exponentially - good for hammering on the code as much as > possible every now and then (and for preemptively catching the kinds > of "only occurs in 3D on 24 processors" bugs we've previously only > found when an application hit them), but well beyond what we'd want to > have to run before every push to the main development branch. > --- > Roy
Roy, That page you linked is the workflow I use for my personal projects. Derek, your comment that '--no-ff' squashes commits is not true. There are several 'merge strategies' git has built in. When you merge, rebase or pull, git tries to figure out the simplest way to merge branches without causing merge conflicts. The one you will see most often is when you 'git pull' to update a local branch to reflect new changes implemented upstream. Usually the changes upstream are commits whose timestamp occurs in reverse chronological order. Thus, in order to update the the local branch, git can do something called a fast-forward merge which says "update me to the latest version". Since one doesn't really touch their local master branch, fast-forwards are used. If you had fiddled with your local master branch rather than branching off to patch something, git will create a merge commit. Now, fast-forwards will not only occur when you 'git pull' but can occur when you 'git merge' a branch whose commits can be cleanly played on top of your out-dated development branch, say. When git fast-forwards to merge a branch, no merge commit is made (otherwise when you git pull you would create pointless merge commits locally). I merge topic branches into my dev branch with the --no-ff option so I can see what history was merged. It's not necessary, but in my opinion a merge commit there is useful for my records. The --no-ff option does not 'squash' commits. It creates a merge commit, just like all the other merge strategies do. If you rebase a public branch everyone will hate you. Here's why: http://git-scm.com/book/en/Git-Branching-Rebasing#The-Perils-of-Rebasing Note, problems only occur when *others* are watching one of your branches. For example, when I'm reviewing a pull request for matplotlib, I often tell my contributors to rebase their branch against the current upstream/master branch. Why? I do this because then I don't have to fetch the branches and merge them locally myself. I just push the big green 'merge' button on github and, since it was rebased, there are no merge conflicts and github is happy. Github will not let you merge a branch if it will result in a conflict. For the most part, it is only matplotlib developers that fetch branches to try them out. Therefore if I, as a developer, tell someone to rebase a branch I have fetched, then presumably I know that branch is bad and I can re-fetch it cleanly once the rebase has happened. Also, if I ask someone to rebase a branch, I do it in a comment on the pull request page and there is a paper trail the other developers can take note of and exercise caution that the branch is likely to be rebased. Furthermore, note that most matplotlib pull request branches only have one committer: the person that submitted the pull request. I do not recommend rebasing branches that are heavily shared. If I rebased matplotlib's upstream/master branch *everybody* that follows the source, pull request or not, would get nastiness occurring locally and I would probably get heavily scorned. One last note: be careful with cherry-picking. I only cherry-pick small changes. And when I do, it's usually because the person that submitted a pull request didn't branch from the correct place. For matplotlib, bug fix branches should branch from the maintenance branch. They are then merged into the maintenance branch when they are complete. The maintenance branch is quasi-periodically merged into master to snarf all the bug fixes. When someone makes a very simple bug fix but branched from master instead of the maintenance branch, I can't 'git merge' their changes into the maintenance branch without including (possibly) API changes into the maintenance branch. This is where cherry-picking a bug-fix comes in handy. In short, you should never really have to do it if you stick to a consistent workflow. Matplotlib doesn't follow the workflow Roy linked to. All development is done on master and when we're about to release we 'git branch v1.2.x master' and unstable work can still be merged into master while preserving the stable 1.2 release branch. This is a simpler workflow than the one Roy linked to; there are less branches to deal with. If it's any consolation I have a ton of local matplotlib branches. Some are mine. Some are others' pull requests I forgot about and some are hacks that will take me months to develop. Note that this is just advice from my experience in working with git. It is not gospel and I do not claim to know what I am doing in the slightest. For example, I have to google how to resolve merge conflicts every time I get one, because I can never remember whether I need to 'git add' or not after I'm done. Also, you will mess up. I think one has to make a catastrophic mistake before learning what and/or what not to do. If you're unsure about something, try it on a separate branch and whatever you do, don't push upstream unless you are completely sure the changes you have made are safe. I messed up my local matplotlib master branch once, and I can tell you I will never do that again, I'm just glad I didn't push. At least now I know how to fix it if it happens again, which I'm sure will. This email is pretty long and opinionated. Feel free to ignore any or all of it. Best wishes, Damon -- Damon McDougall http://www.damon-is-a-geek.com Institute for Computational Engineering Sciences 201 E. 24th St. Stop C0200 The University of Texas at Austin Austin, TX 78712-1229 ------------------------------------------------------------------------------ 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
