From ac47d2fef5d89116a543bcf62a2ca0e208ca867d Mon Sep 17 00:00:00 2001 From: Johannes Schindelin Date: Fri, 20 Feb 2009 02:16:56 +0100 Subject: [PATCH] Housekeeping on Friday, 20th of February, Anno Domini MMIX, at the hour of the Buffalo Signed-off-by: Johannes Schindelin --- blog.rss | 58 ++++++++++++++++++++++++--------------------------- source-1233154567.txt | 24 --------------------- 2 files changed, 27 insertions(+), 55 deletions(-) delete mode 100644 source-1233154567.txt diff --git a/blog.rss b/blog.rss index 02e94bba19..fafdecde48 100644 --- a/blog.rss +++ b/blog.rss @@ -5,9 +5,35 @@ http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html A few stories told by Dscho -Thu, 12 Feb 2009 04:29:56 +0100 +Fri, 20 Feb 2009 02:16:55 +0100 en-us +Code reviews +http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1235092615 +http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1235092615 +Fri, 20 Feb 2009 02:16:55 +0100 +

+It has been said that reviewing patches is a most thankless job. As I really +like the elegance of Git's source code, and care a lot about it, I did not +think that it was thankless, just a little bit tedious (especially when the +patch authors mistake criticism for personal attacks). +

+Usually, I am pretty good at ignoring insults as responses to my comments; +after all, I have a lot more enjoyable things to do than to spend time talking +to a guy who shows how wise he is when he thinks that I criticize him +personally when I just try to enhance his work, by offering a little bit of +my knowledge. +

+However, in the last days, three people really seemed to want to insult me, +to make me go away, to stop the fun I have with Git. +

+And they almost succeeded. +

+So I guess it is time to reassess my priorities, and maybe stop reviewing +Git patches altogether.]]> + + Interactive rebase just learnt a new command: topic http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1234409395 http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1234409395 @@ -383,35 +409,5 @@ $ rm .git/interactive-stash-1 .git/interactive-stash-2 This should probably go into git-stash.sh, maybe even with a switch to start git-gui to do the interactive adding instead of git-add.]]> - -Splitting topic branches -http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1233154567 -http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1233154567 -Wed, 28 Jan 2009 15:56:07 +0100 -

-One might be put off easily by the overarching use of buzzwords in the -description of how Darcs works. I, for one, do not expect an intelligent -author when I read Theory of patches and based on quantum physics. -

-The true story, however, is much simpler, and is actually not that dumb: -Let's call two commits "conflicting" when they contain at least one -overlapping change. -

-The idea is now: Given a list of commits (not a set, as the order is important), -to sort them into smaller lists such that conflicting commits are in the -sublists ("topic branches") and the sublists are minimal, i.e. no two -non-conflicting commits are in the same sublist. -

-The idea has flaws, of course, as you can have a patch changing the code, -and another changing the documentation, but splitting a list of commits -in that way is a first step to sort out my my-next mess, where I have -a linear perl of not-necessarily-dependent commits. -

-And actually, my whole rebase revamp aimed at the clean-up for my own -my-next branch, so I am currently writing a script that can be used -as a GIT_EDITOR for git-rebase which implements the Darcs algorithm. Kind of: -the result is not implicit, but explicit and can be fixed up later.]]> - diff --git a/source-1233154567.txt b/source-1233154567.txt deleted file mode 100644 index 6d82786ed1..0000000000 --- a/source-1233154567.txt +++ /dev/null @@ -1,24 +0,0 @@ -Splitting topic branches - -One might be put off easily by the overarching use of buzzwords in the -description of how ''Darcs'' works. I, for one, do not expect an intelligent -author when I read ''Theory of patches'' and ''based on quantum physics''. - -The true story, however, is much simpler, and is actually not that dumb: -Let's call two commits "conflicting" when they contain at least one -overlapping change. - -The idea is now: Given a list of commits (not a set, as the order is important), -to sort them into smaller lists such that conflicting commits are in the -sublists ("topic branches") and the sublists are minimal, i.e. no two -non-conflicting commits are in the same sublist. - -The idea has flaws, of course, as you can have a patch changing the code, -and another changing the documentation, but splitting a list of commits -in that way is a first step to sort out my ''my-next'' mess, where I have -a linear perl of not-necessarily-dependent commits. - -And actually, my whole rebase revamp aimed at the clean-up for my own -''my-next'' branch, so I am currently writing a script that can be used -as a GIT_EDITOR for git-rebase which implements the Darcs algorithm. Kind of: -the result is not implicit, but explicit and can be fixed up later. -- 2.11.4.GIT