And the one I wrote at the end of the long post as well is a good
illustration of branching/rebasing/resolving conflicts
-Fred
-----Message d'origine-----
From: Erik de Bruin
Sent: Friday, March 22, 2013 11:16 AM
To: dev@flex.apache.org
Subject: Re: [OT] Log history
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
