Re: git and multiple workspaces with the 2 branches and 1 trunk (master?)
trying for quite some hours now to set it up nicely the solution described in that link below doesn't work for windows users, that just makes a copy. for windows users this script must be used: http://git.661346.n2.nabble.com/Fwd-git-git-new-workdir-for-Windows-9-td6479570.html (run it as an admin else the symbolic links won't be created) That seems to work, the only problem i currently facing is that when i do a synchronize in eclipse all files are marked as changed (which of course none of them are) Even a hard reset on the branch will not fix that. So still not really a workable nice solution for this problem :( johan On Wed, Jan 4, 2012 at 16:43, Emond Papegaaij emond.papega...@topicus.nlwrote: With git, switching between branches is very fast, but as you said, with Eclipse it's not. You can have a look at this: http://finik.net/2010/10/24/multiple-working-folders-with-single-git- repository/http://finik.net/2010/10/24/multiple-working-folders-with-single-git-%0Arepository/ Another solution is to use git remotes to link the clones using (local) remotes. You can add a remote using 'git remote add name path', after which you can push/fetch changes between your workspaces directly. Personally, I use this last approach, but that's mainly because I do not yet feel comfortable enough to play with git internals :) Emond On Wednesday 04 January 2012 16:25:32 Johan Compagner wrote: Currently i just have 3 workspaces for wicket (1.4,1,5 and trunk/master) But git works with a/one working directory... thats always one of those.. So is the only solution to have the remote git repo dumped three times on my disk? I don't find that very logical.. And no i don't want to constantly switch, i could do that with wicket if really needed, but i find that annoying because i also look for our self (and eclipse projects also now move) and there i have really all kind of changes in 1 when i want to go to the other... And clicking between eclipse instances is way faster (i always have 3 or more eclipse instances open on various workspaces) johan
Re: git and multiple workspaces with the 2 branches and 1 trunk (master?)
Are you sure that the changed files is caused by the multi-workspace setup? It could also be a problem with the core.autocrlf option. At Topicus, we decided to turn it off on all systems. EGit doesn't support it and caused more trouble than it does good. Personally, I still like the solution with remotes. For example, I've got 2 workspaces for wicket: 1.5 and 6. I've added a remote to both: git remote add wicket-1.5 /home/papegaaij/workspaces/wicket-production git remote add wicket-6 /home/papegaaij/workspaces/master Now, when I commit on 1.5, I go to the other workspace and do a 'git fetch wicket-1.5'. This fetches my latest commit, which I can now cherry-pick onto wicket-6. For the application I work on for Topicus, I even use it to transfer entire branches from one workspace to another. Emond On Friday 06 January 2012 13:58:19 Johan Compagner wrote: trying for quite some hours now to set it up nicely the solution described in that link below doesn't work for windows users, that just makes a copy. for windows users this script must be used: http://git.661346.n2.nabble.com/Fwd-git-git-new-workdir-for-Windows-9-td6479 570.html (run it as an admin else the symbolic links won't be created) That seems to work, the only problem i currently facing is that when i do a synchronize in eclipse all files are marked as changed (which of course none of them are) Even a hard reset on the branch will not fix that. So still not really a workable nice solution for this problem :( johan On Wed, Jan 4, 2012 at 16:43, Emond Papegaaij emond.papega...@topicus.nlwrote: With git, switching between branches is very fast, but as you said, with Eclipse it's not. You can have a look at this: http://finik.net/2010/10/24/multiple-working-folders-with-single-git- repository/http://finik.net/2010/10/24/multiple-working-folders-with-si ngle-git-%0Arepository/ Another solution is to use git remotes to link the clones using (local) remotes. You can add a remote using 'git remote add name path', after which you can push/fetch changes between your workspaces directly. Personally, I use this last approach, but that's mainly because I do not yet feel comfortable enough to play with git internals :) Emond On Wednesday 04 January 2012 16:25:32 Johan Compagner wrote: Currently i just have 3 workspaces for wicket (1.4,1,5 and trunk/master) But git works with a/one working directory... thats always one of those.. So is the only solution to have the remote git repo dumped three times on my disk? I don't find that very logical.. And no i don't want to constantly switch, i could do that with wicket if really needed, but i find that annoying because i also look for our self (and eclipse projects also now move) and there i have really all kind of changes in 1 when i want to go to the other... And clicking between eclipse instances is way faster (i always have 3 or more eclipse instances open on various workspaces) johan
Re: git and multiple workspaces with the 2 branches and 1 trunk (master?)
what is the best way to set that ? or turn that off? i tried this http://stackoverflow.com/questions/1510798/trying-to-fix-line-endings-with-git-filter-branch-but-having-no-luck/1511273#1511273 but still many many outgoing changes. On Fri, Jan 6, 2012 at 14:09, Emond Papegaaij emond.papega...@topicus.nlwrote: core.autocrlf
Re: git and multiple workspaces with the 2 branches and 1 trunk (master?)
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
Re: git and multiple workspaces with the 2 branches and 1 trunk (master?)
Well, you'd rather not rewrite the entire wicket history using filter-branch, or your co-committer (of which I am now one) will be very upset and angry. You can find information on git configuration at http://progit.org/book/ch7-1.html . It also contains a section about core.autocrlf. Just turn it off (unset to option or set it to false) and reset your repo. I'm not sure if this is done using 'git checkout .' or 'git reset --hard HEAD' after changing autocrlf. Cloning again also fixes it :) Emond On Friday 06 January 2012 14:26:38 Johan Compagner wrote: what is the best way to set that ? or turn that off? i tried this http://stackoverflow.com/questions/1510798/trying-to-fix-line-endings-with-g it-filter-branch-but-having-no-luck/1511273#1511273 but still many many outgoing changes. On Fri, Jan 6, 2012 at 14:09, Emond Papegaaij emond.papega...@topicus.nlwrote: core.autocrlf
Re: git and multiple workspaces with the 2 branches and 1 trunk (master?)
It seems to be fine now, when i do the cloning completely in eclipse with that property in the eclipse preferences set to false. On Fri, Jan 6, 2012 at 14:42, Emond Papegaaij emond.papega...@topicus.nlwrote: Well, you'd rather not rewrite the entire wicket history using filter-branch, or your co-committer (of which I am now one) will be very upset and angry. You can find information on git configuration at http://progit.org/book/ch7-1.html . It also contains a section about core.autocrlf. Just turn it off (unset to option or set it to false) and reset your repo. I'm not sure if this is done using 'git checkout .' or 'git reset --hard HEAD' after changing autocrlf. Cloning again also fixes it :) Emond On Friday 06 January 2012 14:26:38 Johan Compagner wrote: what is the best way to set that ? or turn that off? i tried this http://stackoverflow.com/questions/1510798/trying-to-fix-line-endings-with-g it-filter-branch-but-having-no-luck/1511273#1511273 but still many many outgoing changes. On Fri, Jan 6, 2012 at 14:09, Emond Papegaaij emond.papega...@topicus.nlwrote: core.autocrlf
Re: git and multiple workspaces with the 2 branches and 1 trunk (master?)
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
Re: git and multiple workspaces with the 2 branches and 1 trunk (master?)
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 Bruyeronbruye...@fullsix.com wrote: 2012/1/4 Johan Compagnerjcompag...@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
Re: git and multiple workspaces with the 2 branches and 1 trunk (master?)
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.cawrote: 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-commandhttp://stackoverflow.com/questions/5620525/git-pushing-to-two-repos-in-one-commandand http://stackoverflow.com/**questions/5785549/able-to-** push-to-all-git-remotes-with-**the-one-commandhttp://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 Bruyeronbruye...@fullsix.com wrote: 2012/1/4 Johan Compagnerjcompag...@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
Re: git and multiple workspaces with the 2 branches and 1 trunk (master?)
hmm i HATE command line i almost never use that, and i am not planning to use it much now, i really think that is what an IDE is for! This is just going back to the dark ages of the 90's or something Tooling like this should just be next, next, finish in my eyes, quick and easy. We are already 12 years into this century! with svn what i did was all in the UI of eclipse commit a set of file that belong to each other for a specific fix/feature in branch X in Eclipse install/instance X then go to Eclipse instance Y that i already always have open, say Team-Merge a nice merge clients comes up, a few next next, select exactly which commit i want, finish and i am done... thats 1 commit command in Eclipse X, 1 Merge command and 1 Commit command in Eclipse Y and i am done, nothing more. I have currently also no idea if a push did really work for me for https://issues.apache.org/jira/browse/WICKET-4325 i pushed this as far as i now know to wicket1.4.x, wicket1.5.x and master (should i use master or trunk?) johan On Fri, Jan 6, 2012 at 16:11, Emond Papegaaij emond.papega...@topicus.nlwrote: 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.cawrote: 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-commandand 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
Re: git and multiple workspaces with the 2 branches and 1 trunk (master?)
I also really like a UI better with scrollable file lists and multiple panels way better than command line for version control. I'm also on Windows and have started using Git Extensions (http://code.google.com/p/gitextensions/). From my recent experiments, it works really well and is quite fast. Of course, the only downside is that it's not integrated to Eclipse. On 06/01/2012 10:20 AM, Johan Compagner wrote: hmm i HATE command line i almost never use that, and i am not planning to use it much now, i really think that is what an IDE is for! This is just going back to the dark ages of the 90's or something Tooling like this should just be next, next, finish in my eyes, quick and easy. We are already 12 years into this century! with svn what i did was all in the UI of eclipse commit a set of file that belong to each other for a specific fix/feature in branch X in Eclipse install/instance X then go to Eclipse instance Y that i already always have open, say Team-Merge a nice merge clients comes up, a few next next, select exactly which commit i want, finish and i am done... thats 1 commit command in Eclipse X, 1 Merge command and 1 Commit command in Eclipse Y and i am done, nothing more. I have currently also no idea if a push did really work for me for https://issues.apache.org/jira/browse/WICKET-4325 i pushed this as far as i now know to wicket1.4.x, wicket1.5.x and master (should i use master or trunk?) johan On Fri, Jan 6, 2012 at 16:11, Emond Papegaaijemond.papega...@topicus.nlwrote: 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.cawrote: 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-commandand 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
Re: git and multiple workspaces with the 2 branches and 1 trunk (master?)
i have a friend of mine that is also a long time eclipse users and he has now a few months a job where they have to use Intellij his qoute from a few days (after using it now for quite a while) ago: btw, intellij sucksnah, eclipse is way ahead so i guess thats a matter of taste.. The good thing is that Eclipse itself (all the core plugins) are moving to GIT, so that will boost the eclipse plugin a lot if they eat there own ... On Fri, Jan 6, 2012 at 16:26, Martin Grigorov mgrigo...@apache.org wrote: Recently I switched to Intellij IDEA because I think Eclipse doesn't evolve :-) and I'm quite happy I'm a command line user mostly but for first time I decided to give the UI a chance to deal with the SCM for me and so far I'm quite happy with IDEA's integration for Git.
git and multiple workspaces with the 2 branches and 1 trunk (master?)
Currently i just have 3 workspaces for wicket (1.4,1,5 and trunk/master) But git works with a/one working directory... thats always one of those.. So is the only solution to have the remote git repo dumped three times on my disk? I don't find that very logical.. And no i don't want to constantly switch, i could do that with wicket if really needed, but i find that annoying because i also look for our self (and eclipse projects also now move) and there i have really all kind of changes in 1 when i want to go to the other... And clicking between eclipse instances is way faster (i always have 3 or more eclipse instances open on various workspaces) johan
Re: git and multiple workspaces with the 2 branches and 1 trunk (master?)
Hi Johan, You can have one working directory (aka local repository) with these three branches and switch between them with git checkout or the same command in EGit. You can also have 3 working directories - one for each branch. This way you can load them at once in one Eclipse instance of each one in its own Eclipse instance. I personally use the first approach for now. On Wed, Jan 4, 2012 at 5:25 PM, Johan Compagner jcompag...@gmail.com wrote: Currently i just have 3 workspaces for wicket (1.4,1,5 and trunk/master) But git works with a/one working directory... thats always one of those.. So is the only solution to have the remote git repo dumped three times on my disk? I don't find that very logical.. And no i don't want to constantly switch, i could do that with wicket if really needed, but i find that annoying because i also look for our self (and eclipse projects also now move) and there i have really all kind of changes in 1 when i want to go to the other... And clicking between eclipse instances is way faster (i always have 3 or more eclipse instances open on various workspaces) johan -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
Re: git and multiple workspaces with the 2 branches and 1 trunk (master?)
On Wed, Jan 4, 2012 at 4:25 PM, Johan Compagner jcompag...@gmail.com wrote: Currently i just have 3 workspaces for wicket (1.4,1,5 and trunk/master) But git works with a/one working directory... thats always one of those.. So is the only solution to have the remote git repo dumped three times on my disk? I don't find that very logical.. It is logical: it is no different than having 3 checkouts of SVN living on your hard disk. A git checkout with full history is probably the size of O(1) of a SVN checkout (especially for SVN 1.7). You can still use your normal flow just as you'd do with SVN. If you don't like having to wait for the full checkout coming from the apache server, you can easily just clone locally, and set the remote afterwards. You don't have to use the one folder for all branches paradigm, but you can. Or I can, or Igor can, or Emond can. With git we have a choice ourselves. WIth SVN not so. Martijn
Re: git and multiple workspaces with the 2 branches and 1 trunk (master?)
What you need is a separate working directory managed by the same local repo. There's a script git new-workdir in contrib/ that does that for you. See http://nuclearsquid.com/writings/git-new-workdir/ for details. Carl-Eric www.wicketbuch.de On Wed, 4 Jan 2012 16:25:32 +0100 Johan Compagner jcompag...@gmail.com wrote: Currently i just have 3 workspaces for wicket (1.4,1,5 and trunk/master) But git works with a/one working directory... thats always one of those.. So is the only solution to have the remote git repo dumped three times on my disk? I don't find that very logical.. And no i don't want to constantly switch, i could do that with wicket if really needed, but i find that annoying because i also look for our self (and eclipse projects also now move) and there i have really all kind of changes in 1 when i want to go to the other... And clicking between eclipse instances is way faster (i always have 3 or more eclipse instances open on various workspaces) johan
Re: git and multiple workspaces with the 2 branches and 1 trunk (master?)
With git, switching between branches is very fast, but as you said, with Eclipse it's not. You can have a look at this: http://finik.net/2010/10/24/multiple-working-folders-with-single-git- repository/ Another solution is to use git remotes to link the clones using (local) remotes. You can add a remote using 'git remote add name path', after which you can push/fetch changes between your workspaces directly. Personally, I use this last approach, but that's mainly because I do not yet feel comfortable enough to play with git internals :) Emond On Wednesday 04 January 2012 16:25:32 Johan Compagner wrote: Currently i just have 3 workspaces for wicket (1.4,1,5 and trunk/master) But git works with a/one working directory... thats always one of those.. So is the only solution to have the remote git repo dumped three times on my disk? I don't find that very logical.. And no i don't want to constantly switch, i could do that with wicket if really needed, but i find that annoying because i also look for our self (and eclipse projects also now move) and there i have really all kind of changes in 1 when i want to go to the other... And clicking between eclipse instances is way faster (i always have 3 or more eclipse instances open on various workspaces) johan
Re: git and multiple workspaces with the 2 branches and 1 trunk (master?)
Yes i don't care to much about the disk space But if i make a commit in to 1.4 that also want to merge over 1.5 and trunk 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? Of course this can all be different i am just starting to look at git, so i maybe don't see all the different handles.. But the above approach is quite a bit harder and way more steps (at least it looks that way to me now) then what i would do with svn.. (using the merge client shipped with subclipse) On Wed, Jan 4, 2012 at 16:40, Martijn Dashorst martijn.dasho...@gmail.comwrote: On Wed, Jan 4, 2012 at 4:25 PM, Johan Compagner jcompag...@gmail.com wrote: Currently i just have 3 workspaces for wicket (1.4,1,5 and trunk/master) But git works with a/one working directory... thats always one of those.. So is the only solution to have the remote git repo dumped three times on my disk? I don't find that very logical.. It is logical: it is no different than having 3 checkouts of SVN living on your hard disk. A git checkout with full history is probably the size of O(1) of a SVN checkout (especially for SVN 1.7). You can still use your normal flow just as you'd do with SVN. If you don't like having to wait for the full checkout coming from the apache server, you can easily just clone locally, and set the remote afterwards. You don't have to use the one folder for all branches paradigm, but you can. Or I can, or Igor can, or Emond can. With git we have a choice ourselves. WIth SVN not so. Martijn
Re: git and multiple workspaces with the 2 branches and 1 trunk (master?)
Git switching could be very vast But between 1.4 and 1.5 there are really project changes (like wicket-core and just wicket) So if i switch between them in eclipse, i constantly get all kind of compile warnings... And if i reflect that again on our own servoy product (if we would also go to git) this is really not doable, i have also there 3 to 4 active branches and there from branch to branch the number of projects are completely different! because in eclipse plugins you just create quite a lot of projects, so every new branch has a few more projects Then switching it is just quite annoying if you ask me, because you constantly have to get eclipse into sync. I will look at the multiply working folders option, that really looks be me the best way. On Wed, Jan 4, 2012 at 16:43, Emond Papegaaij emond.papega...@topicus.nlwrote: With git, switching between branches is very fast, but as you said, with Eclipse it's not. You can have a look at this: http://finik.net/2010/10/24/multiple-working-folders-with-single-git- repository/http://finik.net/2010/10/24/multiple-working-folders-with-single-git-%0Arepository/ Another solution is to use git remotes to link the clones using (local) remotes. You can add a remote using 'git remote add name path', after which you can push/fetch changes between your workspaces directly. Personally, I use this last approach, but that's mainly because I do not yet feel comfortable enough to play with git internals :) Emond On Wednesday 04 January 2012 16:25:32 Johan Compagner wrote: Currently i just have 3 workspaces for wicket (1.4,1,5 and trunk/master) But git works with a/one working directory... thats always one of those.. So is the only solution to have the remote git repo dumped three times on my disk? I don't find that very logical.. And no i don't want to constantly switch, i could do that with wicket if really needed, but i find that annoying because i also look for our self (and eclipse projects also now move) and there i have really all kind of changes in 1 when i want to go to the other... And clicking between eclipse instances is way faster (i always have 3 or more eclipse instances open on various workspaces) johan