From 2458bf42577d34aedf932dbda2e8f8553e07cee2 Mon Sep 17 00:00:00 2001
From: Johannes Schindelin
Date: Wed, 28 Jan 2009 01:35:19 +0100
Subject: [PATCH] Housekeeping on Wednesday, 28th of January, Anno Domini MMIX,
at the hour of the Buffalo
Signed-off-by: Johannes Schindelin
---
blog.rss | 80 ++++++++++++++++++++++-----------------------------
source-1232742582.txt | 39 -------------------------
2 files changed, 34 insertions(+), 85 deletions(-)
delete mode 100644 source-1232742582.txt
diff --git a/blog.rss b/blog.rss
index 2b21e93dfd..706d186cde 100644
--- a/blog.rss
+++ b/blog.rss
@@ -5,9 +5,42 @@
http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html
A few stories told by Dscho
-Wed, 28 Jan 2009 01:18:39 +0100
+Wed, 28 Jan 2009 01:35:19 +0100en-us
+Showing off that you're an Alpine user ... priceless!
+http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1233102919
+http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1233102919
+Wed, 28 Jan 2009 01:35:19 +0100
+
+So I was in a hurry to send the patches, and sent all the patches as replies
+to the cover-letter, and therefore typed in rnyn all the time, which is the
+mantra I need to say to Alpine for Reply, ... include quoted message?
+No, ... reply to all recipients? Yes, ... use first role?
+No, use default role.
+
+That was pretty embarassing, as it shows everybody that I still do not trust
+send-email, and rather paste every single patch by hand. Which is rather
+annoying.
+
+So I started using format-patch today, to output directly to Alpine's
+postponed-msgs folder, so that I can do some touchups in the mailer
+before sending the patch series on its way.
+
+However, when running format-patch with --thread, it generates Message-ID
+strings that Alpine does not like, and therefore replaces.
+
+Oh, well, I'll probably just investigate how the Message-IDs are supposed to
+look, and then use sed to rewrite the generated ones by Alpine-friendly ones
+during the redirection to postponed-msgs.
+
+But I alread realized that doing it that way is dramatically faster than the
+workflow I had before.
+
+And safer: no more rnyn.]]>
+
+Progress with the interactive rebase preserving merges
http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1233101919
http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1233101919
@@ -507,50 +540,5 @@ And of course, the original logo...
Maybe some of you have fun with them...]]>
-
-How to deal with files that are not source code when merging
-http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1232742582
-http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1232742582
-Fri, 23 Jan 2009 21:29:42 +0100
-
-Last week, one of the mentors of last year's
-Summer of Code mentioned the idea that merge strategies are in dear need
-for file types other than source code.
-
-I think this idea is awesome, even if I cannot bring myself to believe that
-any of the file types would make a good Summer of Code project: either they
-are too complicated (think raster images such as .png or even .jpg), or they
-are too straight-forward (think LaTeX, where all that is needed is a good
-graphical user interface to inspect the three versions: ours, baseline
-and theirs).
-
-The LaTeX idea would be a good project for me to mentor, though: I have a
-pretty clear idea how it should be done; I just lack the time (and motivation)
-to do it myself.
-
-As for OpenOffice text documents, vector graphics (such as .svg), or more
-specific data such as spreadsheets, I think that all of these are really
-difficult: the problem is not so much the implementation (i.e. the programming
-part of it), but the design.
-
-This design should involve much more than a Summer of Code project is about:
-you would need to survey users' expectations, and at least the mentor -- if
-not the student -- would need to be an expert in usability questions, which
-is rather unlikely in the realm of Open Source.
-
-Maybe this is the missing part in Open Source: we have many brilliant
-programmers, but next to nobody with a good idea how to design intuitive
-user interfaces.
-
-That might be related to the fact that brilliant software engineers, as they
-can be found in Open Source, are not exactly known for their social skills,
-a human trait that seems to be a very important prerequisite for designing
-intuitive user interfaces.
-
-Well, I have
-added the proposal to Git's Summer of Code idea page on the Git Wiki; We will
-see what comes out of it.]]>
-
diff --git a/source-1232742582.txt b/source-1232742582.txt
deleted file mode 100644
index 3117463aea..0000000000
--- a/source-1232742582.txt
+++ /dev/null
@@ -1,39 +0,0 @@
-How to deal with files that are not source code when merging
-
-Last week, one of the mentors of last year's
-Summer of Code mentioned the idea that merge strategies are in dear need
-for file types other than source code.
-
-I think this idea is awesome, even if I cannot bring myself to believe that
-any of the file types would make a good Summer of Code project: either they
-are too complicated (think raster images such as .png or even .jpg), or they
-are too straight-forward (think LaTeX, where all that is needed is a good
-graphical user interface to inspect the three versions: ''ours'', ''baseline''
-and ''theirs'').
-
-The LaTeX idea would be a good project for me to mentor, though: I have a
-pretty clear idea how it should be done; I just lack the time (and motivation)
-to do it myself.
-
-As for OpenOffice text documents, vector graphics (such as .svg), or more
-specific data such as spreadsheets, I think that all of these are really
-difficult: the problem is not so much the implementation (i.e. the programming
-part of it), but the design.
-
-This design should involve much more than a Summer of Code project is about:
-you would need to survey users' expectations, and at least the mentor -- if
-not the student -- would need to be an expert in usability questions, which
-is rather unlikely in the realm of Open Source.
-
-Maybe this is the missing part in Open Source: we have many brilliant
-programmers, but next to nobody with a good idea how to design intuitive
-user interfaces.
-
-That might be related to the fact that brilliant software engineers, as they
-can be found in Open Source, are not exactly known for their social skills,
-a human trait that seems to be a very important prerequisite for designing
-intuitive user interfaces.
-
-Well, I have
-added the proposal to Git's Summer of Code idea page on the Git Wiki; We will
-see what comes out of it.
--
2.11.4.GIT