On 06-11-2011 02:37, Jesse Phillips wrote:
On Sat, 05 Nov 2011 15:15:37 -0700, Jonathan M Davis wrote:
So, I should probably add the question more explicitly, what exactly
does using --rebase gain other than not having the extra commit message?
Why is it better?
- Jonathan M Davis
My quick search:
http://book.git-scm.com/4_rebasing.html
Suggests that it will recreate all the changes at the point of merge
rather than having a commit with two parents. This would mean the history
shows all changes of a branch at the point of merge rather intermixed
based on date.
One downside to this is that it is a form of history rewrite. And if I
understand how git works, this means that the branch in SomeOnes
repository will not correspond to any commits in the rebased master.
Meaning pulling the latest Phobos into said branch wouldn't work. Usually
after a merge the branch would be dead anyway.
I don't know if it is done elsewhere but the general rule is not to
rewrite history in a published repository, this would be doing just that,
so I would not recommend it.
Rewriting history in forks is perfectly fine. In fact, many people
generally consider it polite for contributors to clean up their history
using rebase before sending changes upstream.
- Alex
