Ok, I should have say "in this case, use 'git rebase -p origin/develop' to
preserve your 'merged branch commit' from being rewriten/flattened, then you
can push.", I guess that's more english.
As I don't know how I can explain that clearlier, just tell me what you want
me to give some more details.
Thanks,
-Fred
-----Message d'origine-----
From: Justin Mclean
Sent: Thursday, March 21, 2013 7:42 AM
To: dev@flex.apache.org
Subject: Re: [OT] Log history
Hi,
You should always do a "git pull --rebase" before pushing except, AFAIK
when you have a "merged local banch not yet push", from the tests I did on
my git lab relative to the info Desa gave, I can't see an other situation
where a "git pull --rebase" rewrite/flattened your merged commit (and
should not), in this particular case, you do a "git pull -ff-only" instead
(Which refuse to merge and exit with a non-zero status unless the current
HEAD is already up-to-date or the merge can be resolved as a
fast-forward), in this case, use "git rebase -p origin/develop" to
preserve your "merged branch commit" to be rewrite/flattened, then you can
push.
Sorry that's just too confusing to follow. Can you put that into words that
a non git user would understand?
Justin
