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/git-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 >>> >>>
