I've written the proposed workflow (with commands) to the wiki (with Fred). Maybe we can base the discussion on that, not on general theory. In other words, please have a look at the wiki and give feedback (I'm creating a new thread for that) so we can perfect the specifics for this project.
Thanks, EdB On Fri, Mar 22, 2013 at 11:11 AM, Frédéric THOMAS <webdoubl...@hotmail.com> wrote: >> Sure for a feature (and especially when multiple people need to work on >> it) I see the benefit but for a single change to a single file? > > > As I said in the long post, no problem in this case, just, don't forget to > pull --rebase before pushing. > > >> nothing destructive using pull --rebase as soon as you understand when, >> where and why to use it. > > So why do the Git official docs state this? > "This is a potentially dangerous mode of operation. It rewrites history, > which does not bode well when you published that history already. Do not use > this option unless you have read git-rebase(1) carefully." > > The published history is never touched until you really want to do it on > purposed, you can't do it following the workflow I described. > > >> All of the basic tutorials I've seen don't use "git pull --rebase". > > > I can show you a lot recommanding to use it until your know how it works. > Actually, there's one only situation where you can re-write your own merge, > not the one of the others and I explained how to avoid it. > > > >> Know something once and for ever: rebasing preserve a good history and is >> not destructive > > What I don't understand is why it's so important to have a "clean" history > at the expense of making it easy to use. > > Once more, there's no risks as soon as you understand how to work with, it's > easy, push your merge as soon you did it. > Having a readable history allows everybody to understand what happened, see > our history graph, can you tell me what happened, maybe you yes, because you > did the pushes (but not even sure you'll be able to say it in one month) but > someone else ? > > Thanks, > -Fred > > > > -----Message d'origine----- From: Justin Mclean > Sent: Friday, March 22, 2013 10:58 AM > > To: dev@flex.apache.org > Subject: Re: [OT] Log history > > HI, > >> The point, in the example I provided was to illustrate how you should work >> from a branch > > Sure for a feature (and especially when multiple people need to work on it) > I see the benefit but for a single change to a single file? > >> nothing destructive using pull --rebase as soon as you understand when, >> where and why to use it. > > So why do the Git official docs state this? > "This is a potentially dangerous mode of operation. It rewrites history, > which does not bode well when you published that history already. Do not use > this option unless you have read git-rebase(1) carefully." > > All of the basic tutorials I've seen don't use "git pull --rebase". > >> Know something once and for ever: rebasing preserve a good history and is >> not destructive > > What I don't understand is why it's so important to have a "clean" history > at the expense of making it easy to use. > > Thanks, > Justin -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
