blog.rss

   1 <?xml version="1.0" encoding="utf-8"?>
   2 <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
   3 <channel>
   4 <title>Dscho's Git log</title>
   5 <link>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html</link>
   6 <atom:link href="http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=blog.rss" rel="self" type="application/rss+xml"/>
   7 <description>A few stories told by Dscho</description>
   8 <lastBuildDate>Fri, 17 Apr 2009 15:39:57 +0200</lastBuildDate>
   9 <language>en-us</language>
  10 <item>
  11 <title>No time for Git</title>
  12 <link>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1239975597</link>
  13 <guid>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1239975597</guid>
  14 <pubDate>Fri, 17 Apr 2009 15:39:57 +0200</pubDate>
  15 <description><![CDATA[No time for Git
  16 </p><p>
  17 It is a shame, but most of my Git time budget is taken by msysGit these
  18 days.
  19 </p><p>
  20 But at least msysGit is moving again; I'll probably write a Herald about
  21 it.]]></description>
  22 </item>
  23 <item>
  24 <title>How to recover from a hackathon</title>
  25 <link>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1238970571</link>
  26 <guid>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1238970571</guid>
  27 <pubDate>Mon, 06 Apr 2009 00:29:31 +0200</pubDate>
  28 <description><![CDATA[How to recover from a hackathon
  29 </p><p>
  30 Phew, 2 crazy and fantastic weeks are behind me.  But it takes its toll:
  31 a weekend I was more offline than online.
  32 </p><p>
  33 Things that are important now: relax. sleep. take a walk. learn to sleep
  34 more than 4 hours a night again. learn to watch a movie without thinking
  35 about code. go for a run.
  36 </p><p>
  37 And after recovering, back to the rebase-i-p branch!]]></description>
  38 </item>
  39 <item>
  40 <title>So, what is missing from my rebase-i-p branch?</title>
  41 <link>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1236554268</link>
  42 <guid>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1236554268</guid>
  43 <pubDate>Mon, 09 Mar 2009 00:17:48 +0100</pubDate>
  44 <description><![CDATA[So, what is missing from my <i>rebase-i-p</i> branch?
  45 </p><p>
  46 I regularly use <i>rebase -i -p</i> these days, to update my personal Git
  47 tree (which used to be <i>my-next</i>).
  48 </p><p>
  49 There are a few things missing before I can start assembling a patch
  50 series for submission:
  51 </p><p>
  52 <ul>
  53 <li>I need to handle the commit parents which are outside of the rebased
  54 ones properly.  In other words, when a commit is picked whose parent is
  55 not rebased, it needs to be rebased onto $ONTO.
  56 <li>The patch which uses patch-id to generate DROPPED directly also tries to
  57 consolidate the handling of DROPPED commits by putting them into REWRITTEN
  58 instead of DROPPED, but that breaks the tests.  So, this patch needs to be
  59 split.
  60 <li>I want to introduce one more command, <i>rephrase</i>, which allows you to
  61 modify the commit message, and nothing more, and <i>halt</i>, which does the
  62 same as <i>edit</i> without <i>pick</i>.  Then there needs to be a new test script
  63 for those commands, and this will be an early patch series.
  64 <li>Time.  I need time, desperately.  If my day job was not as exciting as it
  65 is, I would have more time for Git.  As it is, I have to budget my time so
  66 that I get anything done at all.
  67 </ul>
  68 </p><p>
  69 These issues have been postponed due to Steffen taking a well-deserved
  70 vacation, which means that I have to act as msysGit maintainer again.
  71 </p><p>
  72 And this coming week, I will have other things to do in all likeliness, so
  73 that I expect to be able to submit a <i>rebase -i -p</i> patch series only next
  74 week.  If not then, due to a heavy workload, it will be postponed to early
  75 April.
  76 </p><p>
  77 Oh well, the joys of being excited by several competing projects! &#x263a;]]></description>
  78 </item>
  79 <item>
  80 <title>New Git for Windows version</title>
  81 <link>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1236479389</link>
  82 <guid>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1236479389</guid>
  83 <pubDate>Sun, 08 Mar 2009 03:29:49 +0100</pubDate>
  84 <description><![CDATA[New Git for Windows version
  85 </p><p>
  86 Phew.  That was quite a day, almost exclusively spent on finishing that
  87 installer.  The worst part: updating GCC seemed not to be such a good idea
  88 after all...
  89 </p><p>
  90 For Windows, we need to use the printf format <i>%I64u</i> (which is
  91 non-standard, in the common way of Microsoft) if you want to print 64-bit
  92 wide unsigned numbers.  The rest of the world accepts the standard <i>%llu</i>.
  93 </p><p>
  94 After upgrading to the new GCC, a lot of warnings appeared, complaining
  95 about <i>%I64u</i>.  The warnings went away when I replaced the format with
  96 <i>%llu</i>.
  97 </p><p>
  98 Being the naive I am, I mistook that for a sign that we could finally go
  99 more standards-compliant.
 100 </p><p>
 101 However, it only means that we have to live with the warnings for now, as
 102 the C runtime provided on Windows still strongly disagrees with standards
 103 (and it has to continue to do so, lest it break existing programs).
 104 </p><p>
 105 Sigh.
 106 </p><p>
 107 At least I have the feeling that I caught the most important bugs before
 108 releasing.]]></description>
 109 </item>
 110 <item>
 111 <title>Code reviews</title>
 112 <link>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1235092615</link>
 113 <guid>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1235092615</guid>
 114 <pubDate>Fri, 20 Feb 2009 02:16:55 +0100</pubDate>
 115 <description><![CDATA[Code reviews
 116 </p><p>
 117 It has been said that reviewing patches is a most thankless job.  As I really
 118 like the elegance of Git's source code, and care a lot about it, I did not
 119 think that it was thankless, just a little bit tedious (especially when the
 120 patch authors mistake criticism for personal attacks).
 121 </p><p>
 122 Usually, I am pretty good at ignoring insults as responses to my comments;
 123 after all, I have a lot more enjoyable things to do than to spend time talking
 124 to a guy who shows how wise he is when he thinks that I criticize him
 125 <u>personally</u> when I just try to enhance his work, by offering a little bit of
 126 my knowledge.
 127 </p><p>
 128 However, in the last days, three people really seemed to want to insult me,
 129 to make me go away, to stop the fun I have with Git.
 130 </p><p>
 131 And they almost succeeded.
 132 </p><p>
 133 So I guess it is time to reassess my priorities, and maybe stop reviewing
 134 Git patches altogether.]]></description>
 135 </item>
 136 <item>
 137 <title>Interactive rebase just learnt a new command: topic</title>
 138 <link>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1234409395</link>
 139 <guid>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1234409395</guid>
 140 <pubDate>Thu, 12 Feb 2009 04:29:55 +0100</pubDate>
 141 <description><![CDATA[Interactive <i>rebase</i> just learnt a new command: <i>topic</i>
 142 </p><p>
 143 Today I am pretty pleased with myself.  Two projects at my day job got a real
 144 boost, and I implemented a shortcut that avoids the ugly 'bookmark' statement
 145 in rebase scripts most of the time.
 146 </p><p>
 147 A typical rebase script, generated by <i>git rebase -i -p $COMMIT</i> will look
 148 something like this:
 149 </p><p>
 150 <table
 151                                 border=1 bgcolor=white>
 152                         <tr><td bgcolor=lightblue colspan=3>
 153                                 <pre>                                                                                </pre>
 154                         </td></tr>
 155                         <tr><td>
 156                                 <table cellspacing=5 border=0
 157                                          style="color:black;">
 158                                 <tr><td>
 159                                         <pre>
 160 pick 1234567 My first commit
 161 topic begin super-cool-feature
 162 pick 2345678 The super cool feature
 163 pick 3456789 Documentation for the super cool feature
 164 topic end super-cool-feature
 165 </pre>
 166                                 </td></tr>
 167                                 </table>
 168                         </td></tr>
 169                         </table>
 170 </p><p>
 171 The result will be a merge commit at the HEAD whose first parent is
 172 "My first commit", whose second parent is "Documentation for the super
 173 cool feature" and whose commit message is "Merge branch 'super-cool-feature'".
 174 </p><p>
 175 Side note: internally, <i>topic begin $NAME [at $COMMIT]</i> will be handled as if
 176 you wrote <i>bookmark merge-parent-of-$NAME; goto $COMMIT</i>, and
 177 <i>topic end $NAME [$MESSAGE]</i> will be handled as if you wrote
 178 <i>bookmark $NAME; goto merge-parent-of-$NAME; merge parents $NAME [original $MARK Merge branch '$NAME']</i>.
 179 </p><p>
 180 Of course, being more concise, the 'topic' statement is not only nicer to the
 181 eye, but also less error-prone.
 182 </p><p>
 183 And hopefully many people will agree with me that this rebase script is pretty
 184 intuitive.]]></description>
 185 </item>
 186 <item>
 187 <title>Thunderbird, oh Thunderbird, you always make my small brain hurt</title>
 188 <link>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1234320806</link>
 189 <guid>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1234320806</guid>
 190 <pubDate>Wed, 11 Feb 2009 03:53:26 +0100</pubDate>
 191 <description><![CDATA[Thunderbird, oh Thunderbird, you always make my small brain hurt
 192 </p><p>
 193 There was a lengthy discussion on the Git mailing list about using Thunderbird,
 194 a not quite unpopular mailing program, to send inline patches.
 195 </p><p>
 196 It is really kind of sad that the Thunderbird developers do not see how
 197 stubbornly they offend quite a number of people and scare them away from their
 198 program.  After all, you should try to be liberal in what you accept and strict
 199 in what you emit.  No, that does not mean that you should force others to
 200 switch their mailers because you strictly adher to your philosophy in what you
 201 emit, ignoring the rest of the world.
 202 </p><p>
 203 In any case, I am not affected (as long as I do not get mails from a poor soul
 204 stuck with Thunderbird).
 205 </p><p>
 206 But I was a bit mean to that Thunderbird guy I dragged into the discussion, and
 207 he seems really offended.
 208 </p><p>
 209 So I thought I'd give him a real reason to feel offended: I'll just do his work:
 210 </p><p>
 211 http://<a href=http://repo.or.cz>repo.or.cz</a>/w/UnFlowedThunderbird.git
 212 </p><p>
 213 It took my free time of two days, being not a Thunderbird developer myself.
 214 Hopefully it works, and hopefully some people will feel really ashamed now.]]></description>
 215 </item>
 216 <item>
 217 <title>format-patch --thread and Alpine</title>
 218 <link>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1234141489</link>
 219 <guid>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1234141489</guid>
 220 <pubDate>Mon, 09 Feb 2009 02:04:49 +0100</pubDate>
 221 <description><![CDATA[<i>format-patch --thread</i> and Alpine
 222 </p><p>
 223 I started recently to pipe the output of
 224 <i>git format-patch --cover-letter --stdout ...</i> directly into the
 225 <i>postponed-msgs</i> folder Alpine uses, instead of pasting files into the
 226 mailer.
 227 </p><p>
 228 The idea is to pretend that I continue a postponed mail, but in reality I
 229 never wrote it, <i>format-patch</i> did.
 230 </p><p>
 231 However, I had problems with the <i>--thread</i> option that is implied by
 232 <i>--cover-letter</i>.  Alpine always generated new message IDs without adjusting
 233 the <i>In-reply-to:</i> and <i>References:</i> headers of the other mails.
 234 </p><p>
 235 Now I found out that the reason is that the <i>Fcc:</i> headers were missing in
 236 the mails, and Alpine generated them, making up new message IDs in the process.
 237 </p><p>
 238 Therefore I have an alias now which sets not only the <i>Fcc:</i> header, but also
 239 the <i>To:</i> headers by rewriting the stream using <i>sed</i>.  This is slightly
 240 ugly, but so is the handling of headers in <i>format-patch</i>: if you thought
 241 you could specify arbitrary headers using the command line, you are mistaken:
 242 you can do that only by editing the config.
 243 </p><p>
 244 While at it, I also noticed a bug whereby <i>--thread --in-reply-to=...</i> simply
 245 forgets the <i>--thread</i>.  Maybe this week I will find time to address this bug.]]></description>
 246 </item>
 247 <item>
 248 <title>rebase updates</title>
 249 <link>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1234140696</link>
 250 <guid>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1234140696</guid>
 251 <pubDate>Mon, 09 Feb 2009 01:51:36 +0100</pubDate>
 252 <description><![CDATA[<i>rebase</i> updates
 253 </p><p>
 254 Phew.  The last few days, I was mainly chasing bugs I introduced due to being
 255 too tired to work on the merge-preserving, interactive <i>rebase</i>.
 256 </p><p>
 257 But finally I have something I can start working with.  After my failed
 258 experiment to use git-blame to split topic branches, I will sort the commits
 259 in my <i>my-next</i> branch into topic branches manually.
 260 </p><p>
 261 Then I will add an option to <i>rebase -i -p</i> to rewrite refs which point to
 262 rewritten commits, so that I can have branches <i>rebase-i-p</i>, <i>add-e</i>, etc
 263 and all of them are automatically updated when I <i>rebase -i -p</i> the <i>my-next</i>
 264 branch.
 265 </p><p>
 266 In the process, not only have I learnt the value of the <i>bookmark</i> command,
 267 but made quite a few-much needed cleanups (which make
 268 <i>git-rebase--interactive.sh</i> longer, but much more understandable).
 269 </p><p>
 270 Hopefully Stephan will pick the changes in the "rebase protocol" up, and then
 271 we can have a sequencer with which I can start to make a graphical interactive
 272 rebase using git-gui.  Or gitk.
 273 </p><p>
 274 Maybe.]]></description>
 275 </item>
 276 <item>
 277 <title>The infamous mark command in the rebase command</title>
 278 <link>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1234040744</link>
 279 <guid>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1234040744</guid>
 280 <pubDate>Sat, 07 Feb 2009 22:05:44 +0100</pubDate>
 281 <description><![CDATA[The infamous <i>mark</i> command in the <i>rebase</i> command
 282 </p><p>
 283 I realized today how easy it is to lose commits with the "merge preserving"
 284 mode of the interactive rebase.  In my case, it was when I tried to move a
 285 bunch of commits from the tip of my branch into a topic branch.
 286 </p><p>
 287 But after moving the commits, I forgot to update the parent of the merge
 288 commit.  Possibly a mark command could have helped.  The very same command
 289 I called a nightmare for usability.
 290 </p><p>
 291 So I was wrong.  Big news.  &#x263a;
 292 </p><p>
 293 However, I think that the syntax "mark :1" is something best left for
 294 machine consumption, not for human beings.
 295 </p><p>
 296 But I have an idea: we could use some garbled commit subject, or in case of
 297 merge parents, the merge subject as some human readable title of the mark.
 298 </p><p>
 299 The rebase script would then look something like this:
 300 </p><p>
 301 <table
 302                                 border=1 bgcolor=white>
 303                         <tr><td bgcolor=lightblue colspan=3>
 304                                 <pre>                                                                                </pre>
 305                         </td></tr>
 306                         <tr><td>
 307                                 <table cellspacing=5 border=0
 308                                          style="color:black;">
 309                                 <tr><td>
 310                                         <pre>
 311 pick abcdefg Some ultra cool commit
 312 bookmark ultra-cool
 313 goto upstream
 314 pick hijklmn Some other cool commit
 315 merge parent ultra-cool Merge 'ultra-cool' into master
 316 </pre>
 317                                 </td></tr>
 318                                 </table>
 319                         </td></tr>
 320                         </table>
 321 </p><p>
 322 The good news is: I added code that refuses to finish a rebase when there
 323 are commits that were rewritten, but not part of the new HEAD's ancestry.]]></description>
 324 </item>
 325 </channel>
 326 </rss>