that's not actually what rebase is doing. Rebase is rewriting the commit
history so it looks nice. It's not required to keep changes merged
answer in the previous post.
However doing so with pull (or fetch+merge)does the same thing, without
the crazy flags or potential for really bad results
Yes, only if there's nothing to merge, as soon as the remote HEAD is ahead
of my branch HEAD, I'll have an extra merge commit I don't want in order to
keep a clean, linear and readable history.
Thanks,
-Fred
-----Message d'origine-----
From: Michael A. Labriola
Sent: Sunday, March 24, 2013 12:45 AM
To: dev@flex.apache.org
Subject: RE: [Git/Wiki] please review the proposed workflow and comment
Sorry of you get multiple copies of this. I keep getting bounce messages. I
messed up and sent a draft in my last response. I didn't want it to be more
confusing, so, if you can.
Read me instead:
First of all, I use pull with the rebasing option to keep my work on top of
what the others already pushed until there's no issues for my local merges.
that's not actually what rebase is doing. Rebase is rewriting the commit
history so it looks nice. It's not required to keep changes merged
Yes, it might have been an option but I preferred to rebase to make people
to get the habit of getting the others' commits before starting a working
session, making the eventual conflicts resolved first.
That was my point too... However doing so with pull (or fetch+merge)does the
same thing, without the crazy flags or potential for really bad results. I
am just saying that's not really what rebase is doing for us here so I am
favoring the simpler approach.
How would you have write it so ?
I will write up something and post
I generaly do a "pull --rebase" + "git merge --no-ff" + "push" in the same
stream to avoid "git rebase -p", which, in case of conflict would make me
create an extra commit in more than the merge commit for the >same
feature/bugfix, with "rebasing first" solution, I can resolve the conflict,
rebase again and then have a merge up to date relative to the main stream.
Okay, although honestly, that seems a little bit like running before we
walk. All we are saving is, at most an extra commit to indicate the merge
and forcing people to understand rebase. Understand what I mean?
