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<emond.papega...@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
<ber...@step.polymtl.ca>wrote:
From what I understand, your solution would work well. You would have:
wicket-trunk remote = gitHub
wicket_14 remote = wicket-trunk
wicket_15 remote = wicket-trunk
What Renaud and and Edmond described is instead:
wicket-trunk remotes = [gitHub, wicket_14, wicket_15]
wicket_14 remotes = [gitHub, wicket-trunk, wicket_15]
wicket_15 remotes = [gitHub, wicket_14, wicket-trunk]
With the second way, you can push a change directly from one of your
working dir clones to all the others at once. See
http://stackoverflow.com/**questions/5620525/git-pushing-**
to-two-repos-in-one-command<
http://stackoverflow.com/questions/5620525/g
it-pushing-to-two-repos-in-one-command>and
http://stackoverflow.com/**questions/5785549/able-to-**
push-to-all-git-remotes-with-**the-one-command<
http://stackoverflow.com/
questions/5785549/able-to-push-to-all-git-remotes-with-the-one-command>
.
I too am new to git so I'd like to know if there are disadvantages to
the
second approach.
Bertrand
On 06/01/2012 9:11 AM, Johan Compagner wrote:
Ok, its getting clearer and clearer,
The thing is what i want is that i can make make a change for 1.4, 1.5
and master/trunk
And do that all locally
Then push that to the remove at once.
I guess what i just need to do for that is pull 1 git repo from
remote,
Get there the 3 branches at onces,
that is inside a dir:
\wicket_trunk\ (.git)
and that is the also my wicket_trunk workspace and master is checked
out
then go to the wicket_15 workspace
clone my local wicket_trunk to that workspace and checkout wicket_15.
go to the wicket_14 workspace
clone again the wicket_trunk to that workspace and checkout wicket_14.
then when i make a change first in 1.4 workspace, i push that to
'remote' which is still local (the trunk repo)
then i go to 1.5 workspace, i first do a pull from trunk, merge the
changes
that i got from 1.4
commit/push that and then i just do an merge in the 1.6/trunk/master
repo.
then everything is merged and i have in my 1.6/trunk repo all the
changes over the 3 branches and i push that to the remove wicket at
onces
johan
On Fri, Jan 6, 2012 at 14:28, Renaud Bruyeron<bruye...@fullsix.com>
wrote:
2012/1/4 Johan Compagner<jcompag...@gmail.com**>:
What is then the nicest way?
Because must i then do a commit the local on 1.4 push that to the
remote then go to 1.5 and pull it, then merge the 1.4 changes to
1.5, commit>>>
that
(this could be slightly different because of some changes)
push that again to remote,
and then do that for trunk/master/1.6 all over again?
"You must unlearn what you have learned" - Yoda :)
I find that the hardest thing with git is to remove the mental
blocks
inherited from subversion's centralized model.
Just clone twice in /home/jc/wicket5 and /home/jc/wicket6, check out
the correct branch in each, then setup 2 eclipse workspaces (one
each).
Then add remote references to be able to push/pull between the two.
Then the process is what you describe, except you do not need to go
to
the remote origin, you can just move code between your 2 clones via
push/pull, and then merge back and forth: for example while in
/home/jc/wicket5, you do git pull local6 to bring in the changes in
the 6 branch, you can then do the merge/cherry locally)
When you are done, you can push to the remote origin.
Renaud
