Fred, Don't get me wrong, I really appreciate your tireless efforts of the last few weeks! I was specifically addressing - as of now unnamed - 'others' with this request. What I'm hoping to see is more task-based and Flex/Apache/NVIE oriented step-by-steps. All the tutorials and most comments by experienced git users tell me that you can only really learn git by using it (after you've mastered the basic commands), and a walk-through is always very useful to get new users doing just that.
So, you take a well deserved break from explaining git and let someone else handle this request ;-) 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:42, Frédéric THOMAS wrote: > 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: [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 > > 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
