From d328cccacc66bc5d183790eebcf5a3334830ab55 Mon Sep 17 00:00:00 2001
From: Johannes Schindelin
+
+ There was a lengthy discussion on the Git mailing list about using Thunderbird,
+ a not quite unpopular mailing program, to send inline patches.
+
+ It is really kind of sad that the Thunderbird developers do not see how
+ stubbornly they offend quite a number of people and scare them away from their
+ program. After all, you should try to be liberal in what you accept and strict
+ in what you emit. No, that does not mean that you should force others to
+ switch their mailers because you strictly adher to your philosophy in what you
+ emit, ignoring the rest of the world.
+
+ In any case, I am not affected (as long as I do not get mails from a poor soul
+ stuck with Thunderbird).
+
+ But I was a bit mean to that Thunderbird guy I dragged into the discussion, and
+ he seems really offended.
+
+ So I thought I'd give him a real reason to feel offended: I'll just do his work:
+
+ http://repo.or.cz/w/UnFlowedThunderbird.git
+
+ It took my free time of two days, being not a Thunderbird developer myself.
+ Hopefully it works, and hopefully some people will feel really ashamed now.
+ Table of contents:
+
- Older posts
+ Older posts
Wednesday, 11th of February, Anno Domini MMIX, at the hour of the Tiger
+
+ Thunderbird, oh Thunderbird, you always make my small brain hurt
+
+ Monday, 9th of February, Anno Domini MMIX, at the hour of the Buffalo
format-patch --thread and Alpine
@@ -436,35 +465,6 @@ $ rm .git/interactive-stash-1 .git/interactive-stash-2
And safer: no more rnyn.
--
- I thought about the "dropped" commits a bit more, after all, and it is - probably a good thing to substitute them by their parent, as Stephen did it. -
- Imagine that you have merged a branch with two commits. One is in upstream, - and you want to rebase (preserving merges) onto upstream. Then you still - want to merge the single commit. -
- Even better, if there is no commit left, the $REWRITTEN mechanism will - substitute the commit onto which we are rebasing, so a merge will just - result in a fast-forward! -
- Oh, another thing: merge commits should not have a patch id, as they have - multiple patches. However, I borked the code long time ago (9c6efa36) - and merges get the patch-id of their diff to the first parent. Which is - probably wrong. So I guess I'll have to fix that with my rebase revamp. -
- So what about a root commit? If that was dropped, we will just substitute - it with the commit onto which we rebase (as a root commit did not really - have a parent, but will get the onto-commit as new parent).. -
- Now that I finally realized that t3410 is so strange because of a bug I - introduced, I can finally go about fixing it. -