Hi Erik,
I added a comment to the wiki with a link which to git basics explanations
but must be read and understood by all new git user IMO, once those basics
clear, which cover all what every boby asks at the moment, I might go
further writing someting on the wiki but before that I don't want to waste
my time (even I repeated myself a lot recently) on explainations already
written and even in a better way than I can do it.
-Fred
-----Message d'origine-----
From: Erik de Bruin
Sent: Tuesday, March 19, 2013 5:35 PM
To: dev@flex.apache.org
Subject: Re: [3/3] git commit: Merge branch 'develop' of
https://git-wip-us.apache.org/repos/asf/flex-sdk into develop
And now it's really time to explain this to - or rather: prescribe this
for - us mere mortals. I think a couple of simple use cases with the exact
steps/commands on the wiki (checkout, commit, push, pull) should be an
excellent start.
Time for some of the other very vocal git proponents to step up and actually
help out?
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl (http://www.ixsoftware.nl)
On Tuesday, March 19, 2013 at 17:07, Frédéric THOMAS wrote:
But to be short and resume what those links means:
You rebase your own commits, git pull --rebase (internaly: git fetch/ git
rebase) because you stay on your own branch
you git pull (internaly: git fetch / git merge) from another branch your
feature/bugfix branch you just completely coded.
And if you know that most of the time you will work on the develop branch,
you can forget the --rebase option setting: git config --global
branch.autosetuprebase always
-Fred
-----Message d'origine-----
From: Frédéric THOMAS
Sent: Tuesday, March 19, 2013 4:56 PM
To: dev@flex.apache.org (mailto:dev@flex.apache.org)
Subject: Re: [3/3] git commit: Merge branch 'develop' of
https://git-wip-us.apache.org/repos/asf/flex-sdk into develop
The first link says exactly what I'm saying, you want to put your changes
on
top of what everybody else has done.
'So "git rebase" is not wrong. But it's right only if it's YOUR VERY OWN
PRIVATE git tree.'
When you do a pull --rebase, you're rebasing only your commits on the top
of
the others commits, nothing before the origin/HEAD indeed.
The 2nd and especially the 3rd links tell as well what I'm saying, they do
a
final merge because there are on branches, in between they rebase their
own
commits:
clone the remote repo
git checkout -b my_new_feature
..work and commit some stuff
git rebase master
..work and commit some stuff
git rebase master
..finish the feature
git checkout master
git merge --squash my_new_feature
git branch -D my_new_feature
The 4th link:
Reason #1: Resolve conflicts once, instead of once for each commit
This case is rare but easy to resolve, you abort your rebase on multi
commits conflicts and to simplify your life, exceptionnaly, you do what he
says, you do a merge, messing the history though.
Reason #2: With rebase, there is no undo!
Doesn't apply, because, you will never rebase your feature branch on the
develop one but merge it and if you work directly on the develop branch,
you
will push a few of rebased commits which are yours.
And I'm tired now, I haven't read the last one.
-Fred
-----Message d'origine-----
From: Justin Mclean
Sent: Tuesday, March 19, 2013 4:20 PM
To: dev@flex.apache.org (mailto:dev@flex.apache.org)
Subject: Re: [3/3] git commit: Merge branch 'develop' of
https://git-wip-us.apache.org/repos/asf/flex-sdk into develop
Hi,
> NO, that's the opposite
Really?
https://wincent.com/wiki/git_rebase:_you're_doing_it_wrong
Dozen of stack overflow question on the issue which warn about rebasing.
For
instance:
http://stackoverflow.com/questions/8939977/git-push-rejected-after-feature-branch-rebase
"Rebase and a shared repository generally do not get along. This is
rewriting history. If others are using that branch or have branched from
that branch then rebase will be quite unpleasant."
http://stackoverflow.com/questions/457927/git-workflow-and-rebase-vs-merge-questions
"It really kills me that people are recommending a rebase workflow as a
better alternative to a merge workflow for conflict resolution"
"With rebase, there is no undo!"
Also
http://git-scm.com/book/en/Git-Branching-Rebasing#The-Perils-of-Rebasing
Again I'll ask do we really want this option to be the default?
Justin
