Re: [Plplot-devel] Rebase workflow
Hi, Phil.
On Feb 22, 2015, at 4:52 AM, Phil Rosenberg wrote:
>> In addition to Alan's suggestion, another approach would be to setup a
>> >local bare git repo that all your local machines could push/pull to/from.
>
> I tried this. As soon as I rebase a branch I am no longer able to push
> it to the local bare repo because all the changes made since the last
> push no longer exist and are replaced with new ones with different
> guids.
I started to write that I don't understand why you are not able to push to the
local bare repo and I created much of the text below. In doing so, I realized
the problem you are having. You are absolutely correct that you cannot push a
rebased branch to the original branch because the commit IDs have changed. You
will need to push the rebased branch to a new branch. There are two ways to do
this. One is to create a "topic-rebase" branch from the "topic" branch, rebase
the "topic-rebase" branch and then push the "topic-rebase" branch. The other
way is to rebase the "topic" branch and give it a new name when you push it to
the local bare repo. Below I show the first option, which I prefer because it
keeps the original topic branch intact.
1) Start from the "master" branch that has commit "C" as the current HEAD:
A--B--C <-{master, origin/master}
2) Create a "topic" branch and create commits "d" and "e" on it:
A--B--C <-{master, origin/master}
\
+--d--e <-{topic}
3) Push "topic" to your "local" repo:
A--B--C <-{master, origin/master}
\
+--d--e <-{topic, local/topic}
4) Using other local machines, push/pull the topic branch to/from the local
repo and it ends up with additional commits "f" and "g":
A--B--C <-{master, origin/master}
\
+--d--e--f--g <-{topic, local/topic}
5) Fetch from origin, find that some else has pushed commits X and Y to master,
and fast-forward your master to match it:
git fetch origin
git co master
git merge --ff-only origin/master
A--B--C--X--Y <-{master, origin/master}
\
+--d--e--f--g <-{topic, local/topic}
6) Create and checkout a new "topic-rebase" branch that is based on the "topic"
branch:
git co -b topic-rebase topic
A--B--C--X--Y <-{master, origin/master}
\
+--d--e--f--g <-{topic, topic-rebase, local/topic}
7) Create and checkout a new "topic-rebase" branch that is based on the "topic"
branch:
git co -b topic-rebase topic
A--B--C--X--Y <-{master, origin/master}
\
+--d--e--f--g <-{topic, topic-rebase, local/topic}
8) Rebase the "topic-rebase" branch onto the new master, which will create new
commits "d'", "e'", "f'", and "g'" that correspond to commits "d", "e", "f",
and "g". These new commits will contain the same changes (assuming no
conflicts with commits X and Y) as their counterparts and have the same log
messages, but each commit will have different parent (e.g. d' has parent Y
while d has parent C) and probably different trees (due to changes from X and
Y) so they have different commit IDs. This step could involve conflicts that
need to be resolved, but this assumes that wasn't necessary:
git rebase origin/master
A--B--C--X--Y <-{master, origin/master}
\ \
\ +--d'--e'--f'--g' <-{topic-rebase}
\
+--d--e--f--g <-{topic, local/topic}
9) Push "topic-rebase" to the local bare repository:
git push local topic-rebase
A--B--C--X--Y <-{master, origin/master}
\ \
\ +--d'--e'--f'--g' <-{topic-rebase, local/topic-rebase}
\
+--d--e--f--g <-{topic, local/topic}
10) Other local machines can fetch from the local bare repo and they will get
the topic-rebase branch and all of its commits. Everything looks good, time to
share with the world!
11) Fast forward "master" to "topic-rebase":
git co master
git merge --ff-only topic-rebase
A--B--C--X--Y <-{origin/master}
\ \
\ +--d'--e'--f'--g' <-{master, topic-rebase, local/topic-rebase}
\
+--d--e--f--g <-{topic, local/topic}
12) Push master to the "origin" repo:
git push origin master
A--B--C--X--Y--d'--e'--f'--g' <-{master, topic-rebase, local/topic-rebase,
origin/master}
\
+--d--e--f--g <-{topic, local/topic}
Hope this helps,
Dave
--
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
Re: [Plplot-devel] Rebase workflow
Hi Alan Thanks for the thoughts. I will try your option II, but I suspect that the two rebases will give different guide to the reapplied commits so I will not be able to do a --ff-only merge between the two. I suspect the same might occur for your option III, however that process is getting so complex that it is easier to delete the branch from my derived repos and restart. Thanks again Phil -Original Message- From: "Alan W. Irwin" Sent: 22/02/2015 17:32 To: "Phil Rosenberg" Cc: "David MacMahon" ; "PLplot development list" Subject: Re: [Plplot-devel] Rebase workflow On 2015-02-22 12:52- 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. Ev
Re: [Plplot-devel] Rebase workflow
On 2015-02-22 12:52- 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 (
Re: [Plplot-devel] Rebase workflow
> In addition to Alan's suggestion, another approach would be to setup a >local > bare git repo that all your local machines could push/pull to/from. I tried this. As soon as I rebase a branch I am no longer able to push it to the local bare repo because all the changes made since the last push no longer exist and are replaced with new ones with different guids. > Out of curiosity, how did you handle this situation when using Subversion? I didn't. I wasn't so involved when we were using svn, so firstly I only really worked on my Windows machine and secondly if I needed to work on something and stash it away I literally copied it to another folder. >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. I realised that basically this means that as soon as I rebase a branch it must be purged from all my repos on all my machines. This isn't really ideal and sometimes things slip through. I think I'm getting the hang of it more as time goes on, but life would be easier if I didn't have to get the hang of it. It's just a comment into the debate about merge vs rebase workflow, I'm certainly not demanding we change, just wanted to make people aware of the restriction, see if anyone had any better suggestions and make sure this is considered if we do ever have a debate about changing. Phil -- 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
Re: [Plplot-devel] Rebase workflow
On Feb 21, 2015, at 4:59 PM, Alan W. Irwin wrote: > On 2015-02-21 20:53- Phil Rosenberg wrote: > >> Basically the rebase workflow is causing me some real problems trying >> to use multiple machines to test my changes. I have a Windows laptop, >> which is my main machine, then I have also been trying to test on my >> work Centos PC and my Ubuntu PC. To do so I have to share my main >> repository from my Windows Laptop with the other computers. However, >> every time I rebase a branch to commit it I end up unable to push to >> my Linux computers because history that they depend upon has been >> rewritten. This is becoming a real pain. >> >> I don't suppose anyone has any suggestions? > > The git format-patch and git am method has recently worked well to > share experimental development work from one of your computers to > mine. So why not use that exact method also when sharing experimental > development work between your various computers? Hi, Phil, In addition to Alan's suggestion, another approach would be to setup a local bare git repo that all your local machines could push/pull to/from. You could use this repo to share your (not yet rebased) topic branch among your local machines. When you are ready to rebase your topic branch, you would do so on one of your machines and then push the rebased branch. The other machines could then be brought up to date by fetching the rebased branch. This can work because git repositories can have more than one "remote" that they push/pull from/to. The remote for the cloned-from repo is usually called "origin", but you can add additional remotes to any repository. See "git help remote" for more details. Out of curiosity, how did you handle this situation when using Subversion? Thanks, Dave -- 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
Re: [Plplot-devel] Rebase workflow
On 2015-02-21 20:53- Phil Rosenberg wrote: > Hi all > This may not be an ideal time to bring this up, but if I don't do it > now I will probably forget. > > Basically the rebase workflow is causing me some real problems trying > to use multiple machines to test my changes. I have a Windows laptop, > which is my main machine, then I have also been trying to test on my > work Centos PC and my Ubuntu PC. To do so I have to share my main > repository from my Windows Laptop with the other computers. However, > every time I rebase a branch to commit it I end up unable to push to > my Linux computers because history that they depend upon has been > rewritten. This is becoming a real pain. > > I don't suppose anyone has any suggestions? Hi Phil: The git format-patch and git am method has recently worked well to share experimental development work from one of your computers to mine. So why not use that exact method also when sharing experimental development work between your various computers? 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
[Plplot-devel] Rebase workflow
Hi all This may not be an ideal time to bring this up, but if I don't do it now I will probably forget. Basically the rebase workflow is causing me some real problems trying to use multiple machines to test my changes. I have a Windows laptop, which is my main machine, then I have also been trying to test on my work Centos PC and my Ubuntu PC. To do so I have to share my main repository from my Windows Laptop with the other computers. However, every time I rebase a branch to commit it I end up unable to push to my Linux computers because history that they depend upon has been rewritten. This is becoming a real pain. I don't suppose anyone has any suggestions? Phil -- 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
