Browse Source


Skia 9 months ago
10 changed files with 184 additions and 0 deletions
  1. +16
      talks/01 - The future of free
  2. +13
      talks/02 - Git @ Google
  3. +30
      talks/03 - The what, how and why of scaling
  4. +18
      talks/04 - Bridging the gap: transitioning Git to
  5. +11
      talks/05 - Git protocols: still tinkering after all these years?.md
  6. +12
      talks/06 - Native Git support for large
  7. +17
      talks/07 - Git for games: current problems and
  8. +37
      talks/08 - The art of patience: why you should bother teaching Git to
  9. +12
      talks/09 - Version control for law: Posey Rule in the U.S.
  10. +18
      talks/10 - Git, the annotated

+ 16
- 0
talks/01 - The future of free View File

@@ -0,0 +1,16 @@
# The Future of free software

- Explorers, discovering new places, are seen from both sides: good and bad
- Cyberpunk
- How do we make free software last forever? -> We need good people
- "Black panther" -> It's optimistic cyberpunk, utopia
- Power & responsibility.
- Leave the sandbox, include new people, and don't hesitate to dilute it all by
bringing new people ever and ever.
- People should be more happy doing free software, to share positive values, and
give a virtuous wind to their projects.
- Do more "Can I help?" than "You're doing it wrong!".

## Personal feedback

Very cool non tech talk, speaking about spirit that free software need to adopt.

+ 13
- 0
talks/02 - Git @ Google View File

@@ -0,0 +1,13 @@
# Git @ Google scale

- Many very big, heavy repos
- Interesting numbers comparing Linux repo, Go, Chromium, and Android
- Small explanation on the bitmap to increase server speed when answering clients
- shallow clone
- story about revision numbering (incremental commit numbers)
TL;DR: get used to git hashes, and avoid putting incremental numbers into commits.
- story about Gerrit: tree or forest? too many commits appearing for each revision change.
Git protocol v2 to the rescue

## Personal feeling
Great technical stories about problematic encountered in very big repos.

+ 30
- 0
talks/03 - The what, how and why of scaling View File

@@ -0,0 +1,30 @@
# The what, how and why of scaling repositories

- Git katas
- Argues about monorepos
- "The State of DevOps"
- Continuous Delivery -> Software delivery performance -> More money
- Repositories anti-patterns
- No tooling mono-repo.
- The integration team: people full time on accepting PRs
- The distributed monolith
- Study about pros/cons in mono-repos
- Pros: very good tooling
- Cons: takes time to build up good
- Netflix: dependency management is **hard**
- Conway's Law
- Story about a customer moving from clearcase to git
- Awesome graph showing repos, people, and how people contribute to repos
- easy to add code, hard to remove
- "Our conclusions are not better than our data"
- "Don't ignore the real problems"
- Discussing rebase vs merge is easy, gitlab vs github/phab is easy...
- Real questions: How is our workflow moving on? Is our scrum well done? etc...

## Personal feedback

We have a lot to take from this talk, but we are also not that badly organized
with Octopus: we don't have the mono-repo problematics, but also not a crazy
shitload of repos everywhere: it's scaled for our team.
Still, people should remember to focus on the right questions.

+ 18
- 0
talks/04 - Bridging the gap: transitioning Git to View File

@@ -0,0 +1,18 @@
# Bridging the gap: transitioning Git to SHA-256

- Why SHA-256? Why not use a broken hash (SHA-1)? Some explanations
- Transition plan:
- Precise goals, like not disturbing users, interoperability
- 4 steps:
- Dark launch
- Early transition
- Late transition
- Post transition
- More information in the git repo
- Implementation details: everything is in the slides, or the code ;)

## Personal feedback

Interesting internal stuff shown, along with some information about the
transition plan.

+ 11
- 0
talks/05 - Git protocols: still tinkering after all these years?.md View File

@@ -0,0 +1,11 @@
# Git protocols: still tinkering after all these years?

- Small intro about former git protocol: very inefficient in many cases
- Old git versions/bugs leading to double NUL byte hack: awesome! :D
- Small explanation about why old protocol was slow, and how the v2 improves this

## Personal feedback

Nice lightning talk about git protocols. Use v2, now!

TODO: check git version on Phabricator: that could explain the slowness

+ 12
- 0
talks/06 - Native Git support for large View File

@@ -0,0 +1,12 @@
# Native Git support for large objects

- What is a large file? By type? By size? Both?
- Not Git LFS: not native, just a hack, need some a priori knowledge.
- Coop between all big companies to improve git with their needs (Google, Microsoft, ...)
- Partial clone: filter objects at clone time, to ask them later, on demand.
- This can be very good to speed up some CI: just use the objects needed for the checkout, forget about old ones.
- clone using CDN: data is close to the destination, HTTP GET is resumable in case of transfer problem.

## Personal feeling

Again a nice presentation about upcoming git features.

+ 17
- 0
talks/07 - Git for games: current problems and View File

@@ -0,0 +1,17 @@
# Git for games: current problems and solutions

- Windows, terabytes of files, 90% binaries.
- No merge for binaries.
- Better communication? Doesn't scale.
- Merging doesn't mean anything for assets. It's more like artistic choices.
- File locking doesn't play nicely with Git.
- Un-mergeable files, binary files are paths through the commit graph.
A commit is then valid if it descends from every commit touching the file.
- Git Global Graph:
Uses some hooks to check the property in a unified global git graph, with per-developer namespaced branches.

## Personal feedback

Great talk about game problematics. May be helpful at some point with our testing data?

+ 37
- 0
talks/08 - The art of patience: why you should bother teaching Git to View File

@@ -0,0 +1,37 @@
# The art of patience: why you should bother teaching Git to designers

- Talk given by a designer
- Building software that makes sense to the people who use it.
- Some things can never be made simple.

## How
- Working for the Yocto Project
- She needed to design a web interface and was always stuck with git, stopping
- Teaching tips:
- "need to know basis"
- "avoid git jargon"
- "don't bother with the concepts"
- "do things with, never for, someone"
- "designers should take notes and keep a cheat sheet"
- teach from the shell, not a GUI
- Mental models are based on beliefs, not facts.
- Great Git UIs (Github) are based on "system models" not "mental models"

## Why
- You first need to convince the designer to learn.
- You must know enough about your design material.
- Quotes:
- "Learning about software as design material"
- "Turning designers into partners in building"
- "Participating in your own terms"
- Allows participating to free software

## How long
- 2 years for her!

## Personal feedback

Awesome speaker, with a completely different point of view. Don't hesitate to
share that talk with as many non-developers working with developers!

+ 12
- 0
talks/09 - Version control for law: Posey Rule in the U.S. View File

@@ -0,0 +1,12 @@
# Version control for law: Posey Rule in the U.S. Congress

- Transparency and modernization.
- Trying to increase the community of lawyers that have Github accounts.
- Use machine-readable amendments, with semantic understanding, and have a kind
of query language, leading to kinda machine-executable amendments.
- Git for law requires specialized tools.

## Personal feedback

Interesting talk about laws, and the problematics working on it.

+ 18
- 0
talks/10 - Git, the annotated View File

@@ -0,0 +1,18 @@
# Git, the annotated notepad

- Get some context in the morning.
- Small logical commits.
- Dark Souls is a **hard** game. You save every time.
- ABC: Always Be Committing
- Logical unit:
- Refactoring
- A set of functions used together
- One complex function
- Personal code review.
- Descriptive titles.
- Quick context reloading.

## Personal feedback

So very true. All that he said. We need to apply all that seriously.