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: [email protected] (mailto:[email protected]) > 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: [email protected] (mailto:[email protected]) > 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
