Hi, Alan, On Sep 22, 2014, at 12:37 PM, Alan W. Irwin wrote:
> You are much more experienced with git than me. However, I thought > that rebasing a public branch was always a bad idea for the reasons I > mentioned concerning disappearing commits. I am positive a number of > resources I read when we were considering using a rebase workflow > mentioned this drawback to that approach. I agree that rebasing any part of a branch that has been pushed is a bad idea. It makes things complicated/inconvenient for those who are following the branch. > If they are right, then for rebase workflows like ours experimental > branches should not be made accessible on public git repos since the > bad choices afterwards are to rebase them periodically (which loses > prior public commits) to keep up with master development or else > become out of date with master. I can understand the desire for a nice clean linear history, especially since the code was just migrated from Subversion. Strict adherence to a rebase only workflow will definitely result in a nice clean linear history. Starting with a strict "rebase only workflow" requirement, the statement quoted above sounds reasonable, but the "experimental branches should not be made accessible on public git repos" part of it really sounds wrong to me. It makes me wonder whether a strict rebase only workflow is really best. > Which means some other alternative for > sharing experimental development topics must be used such as sending > patches to this list. My feeling is that working with such patches is > unlikely to be much of a burden since git has such good facilities > (format-patch and am) for generating and using such patches. Emailing patches is tedious and error prone. Yes, git has good facilities for this, but it has even better facilities for sharing changes: pushing to public repos. Asking developers to refrain from pushing their experimental branches to public repos is somewhat hobbling, IMHO. > Of course, if after we have gained some substantial experience with > the patch method for the special case of sharing experimental > development, we find that method is inhibiting our experimental > development, we should move to a merge workflow instead like suggested > by Brad King. But for now, let's give a good trial (at least 6 > months) to our current rebase workflow including its constraint (if > the resources I read are not overstating the case) that developers > should refrain from sharing their experimental branches via public > repos because it leads to bad further choices that typically come back > to haunt you with a rebase workflow. I am not familiar with Brad King's merge workflow, but I think allowing some merge commits can be a good thing. A compromise between a rebase-only workflow and an unconstrained merge workflow would be to allow merge commits on master but only if the first parent of such merge commits is also on the master branch. Developers would still be allowed (encouraged?) to follow a rebase-as-much-as-possible workflow, but they could also push their experimental branches to public repos without having to worry about rebasing them later. This would allow for a concise summary of changes on master by running "git log --oneline --first-parent master". Each non-merge commit on master would be shown along with the merge commit from each (non-rebased) topic branch, but the topic branch commits themselves would not be shown (because we passed "--first-parent"). Personally, I find merge commits to be a helpful way of partitioning the history of a project, especially when using gitk or "git log --graph". They are kind of analogous to subdirectories in that not having merge commits is kind of like keeping all your files in one directory. When running "git log --graph", merge commits make it easy to see which commits "go together" because they are shown on the same topic/experimental branch. Without merge commits, everything is just one lone thread of development. Of course it is possible to overuse merge commits, but generally if a topic branch is significant enough to share before rebasing it to master, then it's probably significant enough to warrant a merge commit on master when the time comes to bring the topic branch back into the fold. Hope this helps, Dave ------------------------------------------------------------------------------ Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
