| blob | 7a1b366afc67769387e0e8c288b77e3fef87128b |
3 <channel>
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"/>
10 <item>
16 </p><p>
19 </p><p>
20 There are a few things missing before I can start assembling a patch
21 series for submission:
22 </p><p>
23 <ul>
24 <li>I need to handle the commit parents which are outside of the rebased
25 ones properly. In other words, when a commit is picked whose parent is
26 not rebased, it needs to be rebased onto $ONTO.
27 <li>The patch which uses patch-id to generate DROPPED directly also tries to
28 consolidate the handling of DROPPED commits by putting them into REWRITTEN
29 instead of DROPPED, but that breaks the tests. So, this patch needs to be
30 split.
34 for those commands, and this will be an early patch series.
35 <li>Time. I need time, desperately. If my day job was not as exciting as it
36 is, I would have more time for Git. As it is, I have to budget my time so
37 that I get anything done at all.
38 </ul>
39 </p><p>
40 These issues have been postponed due to Steffen taking a well-deserved
41 vacation, which means that I have to act as msysGit maintainer again.
42 </p><p>
43 And this coming week, I will have other things to do in all likeliness, so
45 week. If not then, due to a heavy workload, it will be postponed to early
46 April.
47 </p><p>
49 </item>
50 <item>
55 <description><![CDATA[New Git for Windows version
56 </p><p>
57 Phew. That was quite a day, almost exclusively spent on finishing that
58 installer. The worst part: updating GCC seemed not to be such a good idea
59 after all...
60 </p><p>
62 non-standard, in the common way of Microsoft) if you want to print 64-bit
64 </p><p>
65 After upgrading to the new GCC, a lot of warnings appeared, complaining
68 </p><p>
69 Being the naive I am, I mistook that for a sign that we could finally go
70 more standards-compliant.
71 </p><p>
72 However, it only means that we have to live with the warnings for now, as
73 the C runtime provided on Windows still strongly disagrees with standards
74 (and it has to continue to do so, lest it break existing programs).
75 </p><p>
76 Sigh.
77 </p><p>
78 At least I have the feeling that I caught the most important bugs before
79 releasing.]]></description>
80 </item>
81 <item>
86 <description><![CDATA[Code reviews
87 </p><p>
88 It has been said that reviewing patches is a most thankless job. As I really
89 like the elegance of Git's source code, and care a lot about it, I did not
90 think that it was thankless, just a little bit tedious (especially when the
91 patch authors mistake criticism for personal attacks).
92 </p><p>
93 Usually, I am pretty good at ignoring insults as responses to my comments;
94 after all, I have a lot more enjoyable things to do than to spend time talking
95 to a guy who shows how wise he is when he thinks that I criticize him
97 my knowledge.
98 </p><p>
99 However, in the last days, three people really seemed to want to insult me,
100 to make me go away, to stop the fun I have with Git.
101 </p><p>
102 And they almost succeeded.
103 </p><p>
104 So I guess it is time to reassess my priorities, and maybe stop reviewing
105 Git patches altogether.]]></description>
106 </item>
107 <item>
113 </p><p>
114 Today I am pretty pleased with myself. Two projects at my day job got a real
115 boost, and I implemented a shortcut that avoids the ugly 'bookmark' statement
116 in rebase scripts most of the time.
117 </p><p>
119 something like this:
120 </p><p>
121 <table
124 <pre> </pre>
125 </td></tr>
126 <tr><td>
129 <tr><td>
130 <pre>
131 pick 1234567 My first commit
132 topic begin super-cool-feature
133 pick 2345678 The super cool feature
134 pick 3456789 Documentation for the super cool feature
135 topic end super-cool-feature
136 </pre>
137 </td></tr>
138 </table>
139 </td></tr>
140 </table>
141 </p><p>
142 The result will be a merge commit at the HEAD whose first parent is
145 </p><p>
149 <i>bookmark $NAME; goto merge-parent-of-$NAME; merge parents $NAME [original $MARK Merge branch '$NAME']</i>.
150 </p><p>
151 Of course, being more concise, the 'topic' statement is not only nicer to the
152 eye, but also less error-prone.
153 </p><p>
154 And hopefully many people will agree with me that this rebase script is pretty
155 intuitive.]]></description>
156 </item>
157 <item>
162 <description><![CDATA[Thunderbird, oh Thunderbird, you always make my small brain hurt
163 </p><p>
164 There was a lengthy discussion on the Git mailing list about using Thunderbird,
165 a not quite unpopular mailing program, to send inline patches.
166 </p><p>
167 It is really kind of sad that the Thunderbird developers do not see how
168 stubbornly they offend quite a number of people and scare them away from their
169 program. After all, you should try to be liberal in what you accept and strict
170 in what you emit. No, that does not mean that you should force others to
171 switch their mailers because you strictly adher to your philosophy in what you
172 emit, ignoring the rest of the world.
173 </p><p>
174 In any case, I am not affected (as long as I do not get mails from a poor soul
175 stuck with Thunderbird).
176 </p><p>
177 But I was a bit mean to that Thunderbird guy I dragged into the discussion, and
178 he seems really offended.
179 </p><p>
180 So I thought I'd give him a real reason to feel offended: I'll just do his work:
181 </p><p>
183 </p><p>
184 It took my free time of two days, being not a Thunderbird developer myself.
185 Hopefully it works, and hopefully some people will feel really ashamed now.]]></description>
186 </item>
187 <item>
193 </p><p>
194 I started recently to pipe the output of
197 mailer.
198 </p><p>
199 The idea is to pretend that I continue a postponed mail, but in reality I
201 </p><p>
205 </p><p>
207 the mails, and Alpine generated them, making up new message IDs in the process.
208 </p><p>
212 you could specify arbitrary headers using the command line, you are mistaken:
213 you can do that only by editing the config.
214 </p><p>
216 forgets the <i>--thread</i>. Maybe this week I will find time to address this bug.]]></description>
217 </item>
218 <item>
224 </p><p>
225 Phew. The last few days, I was mainly chasing bugs I introduced due to being
227 </p><p>
228 But finally I have something I can start working with. After my failed
229 experiment to use git-blame to split topic branches, I will sort the commits
231 </p><p>
235 branch.
236 </p><p>
238 but made quite a few-much needed cleanups (which make
240 </p><p>
241 Hopefully Stephan will pick the changes in the "rebase protocol" up, and then
242 we can have a sequencer with which I can start to make a graphical interactive
243 rebase using git-gui. Or gitk.
244 </p><p>
245 Maybe.]]></description>
246 </item>
247 <item>
253 </p><p>
254 I realized today how easy it is to lose commits with the "merge preserving"
255 mode of the interactive rebase. In my case, it was when I tried to move a
256 bunch of commits from the tip of my branch into a topic branch.
257 </p><p>
258 But after moving the commits, I forgot to update the parent of the merge
259 commit. Possibly a mark command could have helped. The very same command
260 I called a nightmare for usability.
261 </p><p>
262 So I was wrong. Big news. ☺
263 </p><p>
264 However, I think that the syntax "mark :1" is something best left for
265 machine consumption, not for human beings.
266 </p><p>
267 But I have an idea: we could use some garbled commit subject, or in case of
268 merge parents, the merge subject as some human readable title of the mark.
269 </p><p>
270 The rebase script would then look something like this:
271 </p><p>
272 <table
275 <pre> </pre>
276 </td></tr>
277 <tr><td>
280 <tr><td>
281 <pre>
282 pick abcdefg Some ultra cool commit
283 bookmark ultra-cool
284 goto upstream
285 pick hijklmn Some other cool commit
286 merge parent ultra-cool Merge 'ultra-cool' into master
287 </pre>
288 </td></tr>
289 </table>
290 </td></tr>
291 </table>
292 </p><p>
293 The good news is: I added code that refuses to finish a rebase when there
294 are commits that were rewritten, but not part of the new HEAD's ancestry.]]></description>
295 </item>
296 <item>
301 <description><![CDATA[New valgrind series
302 </p><p>
303 I spent quite some time cleaning up that patch series, and feel pretty
304 exhausted.
305 </p><p>
309 time to decide upon the order/commit boundaries.
310 </p><p>
311 For example, I could imagine that the patch making the location of the
312 templates independent of the location of the Git binaries should come
314 be squashed into the first valgrind commit.
315 </p><p>
316 Also, it uses two features of valgrind 3.4.0:
317 </p><p>
318 <ul>
321 </ul>
322 </p><p>
323 The latter is actually the reason I am pretty willing to keep the
324 requirement of that valgrind version, as it is really, really useful.
325 </p><p>
326 I guess we will see what happens to it.]]></description>
327 </item>
328 <item>
333 <description><![CDATA[Problems with split-topic-branches.sh
334 </p><p>
335 So my little script that should help me to split my topic branches does
336 not work properly.
337 </p><p>
339 to find overlapping changes, i.e. changes that would conflict when
340 changing the order (or skipping the first change, on which the next builds).
341 </p><p>
344 not find that the first commit is required by the second.
345 </p><p>
346 Therefore I introduced a really slow reverse thing which tries to find
347 those commits whose removals survived until the parent of a particular
348 commit, but not further.
349 </p><p>
350 However, it does not work properly. Basically, only context sizes that
351 span the whole files lead to conflict-free topic branches so far.
352 </p><p>
353 As a consequence, I think I'll add an option --sprout to the revision
354 walker which will fake octopus merges (or a series of two-parent merges)
355 whenever it finds a perl of non-merge commits that are theoretically
356 independent, i.e. whose patches apply cleanly.]]></description>
357 </item>
358 </channel>
359 </rss>