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
and
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
