I try not to use EGit for these things. It's not the most stable piece of software. Cherry-picking and rebasing are related but are 2 different things. cherry-picking is done to pick one or more commits from one branch and apply them on another. Rebasing is used to move your commits over different branches, reorder them, move other commits before your commits, etc.
Rebasing is one of the most powerful features of git, but it also has a major drawback: it changes your commits. Therefore, you should never rebase commits that you have already pushed to a remote repository. To port a change from 1.5 to 6.0, a cherry-pick usually works fine for me: in 1.5.x: git commit -m "my commit" got to wicket 6: git fetch wicket-1.5 (fetches the commit i just did on wicket-1.5) git cherry-pick wicket-1.5/wicket-1.5.x Emond On Friday 06 January 2012 15:55:15 Johan Compagner wrote: > the thing is i like the first approach if that one works, > why? Because then i am forced to first merge it over all revisions before i > can then push it upstream at once > > i never can push right to wicket if i just make a change in 1.4 or 1.5, i > need to think and open 1.5 and or trunk first and do there my stuff > > The only thing is that merge doesn't work for me yet, i get an error: > > Merge of revisions 56ab23584fcb1c3949e69255078239c85dacea69, > 6fec67349a165fb109d93497275ed73f3734f634 with base > 4c482e88eb9f3a74fac01c0a127f1e6be0df59fb using strategy resolve resulted > in: Failed. > > when i have pushed it from 1.4 to 1.5 and then i want to merge it so i > select the project -> team -> merge (merge tool is disabled, anybody knows > how to get that in eclipse and what that is?) > or cherry-picking (rebase i guess) also doesn't work for me. > > > > > On Fri, Jan 6, 2012 at 15:42, Bertrand Guay-Paquet > > <ber...@step.polymtl.ca>wrote: > > From what I understand, your solution would work well. You would have: > > wicket-trunk remote = gitHub > > wicket_14 remote = wicket-trunk > > wicket_15 remote = wicket-trunk > > > > What Renaud and and Edmond described is instead: > > wicket-trunk remotes = [gitHub, wicket_14, wicket_15] > > wicket_14 remotes = [gitHub, wicket-trunk, wicket_15] > > wicket_15 remotes = [gitHub, wicket_14, wicket-trunk] > > > > With the second way, you can push a change directly from one of your > > working dir clones to all the others at once. See > > http://stackoverflow.com/**questions/5620525/git-pushing-** > > to-two-repos-in-one-command<http://stackoverflow.com/questions/5620525/g > > it-pushing-to-two-repos-in-one-command>and > > http://stackoverflow.com/**questions/5785549/able-to-** > > push-to-all-git-remotes-with-**the-one-command<http://stackoverflow.com/ > > questions/5785549/able-to-push-to-all-git-remotes-with-the-one-command> > > . > > > > I too am new to git so I'd like to know if there are disadvantages to > > the > > second approach. > > > > Bertrand > > > > On 06/01/2012 9:11 AM, Johan Compagner wrote: > >> Ok, its getting clearer and clearer, > >> The thing is what i want is that i can make make a change for 1.4, 1.5 > >> and master/trunk > >> And do that all locally > >> Then push that to the remove at once. > >> > >> I guess what i just need to do for that is pull 1 git repo from > >> remote, > >> Get there the 3 branches at onces, > >> > >> that is inside a dir: > >> > >> \wicket_trunk\ (.git) > >> > >> and that is the also my wicket_trunk workspace and master is checked > >> out > >> > >> then go to the wicket_15 workspace > >> clone my local wicket_trunk to that workspace and checkout wicket_15. > >> go to the wicket_14 workspace > >> clone again the wicket_trunk to that workspace and checkout wicket_14. > >> > >> then when i make a change first in 1.4 workspace, i push that to > >> 'remote' which is still local (the trunk repo) > >> then i go to 1.5 workspace, i first do a pull from trunk, merge the > >> changes > >> that i got from 1.4 > >> commit/push that and then i just do an merge in the 1.6/trunk/master > >> repo. > >> > >> then everything is merged and i have in my 1.6/trunk repo all the > >> changes over the 3 branches and i push that to the remove wicket at > >> onces > >> > >> johan > >> > >> > >> On Fri, Jan 6, 2012 at 14:28, Renaud Bruyeron<bruye...@fullsix.com> > >> > >> wrote: > >> > >> 2012/1/4 Johan Compagner<jcompag...@gmail.com**>: > >>>> What is then the nicest way? > >>>> Because must i then do a commit the local on 1.4 push that to the > >>>> remote then go to 1.5 and pull it, then merge the 1.4 changes to > >>>> 1.5, commit>>> > >>> that > >>> > >>>> (this could be slightly different because of some changes) > >>>> push that again to remote, > >>>> and then do that for trunk/master/1.6 all over again? > >>> > >>> "You must unlearn what you have learned" - Yoda :) > >>> > >>> I find that the hardest thing with git is to remove the mental > >>> blocks > >>> inherited from subversion's centralized model. > >>> > >>> Just clone twice in /home/jc/wicket5 and /home/jc/wicket6, check out > >>> the correct branch in each, then setup 2 eclipse workspaces (one > >>> each). > >>> Then add remote references to be able to push/pull between the two. > >>> Then the process is what you describe, except you do not need to go > >>> to > >>> the remote origin, you can just move code between your 2 clones via > >>> push/pull, and then merge back and forth: for example while in > >>> /home/jc/wicket5, you do git pull local6 to bring in the changes in > >>> the 6 branch, you can then do the merge/cherry locally) > >>> When you are done, you can push to the remote origin. > >>> > >>> Renaud
