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 +0100 en-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