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
