From 428650298bec6e76e3c54375050ea0d45b0435b2 Mon Sep 17 00:00:00 2001 From: Johannes Schindelin Date: Mon, 11 May 2009 00:49:20 +0200 Subject: [PATCH] Housekeeping on Monday, 11th of May, Anno Domini MMIX, at the hour of the Rat Signed-off-by: Johannes Schindelin --- blog.rss | 102 +++++++++++++++++++++++++------------------------- source-1234040744.txt | 30 --------------- 2 files changed, 51 insertions(+), 81 deletions(-) delete mode 100644 source-1234040744.txt diff --git a/blog.rss b/blog.rss index 0bed5ac285..b40b07366e 100644 --- a/blog.rss +++ b/blog.rss @@ -5,9 +5,58 @@ http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html A few stories told by Dscho -Fri, 17 Apr 2009 15:39:57 +0200 +Mon, 11 May 2009 00:49:19 +0200 en-us +Working on jgit diff +http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1241995759 +http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1241995759 +Mon, 11 May 2009 00:49:19 +0200 +

+Shawn did so many useful things that I use on a daily basis that I felt really +awful when I realized just how long I had promised to clean up that diff +implementation I wrote for JGit. +

+Alas, it appears that the thing turned out to be almost a complete rewrite, as +the original implementation walked the edit graph in a rather inefficient way. +

+A little background: Myers' algorithm to generate "an edit script" works on +the edit graph: imagine you have all lines of file A as columns and +all lines of file B as rows, then the edit graph is a connection of +the upper left corner to the lower right corner, containing only horizontal, +vertical or diagonal elements, where diagonal elements are only allowed when +the lines of both files agree at that point: +

+

+ H E L L O , W O R L D
+ ----
+L    \
+      ---
+O        \
+          ---
+W            \
+              --------
+
+

+The shortest edit path minimizes the number of non-diagonal elements. +

+Myers' idea is to develop forward and backward paths at the same time +(increasing the number of non-diagonal elements uniformly), storing +only the latest end points. Once the paths meet, divide and conquer. +

+In theory, it would be quicker to store all end points and then just +reconstruct the shortest paths, alas, this takes way too much memory. +

+My first implementation did not remember start or end of the non-diagonal +parts, and had to recurse way more often than really necessary (in the end, +we will order the non-diagonal parts into horizontal and vertical parts +anyway, so start and end are sufficient). +

+The current progress can be seen +here.]]> + + No time for Git http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1239975597 http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1239975597 @@ -208,7 +257,7 @@ 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 +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.]]> @@ -273,54 +322,5 @@ rebase using git-gui. Or gitk.

Maybe.]]> - -The infamous mark command in the rebase command -http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1234040744 -http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1234040744 -Sat, 07 Feb 2009 22:05:44 +0100 -mark command in the rebase command -

-I realized today how easy it is to lose commits with the "merge preserving" -mode of the interactive rebase. In my case, it was when I tried to move a -bunch of commits from the tip of my branch into a topic branch. -

-But after moving the commits, I forgot to update the parent of the merge -commit. Possibly a mark command could have helped. The very same command -I called a nightmare for usability. -

-So I was wrong. Big news. ☺ -

-However, I think that the syntax "mark :1" is something best left for -machine consumption, not for human beings. -

-But I have an idea: we could use some garbled commit subject, or in case of -merge parents, the merge subject as some human readable title of the mark. -

-The rebase script would then look something like this: -

- - - -
-
-
- - -
- 
-pick abcdefg Some ultra cool commit
-bookmark ultra-cool
-goto upstream
-pick hijklmn Some other cool commit
-merge parent ultra-cool Merge 'ultra-cool' into master
-
-
-
-

-The good news is: I added code that refuses to finish a rebase when there -are commits that were rewritten, but not part of the new HEAD's ancestry.]]> - diff --git a/source-1234040744.txt b/source-1234040744.txt deleted file mode 100644 index ad467068e3..0000000000 --- a/source-1234040744.txt +++ /dev/null @@ -1,30 +0,0 @@ -The infamous ''mark'' command in the ''rebase'' command - -I realized today how easy it is to lose commits with the "merge preserving" -mode of the interactive rebase. In my case, it was when I tried to move a -bunch of commits from the tip of my branch into a topic branch. - -But after moving the commits, I forgot to update the parent of the merge -commit. Possibly a mark command could have helped. The very same command -I called a nightmare for usability. - -So I was wrong. Big news. :-) - -However, I think that the syntax "mark :1" is something best left for -machine consumption, not for human beings. - -But I have an idea: we could use some garbled commit subject, or in case of -merge parents, the merge subject as some human readable title of the mark. - -The rebase script would then look something like this: - - -pick abcdefg Some ultra cool commit -bookmark ultra-cool -goto upstream -pick hijklmn Some other cool commit -merge parent ultra-cool Merge 'ultra-cool' into master - - -The good news is: I added code that refuses to finish a rebase when there -are commits that were rewritten, but not part of the new HEAD's ancestry. -- 2.11.4.GIT