From eb2be0f09ac92c0b91475cf489dfc2965108f81b Mon Sep 17 00:00:00 2001
From: Johannes Schindelin
+I recently got into the bad habit of spending a large amount of my waking
+hours working on msysGit, more than is really healthy for me.
+
+For example, I spent the whole morning -- when I should have worked on a
+very important day-job project -- on trying to fix issue 258, where
+git web--browse does not work as expected because of quoting issues
+with cmd.exe.
+
+This is reducing my Git time budget to negative numbers, so much so that I
+cannot even work on Git projects that I actually like, such as jgit diff
+or git rebase -i -p, or at least projects I felt obliged to continue
+to work on, such as git notes.
+
+Now, some people who tried to teach me some time management strongly
+criticized me for ignoring their lessons, and unfortunately, I have to agree.
+
+The problem is that I would hate to see msysGit fall to the same state it
+was after I stopped working on it last year. I started it, and I would like
+it to grow, but too few people took care of the issue tracker, too few tried
+to debug their problems themselves, too few submitted fixes.
+
+I note, though, that there is a positive trend. But being the impatient person
+I am ("2 seconds is my attention span") I tend to want the trend to be more
+impressive.
+
+Anyway, no work on msysGit for at least 4 days, that's what the doctor (me)
+said...]]>
-Phew. The last few days, I was mainly chasing bugs I introduced due to being -too tired to work on the merge-preserving, interactive rebase. -
-But finally I have something I can start working with. After my failed -experiment to use git-blame to split topic branches, I will sort the commits -in my my-next branch into topic branches manually. -
-Then I will add an option to rebase -i -p to rewrite refs which point to -rewritten commits, so that I can have branches rebase-i-p, add-e, etc -and all of them are automatically updated when I rebase -i -p the my-next -branch. -
-In the process, not only have I learnt the value of the bookmark command, -but made quite a few-much needed cleanups (which make -git-rebase--interactive.sh longer, but much more understandable). -
-Hopefully Stephan will pick the changes in the "rebase protocol" up, and then -we can have a sequencer with which I can start to make a graphical interactive -rebase using git-gui. Or gitk. -
-Maybe.]]> - diff --git a/source-1234140696.txt b/source-1234140696.txt deleted file mode 100644 index 87ec3110b7..0000000000 --- a/source-1234140696.txt +++ /dev/null @@ -1,23 +0,0 @@ -''rebase'' updates - -Phew. The last few days, I was mainly chasing bugs I introduced due to being -too tired to work on the merge-preserving, interactive ''rebase''. - -But finally I have something I can start working with. After my failed -experiment to use git-blame to split topic branches, I will sort the commits -in my ''my-next'' branch into topic branches manually. - -Then I will add an option to ''rebase -i -p'' to rewrite refs which point to -rewritten commits, so that I can have branches ''rebase-i-p'', ''add-e'', etc -and all of them are automatically updated when I ''rebase -i -p'' the ''my-next'' -branch. - -In the process, not only have I learnt the value of the ''bookmark'' command, -but made quite a few-much needed cleanups (which make -''git-rebase--interactive.sh'' longer, but much more understandable). - -Hopefully Stephan will pick the changes in the "rebase protocol" up, and then -we can have a sequencer with which I can start to make a graphical interactive -rebase using git-gui. Or gitk. - -Maybe. -- 2.11.4.GIT