[PATCH] Allow fast-forward pushing.

[PATCH] Allow fast-forward pushing.

Pushing patches is too slow. It's a lot slower than quilt, and possibly
even slower than patch-scripts.

Especially, we never fast-forward patches even when we can, because when we
reorder patches that's not always safe.

It is safe to fast-forward a patch sequence if the first patch in the
sequence "chains" correctly with the current HEAD and each patch chains
with the previous one. With chaining I mean "HEAD commit id matches the
bottom id of the patch".

In this patch I fast-forward the longest possible sequence starting from
the first patch.

Since a single commit stores via parent links the entire history, after a
patch doesn't chain there's almost no need to try to chain other patches.

Actually it could maybe happen (but I'm not trying to exploit that case):
create a patch stack, pop it, apply a couple of subsequent patches out of
order (so it's reparented), pop it, and repush the stack in the old order.

The chained sequence will stop at the changed patch, but (should we reuse
the old commit id when repushing, and we can, provided we delete the .old
file when refreshing) we'd reapply again the same commits.

TODO: do fast-forward even when just the tree objects chain, but the
commits don't (for instance, after changing a patch description, we can't
fast-forward with this patch). We can do that with git-commit-tree, which
creates a new commit based on a given tree, parent, description, without
necessarily checking it out.

Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>