Fri, Feb 19, 2010 at 07:59:35PM -0500, Frédéric Brière wrote:
> I'd argue for the empty commit, since I didn't actually remove anything
> from the rebase list. I can always go back and purge it later if I so
> wish.
Hmm, there is something subtle here then. When rebasing a patch series
with rebase or am, if one of my patches is already included upstream, I
would want it excluded, not replaced with an empty commit. Indeed,
that is something rebase already does by using rev-list --cherry-pick
--left-right to generate the list of commits to apply.
apply A --- E --- apply C [upstream]
/
base --- A --- B --- C --- D [master]
should become and does become
base --- apply A --- E --- apply C [upstream] --- B --- D [master]
On the other hand, if one of my patches was already an empty commit,
or in your case where the effect of commits to be squashed cancel each
other out, it makes sense to say the intention is to create an empty
patch, I agree. If I had wanted to remove the patch, I could always
explicitly remove it from the list.
The problem comes in a third case: what if some of my patches were
included upstream, with some other changes squashed in?
apply A+C --- E [upstream]
/
base --- A --- B --- C --- D [master]
rev-list --cherry-pick will correctly note that my patch is not among
those included upstream, so rebase will try to apply it. If the
squashed-in change doesn’t conflict with my change, that will succeed
without conflicts, resulting in an empty patch. I would like that
patch to be omitted from the resulting history.
base --- apply A+C --- E [upstream] --- B --- D [master]
How to achieve both? One could (and maybe should) use heuristics
like “empty commits should be forward-ported without complaint”.
In more complicated situations like squashes, I think the best thing
is to ask the human driver which situation we are in: is this an empty
marker, with an important commit message, or a superseded patch to
discard?
I will look into improving the error message. If you have other ideas
for improving the behavior and a little time, I encourage you to patch
git-rebase--interactive.sh to try them out and send the results to
[email protected].
Jonathan
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
