Skip to content

Commit 382996e

Browse files
tfnicotfnico
committed
rev_news: use blockquotes when quoting
The correct markdown syntax for quoting is like this: > I quoted thee Use this style when quoting words from the mailing list, and other sources..
1 parent 1710f03 commit 382996e

File tree

1 file changed

+103
-127
lines changed

1 file changed

+103
-127
lines changed

‎_posts/2015-03-25-edition-1.markdown

Lines changed: 103 additions & 127 deletions
Original file line numberDiff line numberDiff line change
@@ -57,65 +57,59 @@ rewrite git-pull.sh as a built-in.
5757
Indeed as stated in [the GSoC idea
5858
page](http://git.github.io/SoC-2015-Ideas.html):
5959

60-
```
61-
Many components of Git are still in the form of shell and Perl
62-
scripts. While this is an excellent choice as long as the
63-
functionality is improved, it causes problems in production code – in
64-
particular on multiple platforms, e.g. Windows (think:
65-
POSIX-to-Windows path conversion issues).
66-
```
60+
61+
> Many components of Git are still in the form of shell and Perl
62+
> scripts. While this is an excellent choice as long as the
63+
> functionality is improved, it causes problems in production code – in
64+
> particular on multiple platforms, e.g. Windows (think:
65+
> POSIX-to-Windows path conversion issues).
66+
6767

6868
This is why the "Convert scripts to builtins" GSoC project idea is to:
6969

70-
```
71-
... dive into the Git source code and convert a couple of shell
72-
and/or Perl scripts into portable and performant C code, making it a
73-
so-called "built-in".
74-
```
70+
> ... dive into the Git source code and convert a couple of shell
71+
> and/or Perl scripts into portable and performant C code, making it a
72+
> so-called "built-in".
7573
7674
It appeared that two developers, Duy Nguyen and Stephen Robin, had
7775
already worked on converting git-pull.sh into a built-in in the
7876
past. This happens quite often, so it is a good idea before starting
7977
to develop something in Git, to search and ask around.
8078

81-
Johannes "Dscho" Schindelin, one of the Git for Windows developers,
82-
thanked Paul for the very detailed and well researched comments in
79+
Johannes "Dscho" Schindelin, one of the Git for Windows developers,
80+
thanked Paul for the very detailed and well researched comments in
8381
his patch and commented a bit on the benefits of this kind of work:
8482

85-
```
86-
> on Windows the runtime fell from 8m 25s to 1m 3s.
87-
88-
This is *exactly* the type of benefit that makes this project so important! Nice one.
89-
90-
> A simpler, but less perfect strategy might be to just convert the shell
91-
> scripts directly statement by statement to C, using the run_command*()
92-
> functions as Duy Nguyen[2] suggested, before changing the code to use
93-
> the internal API.
94-
95-
Yeah, the idea is to have a straight-forward strategy to convert the scripts in as efficient manner as
96-
possible. It also makes reviewing easier if the first step is an almost one-to-one translation to
97-
`run_command*()`-based builtins.
98-
99-
Plus, it is rewarding to have concise steps that can be completed in a timely manner.
100-
```
83+
>> on Windows the runtime fell from 8m 25s to 1m 3s.
84+
>
85+
>This is *exactly* the type of benefit that makes this project so important! Nice one.
86+
>
87+
>> A simpler, but less perfect strategy might be to just convert the shell
88+
>> scripts directly statement by statement to C, using the run_command*()
89+
>> functions as Duy Nguyen[2] suggested, before changing the code to use
90+
>> the internal API.
91+
>
92+
>Yeah, the idea is to have a straight-forward strategy to convert the scripts in as efficient manner as
93+
>possible. It also makes reviewing easier if the first step is an almost one-to-one translation to
94+
>`run_command*()`-based builtins.
95+
>
96+
>Plus, it is rewarding to have concise steps that can be completed in a timely manner.
10197
10298
Regarding the test suite, Matthieu Moy suggested:
10399

104-
```
105-
> Ideally, I think the solution is to
106-
> improve the test suite and make it as comprehensive as possible, but
107-
> writing a comprehensive test suite may be too time consuming.
108-
109-
time-consuming, but also very beneficial since the code would end up
110-
being better tested. For sure, a rewrite is a good way to break stuff,
111-
but anything untested can also be broken by mistake rather easily at any
112-
time.
113-
114-
I'd suggest doing a bit of manual mutation testing: take your C code,
115-
comment-out a few lines of code, see if the tests still pass, and if
116-
they do, add a failing test that passes again once you uncomment the
117-
code.
118-
```
100+
>> Ideally, I think the solution is to
101+
>> improve the test suite and make it as comprehensive as possible, but
102+
>> writing a comprehensive test suite may be too time consuming.
103+
>
104+
>time-consuming, but also very beneficial since the code would end up
105+
>being better tested. For sure, a rewrite is a good way to break stuff,
106+
>but anything untested can also be broken by mistake rather easily at any
107+
>time.
108+
>
109+
>I'd suggest doing a bit of manual mutation testing: take your C code,
110+
>comment-out a few lines of code, see if the tests still pass, and if
111+
>they do, add a failing test that passes again once you uncomment the
112+
>code.
119113
120114
* [Forbid "log --graph --no-walk"](http://thread.gmane.org/gmane.comp.version-control.git/264899/)
121115

@@ -129,44 +123,40 @@ make sure that they can work properly with the community.
129123
Eric Sunshine made some good general suggestions that are often made
130124
on incoming patches:
131125

132-
```
133-
> Forbid "log --graph --no-walk
134-
135-
Style: drop capitalization in the Subject: line. Also prefix with the
136-
command or module being modified, followed by a colon. So:
137-
138-
log: forbid combining --graph and --no-walk
139-
140-
or:
141-
142-
revision: forbid combining --graph and --no-walk
143-
144-
> Because --graph is about connected history while --no-walk is about discrete points.
145-
146-
Okay. You might also want to cite the wider discussion[1].
147-
148-
[1]: http://article.gmane.org/gmane.comp.version-control.git/216083
149-
150-
> revision.c: Judge whether --graph and --no-walk come together when running git-log.
151-
> buildin/log.c: Set git-log cmd flag.
152-
> Documentation/rev-list-options.txt: Add specification on the forbidden usage.
153-
154-
No need to repeat in prose what the patch itself states more clearly
155-
and concisely.
156-
157-
Also, such a change should be accompanied by new test(s).
158-
```
126+
>> Forbid "log --graph --no-walk
127+
>
128+
>Style: drop capitalization in the Subject: line. Also prefix with the
129+
>command or module being modified, followed by a colon. So:
130+
>
131+
> log: forbid combining --graph and --no-walk
132+
>
133+
>or:
134+
>
135+
> revision: forbid combining --graph and --no-walk
136+
>
137+
>> Because --graph is about connected history while --no-walk is about discrete points.
138+
>
139+
>Okay. You might also want to cite the wider discussion[1].
140+
>
141+
>[1]: http://article.gmane.org/gmane.comp.version-control.git/216083
142+
>
143+
>> revision.c: Judge whether --graph and --no-walk come together when running git-log.
144+
>> buildin/log.c: Set git-log cmd flag.
145+
>> Documentation/rev-list-options.txt: Add specification on the forbidden usage.
146+
>
147+
>No need to repeat in prose what the patch itself states more clearly
148+
>and concisely.
149+
>
150+
>Also, such a change should be accompanied by new test(s).
159151
160152
René Scharfe and Junio also suggested some improvements especially in the code.
161153

162154
Junio also explained the interesting behavior of `git show` depending
163155
on the arguments it is given:
164156

165-
```
166-
When "git show" is given a range, it turns no-walk off and becomes a
167-
command about a connected history. Otherwise, it is a command about
168-
discrete point(s).
169-
```
157+
> When "git show" is given a range, it turns no-walk off and becomes a
158+
> command about a connected history. Otherwise, it is a command about
159+
> discrete point(s).
170160
171161
* [War on broken &&-chain](http://thread.gmane.org/gmane.comp.version-control.git/265874) (*written by Junio C Hamano*)
172162

@@ -224,32 +214,28 @@ programs](http://en.wikipedia.org/wiki/Programmable_logic_controller)
224214

225215
Kevin D gave the usual non-specific answer:
226216

227-
```
228-
Although git is not very picky about the contents, it is optimized to
229-
track text files. Things like showing diffs and merging files only works
230-
on text files.
231-
232-
Git can track binary files, but there are some disadvantages:
233-
234-
- Diff / merge doesn't work well
235-
- Compression is often difficult, so the repository size may grow
236-
depending on the size of the things stored
237-
```
217+
> Although git is not very picky about the contents, it is optimized to
218+
> track text files. Things like showing diffs and merging files only works
219+
> on text files.
220+
>
221+
> Git can track binary files, but there are some disadvantages:
222+
>
223+
> - Diff / merge doesn't work well
224+
> - Compression is often difficult, so the repository size may grow
225+
> depending on the size of the things stored
238226
239227
Then Randall S. Becker gave a more specific answer:
240228

241-
```
242-
Many PLC programs either store their project code in XML, L5K or L5X (for
243-
example), TXT, CSV, or some other text format or can import and export to
244-
text forms. If you have a directory structure that represents your project,
245-
and the file formats have reasonable line separators so that diffs can be
246-
done easily, git very likely would work out for you. You do not have to have
247-
the local .git repository in the same directory as your working area if your
248-
tool has issues with that or .gitignore. You may want to use a GUI client to
249-
manage your local repository and handle the commit/push/pull/merge/rebase
250-
functions as I expect whatever PLC system you are using does not have git
251-
built-in.
252-
```
229+
> Many PLC programs either store their project code in XML, L5K or L5X (for
230+
> example), TXT, CSV, or some other text format or can import and export to
231+
> text forms. If you have a directory structure that represents your project,
232+
> and the file formats have reasonable line separators so that diffs can be
233+
> done easily, git very likely would work out for you. You do not have to have
234+
> the local .git repository in the same directory as your working area if your
235+
> tool has issues with that or .gitignore. You may want to use a GUI client to
236+
> manage your local repository and handle the commit/push/pull/merge/rebase
237+
> functions as I expect whatever PLC system you are using does not have git
238+
> built-in.
253239
254240
Doug Kelly also gave some interesting specific information and pointed to a
255241
web site more information.
@@ -278,45 +264,35 @@ Jeff King &lt;<[email protected]>&gt;.
278264

279265
* [Git v.2.3.2](http://permalink.gmane.org/gmane.linux.kernel/1902789), March 6th.
280266

281-
```
282-
The latest maintenance release Git v2.3.2 is now available at
283-
the usual places.
284-
```
267+
> The latest maintenance release Git v2.3.2 is now available at
268+
> the usual places.
285269
286270
* [Commandline GUI-tool *tig* version 2.1](http://article.gmane.org/gmane.comp.version-control.git/265298), March 11th:
287271

288-
```
289-
I just released version 2.1 of Tig which brings a lot of improvements to speed
290-
up usage in large repositories such as the Linux kernel repo (see improvements
291-
related to #310, #324, #350, and #368). Else this release brings minor
292-
improvements across the board plus a fair amount of bug fixes.
293-
```
272+
> I just released version 2.1 of Tig which brings a lot of improvements to speed
273+
> up usage in large repositories such as the Linux kernel repo (see improvements
274+
> related to #310, #324, #350, and #368). Else this release brings minor
275+
> improvements across the board plus a fair amount of bug fixes.
294276
295277
* [NodeGit 0.3.0](https://github.com/nodegit/nodegit/releases/tag/v0.3.0), March 13th:
296278

297-
```
298-
Updated to libgit2 v0.22.1. This release contains breaking API changes. Most
299-
noteworthy is the change to how certificate errors are handled during authentication.
300-
301-
For more details check out the change log: http://www.nodegit.org/changelog/#v0-3-0
302-
```
279+
> Updated to libgit2 v0.22.1. This release contains breaking API changes. Most
280+
> noteworthy is the change to how certificate errors are handled during authentication.
281+
>
282+
> For more details check out the change log: http://www.nodegit.org/changelog/#v0-3-0
303283
304284
* [Git v.2.3.3](http://permalink.gmane.org/gmane.linux.kernel/1908634), March 14th:
305285

306-
```
307-
The latest maintenance release Git v2.3.3 is now available at
308-
the usual places. It is comprised of 26 non-merge commits since
309-
v2.3.2, contributed by 11 people, 1 of which is a new contributor.
310-
```
286+
> The latest maintenance release Git v2.3.3 is now available at
287+
> the usual places. It is comprised of 26 non-merge commits since
288+
> v2.3.2, contributed by 11 people, 1 of which is a new contributor.
311289
312290
* [Git v2.3.4](http://permalink.gmane.org/gmane.linux.kernel/1915412), March 23rd:
313291

314-
```
315-
The latest maintenance release Git v2.3.4 is now available at the
316-
usual places. It is comprised of 22 non-merge commits since v2.3.3,
317-
contributed by 9 people, 1 of which is a new face. All these fixes
318-
have already been in the 'master' branch for some time.
319-
```
292+
> The latest maintenance release Git v2.3.4 is now available at the
293+
> usual places. It is comprised of 22 non-merge commits since v2.3.3,
294+
> contributed by 9 people, 1 of which is a new face. All these fixes
295+
> have already been in the 'master' branch for some time.
320296
321297
### From outside the list
322298

0 commit comments

Comments
 (0)