rn-24: reindent Summit article

Author: chriscool

rev_news/drafts/edition-24.md

@@ -35,80 +35,88 @@ had been organized. While both Lars Kruse's and Ed Thomson's blogs
 listed in the "Events" section below very nicely express the great
 atmosphere at the summit, here are the unconference's agenda items:
 
-* Erik van Zijst presented Atlassian's "clone bundles" approach, which had been added to Mercurial some years ago, was later included in BitBucket.
- * Atlassian would like to add it to Git, but would like to discuss the approach first.
- * The main motivation for this feature are CPU and I/O usage on the server side.
- * The feature would be good for large collections fo repos, e.g. the set for Android; the Google "repo" tool would be an alternative.
- * One Alternative would be the design of the Git protocol version 2, with capabilities negociation first.
- * 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).
- * At present, the Atlassian client is a script mimicing `git clone`, while a proper solution would involve the Git client.
- * Peff expressed his willingness to help Atlassian on this subject.
- * The solution is experienced as more efficient, but no real statistics / conclusions for real world repos are available yet.
-
-* Jeff King, alias Peff, presented a "1 minute version" of the current status of the Software Freedom Conservancy; financial details available on the mailing list.
- * The SFC acquired git-scm.com, maintained by Peff.
- * Most effort is spent on trademark/policy work.
-
-* Christian Couder and Ævar Bjarmason presented "Big repos".
-* The topic is very related to the „references database“ item
- below, and deals with improved rebase / staging (split index).
-* The main idea is to make the git client faster for some index
- related operations (that is, `git status`).
-* 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.
-* On Windows, there is no inotify feature available (also applies
- to some Unix flavours).
-* Some discussion arose whether the Windows journal feature or
-[Watchman](https://facebook.github.io/watchman/) was the
- appropriate road to follow.
+** Erik van Zijst presented Atlassian's "clone bundles" approach, which had been added to Mercurial some years ago, was later included in BitBucket.
+
+*** Atlassian would like to add it to Git, but would like to discuss the approach first.
+
+*** The main motivation for this feature are CPU and I/O usage on the server side.
+
+*** The feature would be good for large collections fo repos, e.g. the set for Android; the Google "repo" tool would be an alternative.
+
+*** One Alternative would be the design of the Git protocol version 2, with capabilities negociation first.
+
+*** 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).
+
+*** At present, the Atlassian client is a script mimicing `git clone`, while a proper solution would involve the Git client.
+
+*** Peff expressed his willingness to help Atlassian on this subject.
+
+*** The solution is experienced as more efficient, but no real statistics / conclusions for real world repos are available yet.
+
+** Jeff King, alias Peff, presented a "1 minute version" of the current status of the Software Freedom Conservancy; financial details available on the mailing list.
+
+*** The SFC acquired git-scm.com, maintained by Peff.
+
+*** Most effort is spent on trademark/policy work.
+
+** Christian Couder and Ævar Bjarmason presented "Big repos".
+
+*** The topic is very related to the „references database“ item below, and deals with improved rebase / staging (split index).
+
+*** The main idea is to make the git client faster for some index related operations (that is, `git status`).
+
+*** 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.
+
+*** On Windows, there is no inotify feature available (also applies to some Unix flavours).
+
+*** Some discussion arose whether the Windows journal feature or [Watchman](https://facebook.github.io/watchman/) was the appropriate road to follow.
+
 The participants with really large repos shared their experience.
 
-* Stefan Beller presented the `git submodule` state.
-* Instead of `git submodules`, Android with its 1000 Git repos uses the `repo` tool;
+** Stefan Beller presented the `git submodule` state.
+*** 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.
-* Regarding submodules, actually the fetch is parallelized, checkout is being worked on, next are worktree and submodules.
-* Inside Git, there is no real module awareness for submodules yet,
+*** Regarding submodules, actually the fetch is parallelized, checkout is being worked on, next are worktree and submodules.
+*** Inside Git, there is no real module awareness for submodules yet,
  so each and every Git module needs to be made „submodule ready“.
-* At present, one Git process is spawned for each repo, which is quite slow on Windows.
-* The submodules design is considered not to be optimal yet; as an example, subsets are not possible.
-* Within Gerrit, project changes lead to superproject changes, which might collide, and end up in superproject merge conflict mess.
-* David Turner considered merge conflict helpers for submodules.
-* Johannes Schindelin remarked that offloading such issues to tools like Gerrit looks suboptimal.
-* The topic was concluded with a short disucssion on git bisect with submodules.
-
-* Jacob Vosmaer presented the Gitlab solution for Gitaly, aka „Git RPC“.
-* Gitlab tries to get away from NFS, and would like to see a LRU disk cache,
+*** At present, one Git process is spawned for each repo, which is quite slow on Windows.
+*** The submodules design is considered not to be optimal yet; as an example, subsets are not possible.
+*** Within Gerrit, project changes lead to superproject changes, which might collide, and end up in superproject merge conflict mess.
+*** David Turner considered merge conflict helpers for submodules.
+*** Johannes Schindelin remarked that offloading such issues to tools like Gerrit looks suboptimal.
+*** The topic was concluded with a short disucssion on git bisect with submodules.
+
+** Jacob Vosmaer presented the Gitlab solution for Gitaly, aka „Git RPC“.
+*** 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.
-* The question is how far only Gitlab is affected (vs. the general community).
-* Use case example are bad refs and storing diffs.
-* The work on the Git cache started, but is stalled at present; it will be MIT licensed (uses both Git and Mercurial code).
+*** The question is how far only Gitlab is affected (vs. the general community).
+*** Use case example are bad refs and storing diffs.
+*** The work on the Git cache started, but is stalled at present; it will be MIT licensed (uses both Git and Mercurial code).
 
-* Johannes Schindelin presented "Better tools for reviews and contributions".
+** Johannes Schindelin presented "Better tools for reviews and contributions".
 
-* The mailing list currently drops contributions via mailers which produce HTML or mixed code.
+*** 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.
-* It is problematic to follow long threads (e.g. one thread
+*** It is problematic to follow long threads (e.g. one thread
  stalling for 8 months), while the state of patches discussed is
  sometimes unclear.
-* The “what’s cooking” emails are just sent to the mailing list,
+*** 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.
-* Is there a way to get from the mail client directly into the
+*** Is there a way to get from the mail client directly into the
  mentioned source code?
-* The Git terminology is sometimes strange, the Git glossary is
+*** 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”.
-* Johannes regularly submits other peoples’ patches, and would
+*** 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?
 
@@ -121,33 +129,33 @@ atmosphere at the summit, here are the unconference's agenda items:
 Johannes emphazied his willingness to establish tools which help to improve the situation.
 It was mentioned that code/commit notes should point to mailing list where appropriate.
 
-* Carlos Martín Nieto presented the state of the references database, to get them away from the file system.
-* A recurring problem seems to be that usable databases do not have a Java implementation (e.g. lmdb last tried);
+** Carlos Martín Nieto presented the state of the references database, to get them away from the file system.
+*** 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.
-* According to Peff, Git currently reads the whole packref file into memory –
+*** According to Peff, Git currently reads the whole packref file into memory –
  mmap could help but would need a lot of refactoring.
-* An important question is whether it is a client or a Github hosting problem;
+*** 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.
-* At present, not all race conditions fixed yet. The final solution should be portable to jgit / libgit2.
-* After the efforts of David Turner, there is now an appropriate ref API within Git.
-
-* Brendan Forster presented the gitignore „spec“.
-* The goal is to be more standardized and robust (that is, understandable).
-* Docs should be more structured.
-* One problem is that different implementations of Git, and other tools use gitignore, but implement the stuff differently.
-* An interesting question would be if we could have a common minimal implementation of gitignore in a generally reusable library.
-* Git attributes has similar problems (reading attributes from files in the Index is a nightmare,
+*** At present, not all race conditions fixed yet. The final solution should be portable to jgit / libgit2.
+*** After the efforts of David Turner, there is now an appropriate ref API within Git.
+
+** Brendan Forster presented the gitignore „spec“.
+*** The goal is to be more standardized and robust (that is, understandable).
+*** Docs should be more structured.
+*** One problem is that different implementations of Git, and other tools use gitignore, but implement the stuff differently.
+*** An interesting question would be if we could have a common minimal implementation of gitignore in a generally reusable library.
+*** 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).
 
-* Josh Triplett presented "Git commit refs, tag refs, and compatibility (future of git-series)".
-* Junio has suggested a different type of Git refs (in-tree, like hardlinks).
-* Compatibility: support old clients / libgit either on repo level,
+** Josh Triplett presented "Git commit refs, tag refs, and compatibility (future of git-series)".
+*** Junio has suggested a different type of Git refs (in-tree, like hardlinks).
+*** 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).
-* Use cases should be implemented as easy as possible.
-* Would be great to disallow the capability per repo.
+*** Use cases should be implemented as easy as possible.
+*** Would be great to disallow the capability per repo.
 
-* Other topics:
-* Planned Open Source Hackathons in London and New York in April/May
+** Other topics:
+*** 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.