You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Johan Compagner <jc...@gmail.com> on 2012/01/04 16:25:32 UTC
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?)
Posted by Johan Compagner <jc...@gmail.com>.
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 sucks.... nah, 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 <mg...@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.
>
Re: git and multiple workspaces with the 2 branches and 1 trunk (master?)
Posted by Martin Grigorov <mg...@apache.org>.
On Fri, Jan 6, 2012 at 5:20 PM, Johan Compagner <jc...@gmail.com> 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.
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.
>
> 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?)
Use master, not trunk. We have to delete trunk branch to avoid this confusion.
According to mail notifications you pushed to 1.4.x, 1.5.x and master.
According to BuildBot the build of 1.4.x failed with something
unrelated to your change.
>
> johan
>
>
> On Fri, Jan 6, 2012 at 16:11, Emond Papegaaij <em...@topicus.nl>wrote:
>
>> 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
>> >
>> > <be...@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<br...@fullsix.com>
>> > >>
>> > >> wrote:
>> > >>
>> > >> 2012/1/4 Johan Compagner<jcompagner@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
>>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
Re: git and multiple workspaces with the 2 branches and 1 trunk (master?)
Posted by Bertrand Guay-Paquet <be...@step.polymtl.ca>.
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 Papegaaij<em...@topicus.nl>wrote:
>
>> 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
>>>
>>> <be...@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<br...@fullsix.com>
>>>>>
>>>>> wrote:
>>>>>
>>>>> 2012/1/4 Johan Compagner<jcompagner@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?)
Posted by Johan Compagner <jc...@gmail.com>.
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 <em...@topicus.nl>wrote:
> 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
> >
> > <be...@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<br...@fullsix.com>
> > >>
> > >> wrote:
> > >>
> > >> 2012/1/4 Johan Compagner<jcompagner@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?)
Posted by Emond Papegaaij <em...@topicus.nl>.
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
>
> <be...@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<br...@fullsix.com>
> >>
> >> wrote:
> >>
> >> 2012/1/4 Johan Compagner<jcompagner@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?)
Posted by Johan Compagner <jc...@gmail.com>.
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
<be...@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<br...@fullsix.com>
>> wrote:
>>
>> 2012/1/4 Johan Compagner<jcompagner@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?)
Posted by Bertrand Guay-Paquet <be...@step.polymtl.ca>.
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<br...@fullsix.com> wrote:
>
>> 2012/1/4 Johan Compagner<jc...@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?)
Posted by Johan Compagner <jc...@gmail.com>.
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 <br...@fullsix.com> wrote:
> 2012/1/4 Johan Compagner <jc...@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?)
Posted by Renaud Bruyeron <br...@fullsix.com>.
2012/1/4 Johan Compagner <jc...@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?)
Posted by Johan Compagner <jc...@gmail.com>.
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
<ma...@gmail.com>wrote:
> On Wed, Jan 4, 2012 at 4:25 PM, Johan Compagner <jc...@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?)
Posted by Martijn Dashorst <ma...@gmail.com>.
On Wed, Jan 4, 2012 at 4:25 PM, Johan Compagner <jc...@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?)
Posted by Johan Compagner <jc...@gmail.com>.
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 <em...@topicus.nl>wrote:
> 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
> <em...@topicus.nl>wrote:
> > > core.autocrlf
>
Re: git and multiple workspaces with the 2 branches and 1 trunk (master?)
Posted by Emond Papegaaij <em...@topicus.nl>.
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
<em...@topicus.nl>wrote:
> > core.autocrlf
Re: git and multiple workspaces with the 2 branches and 1 trunk (master?)
Posted by Johan Compagner <jc...@gmail.com>.
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 <em...@topicus.nl>wrote:
> core.autocrlf
Re: git and multiple workspaces with the 2 branches and 1 trunk (master?)
Posted by Emond Papegaaij <em...@topicus.nl>.
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
<em...@topicus.nl>wrote:
> > 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?)
Posted by Johan Compagner <jc...@gmail.com>.
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 <em...@topicus.nl>wrote:
> 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?)
Posted by Johan Compagner <jc...@gmail.com>.
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 <em...@topicus.nl>wrote:
> 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?)
Posted by Emond Papegaaij <em...@topicus.nl>.
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?)
Posted by Martin Grigorov <mg...@apache.org>.
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 <jc...@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?)
Posted by Carl-Eric Menzel <cm...@wicketbuch.de>.
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 <jc...@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