Wed Jan 18 13:28:45 CST 2012
On Wed, Jan 18, 2012 at 10:57, Jason Grout <email@example.com> wrote:
> On 1/18/12 12:50 PM, Brian Granger wrote:
>>>> What did I do wrong when I merged this? I rebased in on master and then
>>>> >> did:
>>>> >> git co master
>>>> >> git merge branchname
>>>> >> git push upstream master
>>> > If you rebased the branch on master, it is possible that the merge was a
>>> > "fast-forward", i.e. a merge commit was not needed since the history merged
>>> > in from the branch could be brought in as a set of patches that applied
>>> > cleanly on top of master without the need for conflict resolution.
>>> > To force a merge commit, use `git merge --no-ff branchname`.
>> Ahh, yes, I imagine this is exactly what happened. Thanks for the
>> clarification - my git-fu is definitely out of shape right now...
> For the rest of us learning more about git...why would a fast-forward
> merge be bad enough to do a force push? Is it just that it is against
> the policy of (almost) always doing --no-ff?
The fast-forward merge is *not* the reason for the force push, though
we are now trying to avoid fast-forward merges, because it gives us a
nicer view of PRs in the git tree. This is not particularly
important, though, just a style preference.
The force-push was caused by the introduction of a submodule, which
introduced incompatibility with (bzr-based) downstream projects.
Since we don't actually use submodules, and IPython only had one for a
single commit, it didn't make sense to keep permanent
incompatibilities based on something we don't actually use, especially
since the problematic commit was only a few days old.
> IPython-dev mailing list
More information about the IPython-dev