Skip to content

Commit 31c1a03

Browse files
tfnicotfnico
committed
rev_news: remove legacy url redirect
Remove the redirect-from as it is a bit of an ugly pattern that generates empty bullet points in the navmenu as it is now. Instead of redirecting the old url /rev_news/edition-1.html to go to the first post on /rev_news/2015/03/25/edition-1/ - simply recreate the edition-1.html page as a copy of the first post. Ugly duplication, but it's the simplest solution without having webserver-level rewrite capability. Ref discussion in #30.
1 parent cc573aa commit 31c1a03

File tree

3 files changed

+337
-4
lines changed

3 files changed

+337
-4
lines changed

‎_config.yml

Lines changed: 0 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,3 @@
11
name: Git Developer Pages
22
markdown: redcarpet
3-
gems:
4-
- jekyll-redirect-from
53
permalink: /rev_news/:year/:month/:day/:title/

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

Lines changed: 1 addition & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,9 +1,8 @@
11
---
22
title: Git Rev News Edition 1 (March 25th, 2015)
33
layout: default
4-
date: 2015-03-25 21:06:51 -0800
4+
date: 2015-03-25 21:06:51 +0100
55
author: chriscool
6-
redirect_from: "/rev_news/edition-1.html"
76
categories: [news]
87
---
98

‎rev_news/edition-1.md

Lines changed: 336 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,336 @@
1+
---
2+
layout: default
3+
title: Git Rev News Edition 1 (March 25th, 2015)
4+
navbar: false
5+
---
6+
7+
## Git Rev News: Edition 1 (March 25th, 2015)
8+
9+
10+
Welcome to the first edition of [Git Rev News](http://git.github.io/rev_news/rev_news.html),
11+
a digest of all things Git, written collaboratively
12+
on [GitHub](https://github.com/git/git.github.io) by volunteers.
13+
14+
Our goal is to aggregate and communicate
15+
some of the activities on the [Git mailing list](mailto:[email protected])
16+
in a format that the wider tech community can follow
17+
and understand. In addition, we'll link to some of the interesting Git-related
18+
articles, tools and projects we come across.
19+
20+
This edition covers what happened during the month of March 2015.
21+
22+
You can contribute to the upcoming edition by sending [pull
23+
requests](https://github.com/git/git.github.io/pulls) or opening
24+
[issues](https://github.com/git/git.github.io/issues).
25+
26+
## Discussions
27+
28+
### General
29+
30+
* [Promoting Git developers](http://thread.gmane.org/gmane.comp.version-control.git/265165) (*written by Junio C Hamano*)
31+
32+
Following up to a message from David Kastrup, a discussion was initiated
33+
by Christian Couder where Michael J Gruber noted
34+
that there are three classes of Git developers, and it is hard for
35+
people who are not already sponsored by corporations to work on Git
36+
not as a hobbyist, but as a means to gain either monetarily or build
37+
reputation.
38+
39+
Later in the thread, Christian volunteered to start a newsletter (this
40+
newsletter!) to summarize and publicise works by participants and
41+
Thomas Ferris Nicolaisen, who runs a popular podcast GitMinutes,
42+
offered to help.
43+
44+
Also, it was decided that release notes will list new and returning
45+
contributors and thank for their help for each release.
46+
47+
### Reviews
48+
49+
* [make git-pull a builtin](http://thread.gmane.org/gmane.comp.version-control.git/265628/)
50+
51+
Paul Tan, who will probably apply to be a [Google Summer of Code
52+
(GSoC)](https://developers.google.com/open-source/soc/) student for
53+
Git this year, anticipated the start of the GSoC and sent a patch to
54+
rewrite git-pull.sh as a built-in.
55+
56+
Indeed as stated in [the GSoC idea
57+
page](http://git.github.io/SoC-2015-Ideas.html):
58+
59+
```
60+
Many components of Git are still in the form of shell and Perl
61+
scripts. While this is an excellent choice as long as the
62+
functionality is improved, it causes problems in production code – in
63+
particular on multiple platforms, e.g. Windows (think:
64+
POSIX-to-Windows path conversion issues).
65+
```
66+
67+
This is why the "Convert scripts to builtins" GSoC project idea is to:
68+
69+
```
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".
73+
```
74+
75+
It appeared that two developers, Duy Nguyen and Stephen Robin, had
76+
already worked on converting git-pull.sh into a built-in in the
77+
past. This happens quite often, so it is a good idea before starting
78+
to develop something in Git, to search and ask around.
79+
80+
Johannes "Dscho" Schindelin, one of the Git for Windows developers,
81+
thanked Paul for the very detailed and well researched comments in
82+
his patch and commented a bit on the benefits of this kind of work:
83+
84+
```
85+
> on Windows the runtime fell from 8m 25s to 1m 3s.
86+
87+
This is *exactly* the type of benefit that makes this project so important! Nice one.
88+
89+
> A simpler, but less perfect strategy might be to just convert the shell
90+
> scripts directly statement by statement to C, using the run_command*()
91+
> functions as Duy Nguyen[2] suggested, before changing the code to use
92+
> the internal API.
93+
94+
Yeah, the idea is to have a straight-forward strategy to convert the scripts in as efficient manner as
95+
possible. It also makes reviewing easier if the first step is an almost one-to-one translation to
96+
`run_command*()`-based builtins.
97+
98+
Plus, it is rewarding to have concise steps that can be completed in a timely manner.
99+
```
100+
101+
Regarding the test suite, Matthieu Moy suggested:
102+
103+
```
104+
> Ideally, I think the solution is to
105+
> improve the test suite and make it as comprehensive as possible, but
106+
> writing a comprehensive test suite may be too time consuming.
107+
108+
time-consuming, but also very beneficial since the code would end up
109+
being better tested. For sure, a rewrite is a good way to break stuff,
110+
but anything untested can also be broken by mistake rather easily at any
111+
time.
112+
113+
I'd suggest doing a bit of manual mutation testing: take your C code,
114+
comment-out a few lines of code, see if the tests still pass, and if
115+
they do, add a failing test that passes again once you uncomment the
116+
code.
117+
```
118+
119+
* [Forbid "log --graph --no-walk"](http://thread.gmane.org/gmane.comp.version-control.git/264899/)
120+
121+
Dongcan Jiang, who will also probably apply to be a GSoC student for
122+
Git this year, sent a patch to prevent `git log` from being used with both
123+
the `--graph` and the `--no-walk` option. He sent this patch because
124+
the Git community asks potential students to work on a
125+
[microproject](http://git.github.io/SoC-2015-Microprojects.html) to
126+
make sure that they can work properly with the community.
127+
128+
Eric Sunshine made some good general suggestions that are often made
129+
on incoming patches:
130+
131+
```
132+
> Forbid "log --graph --no-walk
133+
134+
Style: drop capitalization in the Subject: line. Also prefix with the
135+
command or module being modified, followed by a colon. So:
136+
137+
log: forbid combining --graph and --no-walk
138+
139+
or:
140+
141+
revision: forbid combining --graph and --no-walk
142+
143+
> Because --graph is about connected history while --no-walk is about discrete points.
144+
145+
Okay. You might also want to cite the wider discussion[1].
146+
147+
[1]: http://article.gmane.org/gmane.comp.version-control.git/216083
148+
149+
> revision.c: Judge whether --graph and --no-walk come together when running git-log.
150+
> buildin/log.c: Set git-log cmd flag.
151+
> Documentation/rev-list-options.txt: Add specification on the forbidden usage.
152+
153+
No need to repeat in prose what the patch itself states more clearly
154+
and concisely.
155+
156+
Also, such a change should be accompanied by new test(s).
157+
```
158+
159+
René Scharfe and Junio also suggested some improvements especially in the code.
160+
161+
Junio also explained the interesting behavior of `git show` depending
162+
on the arguments it is given:
163+
164+
```
165+
When "git show" is given a range, it turns no-walk off and becomes a
166+
command about a connected history. Otherwise, it is a command about
167+
discrete point(s).
168+
```
169+
170+
* [War on broken &&-chain](http://thread.gmane.org/gmane.comp.version-control.git/265874) (*written by Junio C Hamano*)
171+
172+
We often see review comments on test scripts that points out a
173+
breakage in the &&-chain, but what does that mean?
174+
175+
When you have a test that looks like this:
176+
177+
```
178+
test_expect_success 'frotz and nitfol work' '
179+
git frotz
180+
git nitfol
181+
'
182+
```
183+
184+
the test framework will not detect even if the `frotz` command
185+
exits with a non-zero error status. A test must be written like
186+
this instead:
187+
188+
```
189+
test_expect_success 'frotz and nitfol work' '
190+
git frotz &&
191+
git nitfol
192+
'
193+
```
194+
195+
Jeff resurrected a clever idea, which was first floated by Jonathan
196+
Nieder in October 2013, to automate detection of such an issue. The
197+
idea is to try running the test body with this magic string prefixed:
198+
`(exit 117) &&`. If everything is properly chained together with `&&`
199+
in the test, running such a test will exit with error code 117 (and
200+
the important assumption is that error code is unused elsewhere). If
201+
on the other hand, if there is an breakage, the test prefixed with the
202+
magic string would either succeed or fail with a code different from
203+
117. His work caught many real test breakages but fortunately it was
204+
found that no command being tested was failing ;-)
205+
206+
As the variety of platforms each developer has access to and the time
207+
each developer has to test Git on them is inevitably limited, broken
208+
&&-chains in some tests that Jeff didn't run were expected to be
209+
caught by others. Torsten Bögershausen did find one in a test that
210+
runs only on a case insensitive filesystem a few days later.
211+
212+
213+
### Support
214+
215+
* [Git with Lader logic](http://thread.gmane.org/gmane.comp.version-control.git/265679/)
216+
217+
People often ask the Git mailing list whether they can use Git to manage
218+
special content. Fortunately, the list is monitored by many experts in different
219+
domains who can often provide specific answers.
220+
221+
This time Bharat Suvarna asked about [PLC
222+
programs](http://en.wikipedia.org/wiki/Programmable_logic_controller)
223+
224+
Kevin D gave the usual non-specific answer:
225+
226+
```
227+
Although git is not very picky about the contents, it is optimized to
228+
track text files. Things like showing diffs and merging files only works
229+
on text files.
230+
231+
Git can track binary files, but there are some disadvantages:
232+
233+
- Diff / merge doesn't work well
234+
- Compression is often difficult, so the repository size may grow
235+
depending on the size of the things stored
236+
```
237+
238+
Then Randall S. Becker gave a more specific answer:
239+
240+
```
241+
Many PLC programs either store their project code in XML, L5K or L5X (for
242+
example), TXT, CSV, or some other text format or can import and export to
243+
text forms. If you have a directory structure that represents your project,
244+
and the file formats have reasonable line separators so that diffs can be
245+
done easily, git very likely would work out for you. You do not have to have
246+
the local .git repository in the same directory as your working area if your
247+
tool has issues with that or .gitignore. You may want to use a GUI client to
248+
manage your local repository and handle the commit/push/pull/merge/rebase
249+
functions as I expect whatever PLC system you are using does not have git
250+
built-in.
251+
```
252+
253+
Doug Kelly also gave some interesting specific information and pointed to a
254+
web site more information.
255+
256+
Thank you all for these helpful answers!
257+
258+
## Misc Git News
259+
260+
### Developers
261+
262+
* David Kastrup (dak at gnu.org) as of version 2.1.0 reimplemented significant
263+
parts of "git blame" for a vast gain in performance with complex
264+
histories and large files. As working on free software is his sole
265+
source of income, please consider contributing to his remuneration if
266+
you find this kind of improvements useful.
267+
268+
### Events
269+
270+
* [Git Merge 2015](http://git-merge.com/), The Conference for the Git
271+
Community, will take place on April 8th & 9th in Paris, France, thanks
272+
to GitHub and the sponsors. If you are a Git developer and need travel
273+
or other assistance to go there, please contact Peff, aka
274+
Jeff King &lt;<[email protected]>&gt;.
275+
276+
### Releases
277+
278+
* [Git v.2.3.2](http://permalink.gmane.org/gmane.linux.kernel/1902789), March 6th.
279+
280+
```
281+
The latest maintenance release Git v2.3.2 is now available at
282+
the usual places.
283+
```
284+
285+
* [Commandline GUI-tool *tig* version 2.1](http://article.gmane.org/gmane.comp.version-control.git/265298), March 11th:
286+
287+
```
288+
I just released version 2.1 of Tig which brings a lot of improvements to speed
289+
up usage in large repositories such as the Linux kernel repo (see improvements
290+
related to #310, #324, #350, and #368). Else this release brings minor
291+
improvements across the board plus a fair amount of bug fixes.
292+
```
293+
294+
* [NodeGit 0.3.0](https://github.com/nodegit/nodegit/releases/tag/v0.3.0), March 13th:
295+
296+
```
297+
Updated to libgit2 v0.22.1. This release contains breaking API changes. Most
298+
noteworthy is the change to how certificate errors are handled during authentication.
299+
300+
For more details check out the change log: http://www.nodegit.org/changelog/#v0-3-0
301+
```
302+
303+
* [Git v.2.3.3](http://permalink.gmane.org/gmane.linux.kernel/1908634), March 14th:
304+
305+
```
306+
The latest maintenance release Git v2.3.3 is now available at
307+
the usual places. It is comprised of 26 non-merge commits since
308+
v2.3.2, contributed by 11 people, 1 of which is a new contributor.
309+
```
310+
311+
* [Git v2.3.4](http://permalink.gmane.org/gmane.linux.kernel/1915412), March 23rd:
312+
313+
```
314+
The latest maintenance release Git v2.3.4 is now available at the
315+
usual places. It is comprised of 22 non-merge commits since v2.3.3,
316+
contributed by 9 people, 1 of which is a new face. All these fixes
317+
have already been in the 'master' branch for some time.
318+
```
319+
320+
### From outside the list
321+
322+
* Google Code [announced their shutdown](http://google-opensource.blogspot.de/2015/03/farewell-to-google-code.html), offering all remaining projects easy migration to Git/GitHub.
323+
* Nava Whiteford wrote a popular article on the [most common Git screwups/questions and solutions](http://41j.com/blog/2015/02/common-git-screwupsquestions-solutions/).
324+
* An older but related resource: [Flight rules for Git](https://github.com/k88hudson/git-flight-rules).
325+
* An [interview with Git book "Git in Practice" author, Mike McQuaid](http://www.infoq.com/articles/interview-Mike-McQuaid-git-practice).
326+
* Speaking of Git books, there's a new one on the way: [Git Essentials](https://www.packtpub.com/application-development/git-essentials).
327+
* And there's [a new video course out on mastering Git](https://www.packtpub.com/application-development/mastering-git-video). The author was just interviewed on....
328+
* The [latest episode of the podcast GitMinutes](http://episodes.gitminutes.com/2015/03/gitminutes-33-thom-parkin-on-mastering.html), about mastering Git.
329+
* Here's a [Git hook](https://github.com/naholyr/github-todos/wiki/Full-presentation) which will automatically turn new TODOs into tasks in your issue tracker (if you use GitHub issues).
330+
* Both [GitLab](https://about.gitlab.com/2015/03/19/omnibus-gitlab-openssl-security-release/) and [BitBucket](https://blog.bitbucket.org/2015/03/19/openssl-security-advisory/) recently posted advisories on recent OpenSSL vulnerabilities.
331+
Make sure that your Git or otherwise OpenSSL-based services are not affected!
332+
333+
## Credits
334+
335+
This edition of Git Rev News was curated by Christian Couder &lt;<[email protected]>&gt; and Thomas Ferris Nicolaisen &lt;<[email protected]>&gt; with help from Junio Hamano, Matthieu Moy, Jeff King, David Kastrup, Stefan Beller and Alex Vandiver.
336+

0 commit comments

Comments
 (0)