On 2015-02-22 12:52-0000 Phil Rosenberg wrote: >> The git format-patch and git am method has recently worked well to >> share experimental development work from one of your computers to >> mine. > This has the same downsides. As soon as I rebase a branch all patched > repos which included the rebased commits get screwed up, because the > commits they included from the patch no longer exist.
Let's take the following specific case to discuss this. Machine A has local branch x for which you prepare a patch series with "git format-patch" where the series includes all commits peculiar to the branch, i.e., back to where the local branch branches from official master. Machine B starts just with official master and you create a local branch y there with "git am" using the above patch series. So far so good. (This I know works well.) Then so long as you don't rebase, you should be able to prepare patch series of just your additional commits on Machine A branch x and propagate those additional patches to Machine B branch y with no issues. (I haven't tried this myself, but I assume it works.) Then there is a change to official master that you absolutely must have in your topic branch so on Machine A you rebase branch x with those official changes. This indeed changes all the commit id's for the commits on x since rebase is equivalent to saving all commits on the branch, removing all commits on the branch, fast-forwarding from master, then reapplying all the saved commits back to the branch (now with necessarily changed id's because the parent commit id's are different). Then you work some more on Machine A creating additional commits on branch x. Now you want to propagate all of these changes to Machine B branch y to test it there. Alternative I. Deleting Machine B branch y and replacing it from scratch with the rebased branch from Machine A branch x is what you are doing now, and that certainly should work. Alternative II. You could also rebase Machine B branch y on the official repo's master tip, and so long as it was the same tip commit id as for your rebase of Machine A branch x, then I believe that would make the common commit id's in Machine B branch y identical with the corresponding commit id's in Machine A branch x. Then we should be back to the original situation where additional commits on Machine A branch x can just be propagated to Machine B branch y. (Note, I also think this would work with Dave's scenario as well so long as the various rebases all corresponded to the same master tip commit.) Alternative III. If the order of the commits doesn't matter, then you could prepare two patch series from Machine A branch x. The first patch series would correspond to the rebased commits from master that Machine B branch y doesn't have yet, and the second patch series would consist of the additional changes in Machine A branch x that Machine B branch y doesn't have yet. Then apply those two series to Machine B branch y. Here is the schematic result where each letter represents a commit, and the three patch series are separated by "|" Machine A branch x ABCDE | FGHIJ | KLMNOP Machine B branch y FGHIJ | ABCDE | KLMNOP where ABCDE are the patch series from official master which were used to rebase Machine A branch x, FGHIJ are the patch series common to both Machine A branch x and Machine B branch y before the rebase and the additional work on Machine A branch x, and KLMNOP are the patch series representing the additional work done on Machine A branch x after the rebase, but before sharing the result with Machine B branch y. Note because of the changed order you would be in real trouble if you attempted to push from Machine B to official master. So you would have to remember to always push from Machine A. But otherwise, alternative III should work so long as the different order in which the commits are applied does not give you some sort of conflict. I honestly think alternative II (going through an identical rebase procedure) would work well either for the git format-path/am method or Dave's method so I favor that. And my own feeling is alternative III is likely an accident waiting to happen, but I decided to mention it anyway. Even if you decide to just continue to use alternative I, hopefully this discussion will help everyone sharpen their mental model of what is going on with git rebase and sharing topic branches. And, of course, if I had some typos or even fundamental mistakes in the above discussion, please correct. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
