Skip to content

Commit 0d52a90

Browse files
chriscoolchriscool
committed
rn-24: improve Summit article
1 parent 052d4bb commit 0d52a90

File tree

1 file changed

+170
-60
lines changed

1 file changed

+170
-60
lines changed

‎rev_news/drafts/edition-24.md‎

Lines changed: 170 additions & 60 deletions
Original file line numberDiff line numberDiff line change
@@ -35,92 +35,173 @@ the [Git Merge 2017](http://git-merge.com/) conference that happenend on Februar
3535
listed in the "Events" section below very nicely express the great
3636
atmosphere at the summit, here are the unconference's agenda items:
3737

38-
* Erik van Zijst presented Atlassian's "clone bundles" approach, which had been added to Mercurial some years ago, was later included in BitBucket.
38+
* Erik van Zijst presented Atlassian's "clone bundles"
39+
approach, which had been added to Mercurial some years ago,
40+
was later included in BitBucket.
3941

40-
* Atlassian would like to add it to Git, but would like to discuss the approach first.
42+
* Atlassian would like to add it to Git, but would
43+
like to discuss the approach first.
4144

42-
* Stefan Saasen had sent [an email about it](http://public-inbox.org/git/CADoxLGPFgF7W4XJzt0X+xFJDoN6RmfFGx_96MO9GPSSOjDK0EQ@mail.gmail.com/) a few days before the Summit.
45+
* Stefan Saasen had sent
46+
[an email about it](http://public-inbox.org/git/CADoxLGPFgF7W4XJzt0X+xFJDoN6RmfFGx_96MO9GPSSOjDK0EQ@mail.gmail.com/)
47+
a few days before the Summit.
4348

44-
* The main motivation for this feature are CPU and I/O usage on the server side.
49+
* The main motivation for this feature are CPU and I/O
50+
usage on the server side.
4551

46-
* The feature would be good for large collections fo repos, e.g. the set for Android; the Google "repo" tool would be an alternative.
52+
* The feature would be good for large collections fo
53+
repos, e.g. the set for Android; the Google "repo"
54+
tool would be an alternative.
4755

48-
* One Alternative would be the design of the Git protocol version 2, with capabilities negociation first.
56+
* One Alternative would be the design of the Git
57+
protocol version 2, with capabilities negociation
58+
first.
4959

50-
* Jeff King, alias Peff, suggested to keep the solution as simple as possible (as an example, a sliced history etc. would be nice to have, but things could get quite complicated).
60+
* Jeff King, alias Peff, suggested to keep the
61+
solution as simple as possible (as an example, a
62+
sliced history etc. would be nice to have, but
63+
things could get quite complicated).
5164

52-
* One downside is that it could take twice the disk space, if the bundle is not generated on the fly.
65+
* One downside is that it could take twice the disk
66+
space, if the bundle is not generated on the fly.
5367

54-
* At present, the Atlassian client is a script mimicing `git clone`, while a proper solution would involve the Git client.
68+
* At present, the Atlassian client is a script
69+
mimicing `git clone`, while a proper solution would
70+
involve the Git client.
5571

56-
* Peff expressed his willingness to help Atlassian on this subject.
72+
* Peff expressed his willingness to help Atlassian on
73+
this subject.
5774

58-
* The solution is experienced as more efficient, but no real statistics / conclusions for real world repos are available yet.
75+
* The solution is experienced as more efficient, but
76+
no real statistics / conclusions for real world
77+
repos are available yet.
5978

60-
* Jeff King, alias Peff, presented a "1 minute version" of the current status of the Software Freedom Conservancy; details available [on the mailing list](http://public-inbox.org/git/[email protected]/). (See also the next article in this edition of Git Rev News.)
79+
* Jeff King, alias Peff, presented a "1 minute version" of the
80+
current status of the Software Freedom Conservancy; details
81+
available [on the mailing list](http://public-inbox.org/git/[email protected]/).
82+
(See also the next article in this edition of Git Rev News.)
6183

6284
* The SFC acquired git-scm.com, maintained by Peff.
6385

6486
* Most effort is spent on trademark/policy work.
6587

6688
* Christian Couder and Ævar Bjarmason presented "Big repos".
6789

68-
* The topic is very related to the „references database“ item below, and deals with improved rebase / staging (split index).
90+
* The topic is very related to the „references database“
91+
item below, and deals with improved rebase / staging
92+
(split index).
6993

70-
* The main idea is to make the git client faster for some index related operations (that is, `git status`).
94+
* The main idea is to make the git client faster for
95+
some index related operations (that is, `git status`).
7196

72-
* Some work on a daemon for file system notifications in the background (inotify) has been done by Duy Nguyen and David Turner, and was planned to rework, but the present contributor is at present busy with other things.
97+
* Some work on a daemon for file system notifications
98+
in the background (inotify) has been done by Duy
99+
Nguyen and David Turner, and was planned to rework,
100+
but the present contributor is at present busy with
101+
other things.
73102

74-
* On Windows, there is no inotify feature available (also applies to some Unix flavours).
103+
* On Windows, there is no inotify feature available
104+
(also applies to some Unix flavours).
75105

76-
* Some discussion arose whether the Windows journal feature or [Watchman](https://facebook.github.io/watchman/) was the appropriate road to follow.
106+
* Some discussion arose whether the Windows journal
107+
feature or
108+
[Watchman](https://facebook.github.io/watchman/) was
109+
the appropriate road to follow.
77110

78-
The participants with really large repos shared their experience.
111+
The participants with really large repos shared their
112+
experience.
79113

80114
* Stefan Beller presented the `git submodule` state.
81115

82-
* Instead of `git submodules`, Android with its 1000 Git repos uses the `repo` tool; the Android repositories are somewhat unrelated, and most contributors just work in 1 or 2 repos.
116+
* Instead of `git submodules`, Android with its 1000
117+
Git repos uses the `repo` tool; the Android
118+
repositories are somewhat unrelated, and most
119+
contributors just work in 1 or 2 repos.
83120

84-
* Regarding submodules, actually the fetch is parallelized, checkout is being worked on, next are worktree and submodules.
121+
* Regarding submodules, actually the fetch is
122+
parallelized, checkout is being worked on, next are
123+
worktree and submodules.
85124

86-
* Inside Git, there is no real module awareness for submodules yet, so each and every Git module needs to be made „submodule ready“.
125+
* Inside Git, there is no real module awareness for
126+
submodules yet, so each and every Git module needs
127+
to be made „submodule ready“.
87128

88-
* At present, one Git process is spawned for each repo, which is quite slow on Windows.
129+
* At present, one Git process is spawned for each
130+
repo, which is quite slow on Windows.
89131

90-
* The submodules design is considered not to be optimal yet; as an example, subsets are not possible.
132+
* The submodules design is considered not to be
133+
optimal yet; as an example, subsets are not
134+
possible.
91135

92-
* Within Gerrit, project changes lead to superproject changes, which might collide, and end up in superproject merge conflict mess.
136+
* Within Gerrit, project changes lead to superproject
137+
changes, which might collide, and end up in
138+
superproject merge conflict mess.
93139

94-
* David Turner considered merge conflict helpers for submodules.
140+
* David Turner considered merge conflict helpers for
141+
submodules.
95142

96-
* Johannes Schindelin remarked that offloading such issues to tools like Gerrit looks suboptimal.
143+
* Johannes Schindelin remarked that offloading such
144+
issues to tools like Gerrit looks suboptimal.
97145

98-
* The topic was concluded with a short disucssion on git bisect with submodules.
146+
* The topic was concluded with a short disucssion on
147+
git bisect with submodules.
99148

100-
* Jacob Vosmaer presented the Gitlab solution for Gitaly, aka „Git RPC“.
149+
* Jacob Vosmaer presented the Gitlab solution for Gitaly, aka
150+
„Git RPC“.
101151

102-
* Gitlab tries to get away from NFS, and would like to see a LRU disk cache, as the NFS cache not good enough for heavy use.
152+
* Gitlab tries to get away from NFS, and would like to
153+
see a LRU disk cache, as the NFS cache not good
154+
enough for heavy use.
103155

104-
* The question is how far only Gitlab is affected (vs. the general community).
156+
* The question is how far only Gitlab is affected
157+
(vs. the general community).
105158

106159
* Use case example are bad refs and storing diffs.
107160

108-
* The work on the Git cache started, but is stalled at present; it will be MIT licensed (uses both Git and Mercurial code).
109-
110-
* Johannes Schindelin presented "Better tools for reviews and contributions".
111-
112-
* The mailing list currently drops contributions via mailers which produce HTML or mixed code. It is too difficult for people to supply patches by mail; the “once tested and then should work" approach (“and then everybody failing is stupid”) is considered simply wrong. One of the rejected clients is Microsoft Outlook, the other is gmail, the main problem being the handling of white space. Perhaps some tool might help with transmitting code corrections with white space. In general, patches would be better attached to mails than just placed inline.
113-
114-
* It is problematic to follow long threads (e.g. one thread stalling for 8 months), while the state of patches discussed is
115-
sometimes unclear.
116-
117-
* The “what’s cooking” emails are just sent to the mailing list, but not to the people being mentioned in the email. At present, the “what’s cooking” email is mostly generated in an automated way from the ToDo branch using a very specialized Scala (?) framework.
118-
119-
* Is there a way to get from the mail client directly into the mentioned source code?
120-
121-
* The Git terminology is sometimes strange, the Git glossary is hard to find, and can be improved; using terms only the email community uses does not improve readability for others outside the list “inhabitants”.
122-
123-
* Johannes regularly submits other peoples’ patches, and would like to see better tool support for this use case. Peff asked whether we need different terms, or better concepts?
161+
* The work on the Git cache started, but is stalled at
162+
present; it will be MIT licensed (uses both Git and
163+
Mercurial code).
164+
165+
* Johannes Schindelin presented "Better tools for reviews and
166+
contributions".
167+
168+
* The mailing list currently drops contributions via
169+
mailers which produce HTML or mixed code. It is too
170+
difficult for people to supply patches by mail; the
171+
“once tested and then should work" approach (“and
172+
then everybody failing is stupid”) is considered
173+
simply wrong. One of the rejected clients is
174+
Microsoft Outlook, the other is gmail, the main
175+
problem being the handling of white space. Perhaps
176+
some tool might help with transmitting code
177+
corrections with white space. In general, patches
178+
would be better attached to mails than just placed
179+
inline.
180+
181+
* It is problematic to follow long threads (e.g. one
182+
thread stalling for 8 months), while the state of
183+
patches discussed is sometimes unclear.
184+
185+
* The “what’s cooking” emails are just sent to the
186+
mailing list, but not to the people being mentioned
187+
in the email. At present, the “what’s cooking” email
188+
is mostly generated in an automated way from the
189+
ToDo branch using a very specialized Scala (?)
190+
framework.
191+
192+
* Is there a way to get from the mail client directly
193+
into the mentioned source code?
194+
195+
* The Git terminology is sometimes strange, the Git
196+
glossary is hard to find, and can be improved; using
197+
terms only the email community uses does not improve
198+
readability for others outside the list
199+
“inhabitants”.
200+
201+
* Johannes regularly submits other peoples’ patches,
202+
and would like to see better tool support for this
203+
use case. Peff asked whether we need different
204+
terms, or better concepts?
124205

125206
Regarding patches, the maintainer decides when an where they are merged / implemented.
126207
The maintainer workflow may prevent us from just using Github PRs.
@@ -131,43 +212,72 @@ the [Git Merge 2017](http://git-merge.com/) conference that happenend on Februar
131212
Johannes emphazied his willingness to establish tools which help to improve the situation.
132213
It was mentioned that code/commit notes should point to mailing list where appropriate.
133214

134-
* Carlos Martín Nieto presented the state of the references database, to get them away from the file system.
215+
* Carlos Martín Nieto presented the state of the references
216+
database, to get them away from the file system.
135217

136-
* A recurring problem seems to be that usable databases do not have a Java implementation (e.g. lmdb last tried); this would help GitHub but still have the potential to split the Git coummunity.
218+
* A recurring problem seems to be that usable
219+
databases do not have a Java implementation
220+
(e.g. lmdb last tried); this would help GitHub but
221+
still have the potential to split the Git
222+
coummunity.
137223

138-
* According to Peff, Git currently reads the whole packref file into memory – mmap could help but would need a lot of refactoring.
224+
* According to Peff, Git currently reads the whole
225+
packref file into memory – mmap could help but would
226+
need a lot of refactoring.
139227

140-
* An important question is whether it is a client or a Github hosting problem; some workflows could cause unhealthy numbers of refs on a client, too.
228+
* An important question is whether it is a client or a
229+
Github hosting problem; some workflows could cause
230+
unhealthy numbers of refs on a client, too.
141231

142-
* At present, not all race conditions fixed yet. The final solution should be portable to jgit / libgit2.
232+
* At present, not all race conditions fixed yet. The
233+
final solution should be portable to jgit / libgit2.
143234

144-
* After the efforts of David Turner, there is now an appropriate ref API within Git.
235+
* After the efforts of David Turner, there is now an
236+
appropriate ref API within Git.
145237

146238
* Brendan Forster presented the gitignore „spec“.
147239

148-
* The goal is to be more standardized and robust (that is, understandable).
240+
* The goal is to be more standardized and robust (that
241+
is, understandable).
149242

150243
* Docs should be more structured.
151244

152-
* One problem is that different implementations of Git, and other tools use gitignore, but implement the stuff differently.
245+
* One problem is that different implementations of
246+
Git, and other tools use gitignore, but implement
247+
the stuff differently.
153248

154-
* An interesting question would be if we could have a common minimal implementation of gitignore in a generally reusable library.
249+
* An interesting question would be if we could have a
250+
common minimal implementation of gitignore in a
251+
generally reusable library.
155252

156-
* Git attributes has similar problems (reading attributes from files in the Index is a nightmare, in some case with read / change / read / change / read sequences (or the like) involved).
253+
* Git attributes has similar problems (reading
254+
attributes from files in the Index is a nightmare,
255+
in some case with read / change / read / change /
256+
read sequences (or the like) involved).
157257

158-
* Josh Triplett presented "Git commit refs, tag refs, and compatibility (future of git-series)".
258+
* Josh Triplett presented "Git commit refs, tag refs, and
259+
compatibility (future of git-series)".
159260

160-
* Junio has suggested a different type of Git refs (in-tree, like hardlinks).
261+
* Junio has suggested a different type of Git refs
262+
(in-tree, like hardlinks).
161263

162-
* Compatibility: support old clients / libgit either on repo level, or unless an operation hits an object type unknown for the old version (the latter being more complicated).
264+
* Compatibility: support old clients / libgit either
265+
on repo level, or unless an operation hits an object
266+
type unknown for the old version (the latter being
267+
more complicated).
163268

164269
* Use cases should be implemented as easy as possible.
165270

166271
* Would be great to disallow the capability per repo.
167272

168273
* Other topics:
169274

170-
* Planned Open Source Hackathons in London and New York in April/May. The intent is to get some stuff in on that day, also recruitment of future contributors. Libgit2 should perhaps be included there. Appropriate contributors should be on board guiding the process.
275+
* Planned Open Source Hackathons in London and New
276+
York in April/May. The intent is to get some stuff
277+
in on that day, also recruitment of future
278+
contributors. Libgit2 should perhaps be included
279+
there. Appropriate contributors should be on board
280+
guiding the process.
171281

172282

173283
*[Git / Software Freedom Conservancy status report](http://public-inbox.org/git/[email protected]/)

0 commit comments

Comments
(0)