Virtual Git Contributor Summit

Virtual Git Contributor Summit

[Johannes Schindelin]

Team,

I kept talking about this idea of a purely online Git Contributor Summit,
and it is finally time for action.

The idea: just like the Git Contributor Summits we have on the day before
GitMerge, but instead of traveling to the same place, we'll use an online
conferencing system.

From my point of view, the main benefits of doing this online are:

- It should make it easier for all contributors to attend (yes, Junio, we
  do miss you every single time you're not there).

- We will leave a substantially reduced carbon footprint.

- There won't be any jet-lag involved, including the consequences on
  health/sleeping.

- It is substantially cheaper and more sustainable.

Of course, there are also some challenges:

- Timezones. My idea here is to have all participants put down their
  preferred timezone and then compromising on some sort of Median.

- Timing. As it is not attached to a conference, we are less bound to a
  specific date, and that flexibility might make it harder to agree
  on one date.

To alleviate both of those points, we might want to consider spreading it
out over a couple of days? I already heard some fierce opposition against
that idea, though.

In any case, I think it would be good to give everybody some time to
coordinate and to shift work out of the way, so I propose that we look for
dates in the first two weeks of September.

Peff kindly agreed to use GitHub's Zoom license for this, which should
also make it easy to have a recording (and not having people in the same
room will benefit this, too).

To coordinate this event, I started a Google Spreadsheet where we can
decide on timezone, date(s), number of days, and later on try to imitate
the sticky game with virtual stickies for the discussions.

I will send out an invitation to the top 25 contributors (according to
`git shortlog -nse --since=1.year.ago`) after sending out this mail.

Obviously, there will be more people interested in participating; Please
do drop me an email if you're interested and I will send you a link to
that spreadsheet (as I do not read my mails continuously, it might take a
day, but I will, promise).

Thanks all,
Dscho

Re: Virtual Git Contributor Summit

[Derrick Stolee]

On 7/3/2019 9:01 AM, Johannes Schindelin wrote:
> Team,
> 
> I kept talking about this idea of a purely online Git Contributor Summit,
> and it is finally time for action.

Thanks for organizing this!

> To alleviate both of those points, we might want to consider spreading it
> out over a couple of days? I already heard some fierce opposition against
> that idea, though.

I don't have fierce opposition, but I do recommend one 8-hour day with the
intention of some contributors only able to join in the AM and some only in
the PM hours. We should not require all participants to be present for the
entire summit. By taking copious notes, we should be able to include the
rest of the community in the discussion.

Thanks,
-Stolee

Re: Virtual Git Contributor Summit

[Jakub Narebski]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Team,
>
> I kept talking about this idea of a purely online Git Contributor Summit,
> and it is finally time for action.
>
> The idea: just like the Git Contributor Summits we have on the day before
> GitMerge, but instead of traveling to the same place, we'll use an online
> conferencing system.

By the way, would there be GitTogether meeting held in conjunction with
Google Summer of Code 2019 Mentors Meeting?

> From my point of view, the main benefits of doing this online are:
>
> - It should make it easier for all contributors to attend (yes, Junio, we
>   do miss you every single time you're not there).
>
> - We will leave a substantially reduced carbon footprint.
>
> - There won't be any jet-lag involved, including the consequences on
>   health/sleeping.
>
> - It is substantially cheaper and more sustainable.
>
> Of course, there are also some challenges:
>
> - Timezones. My idea here is to have all participants put down their
>   preferred timezone and then compromising on some sort of Median.
>
> - Timing. As it is not attached to a conference, we are less bound to a
>   specific date, and that flexibility might make it harder to agree
>   on one date.

Also, all the challenges of remote-only meeting instead of real-life
contact.  Though it might be good supplement to the meeting before
GitMerge.

[...]
> To coordinate this event, I started a Google Spreadsheet where we can
> decide on timezone, date(s), number of days, and later on try to imitate
> the sticky game with virtual stickies for the discussions.
>
> I will send out an invitation to the top 25 contributors (according to
> `git shortlog -nse --since=1.year.ago`) after sending out this mail.
>
> Obviously, there will be more people interested in participating; Please
> do drop me an email if you're interested and I will send you a link to
> that spreadsheet (as I do not read my mails continuously, it might take a
> day, but I will, promise).

I think it would be good idea to have some of us from Git Rev News team
to chronicle this Virtual Git Contributors Summit meeting.

Best,
--
Jakub Narębski

Re: Virtual Git Contributor Summit

[Philip Oakley]

Hi Dscho,

On 03/07/2019 14:01, Johannes Schindelin wrote:
> Team,
>
> I kept talking about this idea of a purely online Git Contributor Summit,
> and it is finally time for action.
>
> The idea: just like the Git Contributor Summits we have on the day before
> GitMerge, but instead of traveling to the same place, we'll use an online
> conferencing system.
>
>  From my point of view, the main benefits of doing this online are:
>
> - It should make it easier for all contributors to attend (yes, Junio, we
>    do miss you every single time you're not there).
>
> - We will leave a substantially reduced carbon footprint.
>
> - There won't be any jet-lag involved, including the consequences on
>    health/sleeping.
>
> - It is substantially cheaper and more sustainable.
>
> Of course, there are also some challenges:
>
> - Timezones. My idea here is to have all participants put down their
>    preferred timezone and then compromising on some sort of Median.
>
> - Timing. As it is not attached to a conference, we are less bound to a
>    specific date, and that flexibility might make it harder to agree
>    on one date.
>
> To alleviate both of those points, we might want to consider spreading it
> out over a couple of days? I already heard some fierce opposition against
> that idea, though.
>
> In any case, I think it would be good to give everybody some time to
> coordinate and to shift work out of the way, so I propose that we look for
> dates in the first two weeks of September.
>
> Peff kindly agreed to use GitHub's Zoom license for this, which should
> also make it easy to have a recording (and not having people in the same
> room will benefit this, too).
>
> To coordinate this event, I started a Google Spreadsheet where we can
> decide on timezone, date(s), number of days, and later on try to imitate
> the sticky game with virtual stickies for the discussions.
>
> I will send out an invitation to the top 25 contributors (according to
> `git shortlog -nse --since=1.year.ago`) after sending out this mail.
>
> Obviously, there will be more people interested in participating; Please
> do drop me an email if you're interested and I will send you a link to
> that spreadsheet (as I do not read my mails continuously, it might take a
> day, but I will, promise).
>
> Thanks all,
> Dscho

Will there also be an opportunity for a listen/read -only mode for those 
of us on the lower reaches of the contributor list? I'd certainly like 
to at least keep up with progress.
--
Philip

Re: Virtual Git Contributor Summit

[Johannes Schindelin]

Hi Jakub,

On Fri, 5 Jul 2019, Jakub Narebski wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > I kept talking about this idea of a purely online Git Contributor
> > Summit, and it is finally time for action.
> >
> > The idea: just like the Git Contributor Summits we have on the day
> > before GitMerge, but instead of traveling to the same place, we'll use
> > an online conferencing system.
>
> By the way, would there be GitTogether meeting held in conjunction with
> Google Summer of Code 2019 Mentors Meeting?

I know of no such plans. Please note also that the GSoC summit is in
Munich, Germany this year.

> > Obviously, there will be more people interested in participating; Please
> > do drop me an email if you're interested and I will send you a link to
> > that spreadsheet (as I do not read my mails continuously, it might take a
> > day, but I will, promise).
>
> I think it would be good idea to have some of us from Git Rev News team
> to chronicle this Virtual Git Contributors Summit meeting.

Sure, I forwarded the information to you (Christian already had it).

Ciao,
Dscho

Re: Virtual Git Contributor Summit

[Rohit Ashiwal]

Hi Philip

On 2019-07-05 14:09 UTC Philip Oakley <philipoakley@iee.org> wrote:
>
> Will there also be an opportunity for a listen/read -only mode for those
> of us on the lower reaches of the contributor list? I'd certainly like
> to at least keep up with progress.

+1

It'd really be a nice addition if contributors, like us (the new ones),
can get a nice audio feed.

Best
Rohit

Re: Virtual Git Contributor Summit

[James Ramsay]

On 3 Jul 2019, at 9:01, Johannes Schindelin wrote:

> Team,
>
> I kept talking about this idea of a purely online Git Contributor 
> Summit,
> and it is finally time for action.

Thank you for organizing!

Yesterday, Christian and I took notes in the doc below which might be 
useful for others.

https://docs.google.com/document/d/1Yp6tz_JgUYjoofTDogtosLsdykwiAyYu9yM42yTuFA4/edit

Any additions or edits would be most welcome!

Best,
James

Re: Virtual Git Contributor Summit

[Eric Wong]

James Ramsay <james@jramsay.com.au> wrote:
> On 3 Jul 2019, at 9:01, Johannes Schindelin wrote:
> > Team,
> > 
> > I kept talking about this idea of a purely online Git Contributor
> > Summit,
> > and it is finally time for action.
> 
> Thank you for organizing!
> 
> Yesterday, Christian and I took notes in the doc below which might be useful
> for others.
> 
> https://docs.google.com/document/d/1Yp6tz_JgUYjoofTDogtosLsdykwiAyYu9yM42yTuFA4/edit

Is there a way to view that without JavaScript?
I'm using w3m.  Thanks

Re: Virtual Git Contributor Summit

[Johannes Schindelin]

[-- Attachment #1: Type: text/plain, Size: 92827 bytes --]

On Thu, 26 Sep 2019, Eric Wong wrote:

> James Ramsay <james@jramsay.com.au> wrote:
> > On 3 Jul 2019, at 9:01, Johannes Schindelin wrote:
> > >
> > > I kept talking about this idea of a purely online Git Contributor
> > > Summit, and it is finally time for action.
> >
> > Yesterday, Christian and I took notes in the doc below which might be useful
> > for others.
> >
> > https://docs.google.com/document/d/1Yp6tz_JgUYjoofTDogtosLsdykwiAyYu9yM42yTuFA4/edit
>
> Is there a way to view that without JavaScript?

Virtual Git Contributors’ Summit Notes
2019-09-12/13
Topics
1. Sparse-checkout: Client side UX (Stolee)
2. Docs: Git contributor blog & git contributor's manual (Emily)
3. Inclusion & Diversity (Dscho?)
4. Batteries not included?  What's our path forward? (Elijah)
5. Commit-graph: status and future work (Stolee)
6. Partial clone: challenges on the server side (Dscho)
-- END DAY 1 --
1. Exchanging rerere resolutions -pseudo patches?
2. Git-at-GitHub: alternates, commit-graph, etc.
3. Multi-pack-index: status and future work
4. Git Merge conference suggestions
5. CDN: best server-side strategies
6. Workflow and tooling for the Git project (especially CI)
7. Outreachy planning
8. Bi-Weekly standup: still useful? (attendance is getting sparse)
Introduction
1. Dscho: at Microsoft working on making Git great on Windows
2. Stolee: also at Microsoft with Garima Singh and Jeff Hostetler
3. William Baker: also at Microsoft working on VFS for Git. Now working on Git itself.
4. Peff: working on Git for 13 years, at GitHub, scaling and backend, but like all the code! Prev helped with Summer of Code (SoC) and also Outreachy.
5. Christian: working at Booking.com and GitLab, focus on performance and partial clone. Involved with SoC and Outreachy.
6. Elijah: start 10 years ago, disappeared for a while, started contributing again a couple years ago. Works on merge and fast import/export.
7. Phillip Wood: contributing for 2.5 years, particularly working on rebasing.
8. Matheus: working on git grep with more threading
9. Martin: started 2 years ago, fixes and docs
10. Philip Oakley: contributing for a few years, primarily the docs. Background in electronics. More recently looking at larger than 4GB problem on Windows.
11. Emily: joined Jonathan’s team recently. So far looking at contributor experience.
12. Taylor: prev maintainer of Git LFS. Work at GitHub, write the Git release posts
13.  : working for GitHub. Involved with Git on and off since SoC in 2012.
14. Brian: working for GitHub. Usually Git LFS, also working on Kerberos support and hash func transition. Also AsciiDoc.
15. James: long time reader, hoping to become more active on the mailing list. Working at GitLab.
16. ZJ: also at GitLab and long time reader. Hoping to make first contribution soon. Looking into Partial Clone.
17. John Cai: also at GitLab.
18. Jonathan Nieder:
19. Rohit: <muffled> // GSoC ‘19 Student, worked on improving consistency of sequencer commands.
20. Kevin: MSFT for 4 years, working on VFS for Git. Have made some tweaks for performance.
21. Josh:
22. Pratik: Worked on builtin rebase as a GSoC’18 student. (Convert the git-rebase script to builtin). Looking to contribute more.
Discussion 1: Sparse checkout client UX
1. Stolee: not first class in the UI. We have an RFC on the mailing list for enabling/disabling/adding patterns.
   1. https://public-inbox.org/git/pull.316.git.gitgitgadget@gmail.com/
   2. Challenge: quadratic scaling problem as more paths are added.
   3. Solution: make more restrictive - needs to be a “cone”
1. Elijah:
2. Philip: have an interest
3. Peff: haven’t been particularly focussed on the client side for large repositories. Beginning to be more interested.
4. James: big are of interest, particularly in combination with partial clone.
5. Peff: sparse based partial clones are difficult, what’s the end game with partial clone?
6. Stolee: no blobs filter turns Git into a replacement for LFS. Get it it only when you need it. Sparse checkout then reduces this further with a cone. As you do more work you get more slices. Difference between VFS and Partial Clone is this happens at checkout, then as accessed.
   1. Using no blobs will probably yield a better result with sparse checkout.
1. Elijah: put the partial clone flags behind a scary feature flag. Surprised that git grep will search outside sparsity pattern. They don’t want those results. Also takes a long time. Log or diff have similar problems. Would like these to also respect sparsity. This could help in combination with partial/VFS. Helps performance and is better aligned with user expectations.
2. Taylor: could have a flag to search everything. N+1 problem that might need to be addressed first.
3. Stolee: Elijah would you rather have a setting to make this default/config, or flag?
4. Elijah: We should have a better default. Could have a config flag as well.
5. Stolee: agree for grep and diff. Not sure about log. E.g. git log graph what do I expect to see? Git log -p this might make more sense to exclude commits outside the cone. Particularly if you change cone frequently it could be more confusing.
6. XXX: what if you highlight the ones that are in the cone, rather than hide the ones outside graph
7. Elijah: I might be on the side of also exclude them in log graph too… Some places don’t make sense like fast export etc. Not trying to view history, but (re)creating history.
8. Dscho: maybe disable these functions when in a cone, and explicitly break out of the cone. You mention you are using sparse checkout? Does the proposal work for you? Or is it an over simplification?
9. Elijah: initially worried, but feel like it close to what we already have. It’s maybe 98% of what we already have. If we get close, we could tweak our repo structure. Excited and optimistic about the proposal.
10. Stolee: open to incrementally expanding supported patterns. For example exact file match. Could be support. Hard requirement is the monotonicity - parent folders must be present. Open question: what’s the performance impact of adding these exceptions
11. Jonathan Nieder: Another partial clone situations. Commit filters then you can use partial clone to imitate shallow clone. Initially a benefit because you can later get more history. If you want to be backward compatible, some people like shallow clone illusion that history begins at some point. Illusions of partial history (path, depth etc) could be nice.
12. Kevin: conflicts outside of your cone. Cleanup outside of cone only handled at checkout. When should this be cleaned up?
   1. Elijah: how is this happening? Changing cone, checking out other code.
   2. Kevin: cherry picking changes from elsewhere that introduce conflicts.
   3. Stolee: long lived branches have this problem if collaborators on the branch make changes outside of the cone?
   4. XX: it’s a local problem though? Server has everything. Rare scenario…
   5. Elijah: renames from inside to outside cone?
   6. Taylor: rebase/picking forward - at one time had larger cone, then a reduced cone. Force client to expand their view and resolve.
   7. Jonathan Nieder: existing sparse checkout code does already handle this.
   8. Peff: difference between I can pull this in cleanly
   9. Taylor: should always be able to fast forward outside code right?
   10. Elijah: maybe it’s a little aggressive and could be improved
   11. Stolee: have to run checkout or git retree to cleanup
1. Jonathan: Elijah, do others in your team use this?
   1. Elijah: I use it a little bit. Help set it up for others. I’ve got a wrapper called “sparsify” - also handles high level dependencies and helps users get the right subdirectories. Also documents cleanup that needs to happen, gives nice warnings of gotchas. Mentioned some of this on the RFC thread to Stolee.
1. Dscho: Stolee, what do you need from others?
   1. Stolee: Lots of follow up work needed. Will have a new version next week. Internal customers don’t want to just add patterns, but completely change patterns. Set will replace Add for changing patterns.
   2. Stolee: interactions with worktrees raised by Elijah.
1. Dscho: heavy user of worktrees, and would be important to me.
2. James: I don’t have strong numbers. I will check with customers on this.
3. Peff: had customer wanting partial clone beta. Told him no. Seems more alpha.
4. Stolee: already depending on new sparse checkout in Windows for .NET work.
5. Elijah: switching from add to set, what about a list command?
   1. Stolee: yes, will keep it.
1. Philip O: in cone mode, long descriptors of sparsity. Can we use path markers?
   1. Stolee: cone mode has ..
   2. Dscho: could you make cone mode a tri-state?
   3. Stolee: old way would still work, just slower
1. Elijah: patterns had trailing asterisks. Anything with a wild match will be slower. What about a trailing slash?
   1. Stolee: first level needs a slash star, wanted to be consistent. Agree it could be faster
1. Elijah: different patterns for ignore, sparse checkout and as args.
   1. Dscho: restrict to intersection?
   2. Elijah: if paths are explicit, take what’s given. Otherwise default to sparsity
   3. Taylor: special rule, none patterned path specs expand the cone, otherwise don’t expand to prevent inflating everything?
   4. Elijah: hard to do intersection since they don’t support the same filtering ops
1. 2.


Discussion 2: Docs: Git contributor blog & git contributor's manual
1. Emily: two kinds
   1. Blog by contributors for users
   2. Manual by contributors for contributors
1. Emily: should we put blog on the same domain as the book: git-scm
   1. Peff: no progress. Not same site, but not difficult. Just give me something to point a CNAME at
   2. Peff: not wordpress please. Use Git!
1. Tailor: what kind of content?
2. Emily: howto for tricky topics like:
3. Stolee: for example sparse checkout
4. Taylor: nice complement with what we do at GH. Switch and restore command. Link to the contributor blog
5. (zoom chat) Jonathan: gitignore and "git update-index --assume-unchanged"
   1. gitster has written lots of "fun with" docs, like https://git-blame.blogspot.com/2016/05/fun-with-new-feature-in-recent-git.html
1. Emily: tie with corporate blog otherwise no manager time to work on it
2. Peff: not too much time on content that should be in doc. Intros are ok, but let’s still add examples to the doc
3. Emily: operations that user do cannot fit in a man page because they are comprised of a lot of commands
4. Stolee: casual voice on blog post
5. Peff: I want to do blog stuff
6. Taylor: light updating should be ok to say that a blog post is not up to date
7. Emily: updating the site: I am not good at that
8. Peff: let’s use GH and a static generator like GH pages
9. Stolee: I agree. It’s very simple.
10. Emily: I agree it’s pretty easy. Don’t let me style.
11. Peff: git.github.io part of the same or separate? Jason Long who did the look of the site is very busy
12. James: we need a concrete visual proposal. I can spend some time to create a rough proposal. Implement an MVC
   1. Very rough start… https://gitlab.com/git-scm/blog/merge_requests/2
1. Emily: Thank you
2. Peff: I will ping Jason to know his plan. I am fine with doing it on GitLab
3. Stolee: we want to do review, to ask for review on the mailing list
4. Emily: sure otherwise it’s just a personal blog. What about dumping the text part on the mailing list?
5.  Stolee: GH action is good at that
6. James: GL CI is also good at that. It could move somewhere else after the prototype step
7. Emily: we need to aggregate topics We can use the issue tracker. Doc takes a lot of effort so we should make sure
8. Peff we have been writing for every release something. In the past Atlassian also used to do it too.
9. James: Thanks for writing this!
10. Taylor: it is time consuming I’d love to have an advanced set of hyperlinks.
11. Stolee: community blog: create release notes for the future release
12. Peff: that’s how Junio work. It could be the  same community version as what Junio does. It could be worked on parallel
13. Emily: good candidate to crosspost. A blog post at the same time as release notes.
14. Taylor: yeah that’s what I wanted. I don’t know who to ask.
15. Stolee: here is a feature specific blog post about a thing in a rc release to get more tests. With trace2 I got it merged.
16. Peff: people might want to work on different aspects. Some people are good at writing other who wrote the code might not. “I need to understand so I will spend time to look at that”
17. Taylor: I tried out something for a few days before writing about it.
18. James: a what’s cooking for instance administrator. Customers are worried about things happening in Git. Customers also have no idea about what’s going on. Expensive to explain. It would be a good idea to collaborate on it.
19. Taylor: about some advance things I emailed Stolee bt there should be no reason he should be the only one to receive such email.
20. Emily: anything else to discuss?
21. Stolee: a way to request collaboration? I would like someone to write a blog about.
22. Emily: if we use issues we can post requests for someone to write something.
23. Peff: it’s almost implicit that all new features are blog postable. People writing should be interested in the feature. Junio’s release notes should be the starting point.
24. Stolee: ask for people who are not contributing code to help
25. Peff: yeah let’s invite people
26. Garima: we need to be more inviting to people so that they feel empowered
27. Emily: we need to advertise that we want this kind of work.
28. Brian: whether in the repo or blog people can be very valuable
29. Emily: awesome. The action point we have is James suggestion.
30. Stolee: I might take a spin at the ??? post
31. Dscho: that could attract new talent if we put it in some posts
32. Emily: I’d like things about switch and restore, worktrees, ???
33. Taylor: interactive modes
34. Stolee: let’s brainstorm about those
35. Emily: let’s open issues on the project James posted. That’s awesome!
We can talk about the contributor tutorial that I wrote. Where to put that doc in the worktree? I have a stack of examples and I’d like them to be somewhere. Store the patch set as mailbox file? How to review and inflate those patches?
Peff: mailbox seems reasonable to me.
1.  Emily: thanks to my teams for those ideas. We had an internal brainstorm. Is there a good idea about part of the documentation tree that we want to reclaim?
2. Brian: people have trouble finding the contributor doc.
3. Emily: I agree. Jonahan Nieder suggest Documentation/contribute
4. Philip O.:
5. Peff: git help is not useful providing guidelines. git-scm.com/community answers some questions. Suggestions to update that are welcome. That could be the definitive place.
6. Emily: contributor manual I’d like a list of topics. What do others would like to see?
7. JN: how to make contributions other than patches. Linux kernel has stuff about that. How to help with non code contributions
8. Garima: how to setup  mailing list interactions ??
9. Garima: submodules, why they were introduced, what to look out for. Dscho had to give me a long overview


   1. Dscho: done - don’t use them.
   2. Emily:I want a screenshot of the “the lecture”
1. JN: there is a page about pack files which was first a conversation on IRC
2. Garima: Will send the lecture. will edit out colorful embellishments. What was the rationale for submodules? Best practices.
3. JN: contributions to the submodule page would be welcome. Article about the platform problem. Low hanging fruit it’s the platform I can’t touch it
4. Emily: review should help outline historical reasons. I encourage you to send the notes about the conversation you had with Dscho.I would like something about the index.[a][b]
5. Dscho: everyone can use the GL project to start working


Let's have a 10 minutes pause




Let’s go with inclusion and diversity


Discussion 3: Inclusion & Diversity


1. Dscho: I would like more diversity It would make us stronger.
2. When I have to introduce someone to Git I feel that it’s not very well designed for beginners
3. Our contribution process could become more open and fun
4. Outreachy was kind of fun
5. What we could do to use our privilege to change things
6. Brian: I’d like to see a code of conduct. I heard from women that they are more comfortable contributing with such a policy that is enforced
7. Taylor: I agree
8. Peff: controversy around the kernel. Nobody is interested in starting it.
9. Emily: I am interested
10. Peff there is an invisible cost of not doing it
11. Taylor: the cost is far from invisible
12. Stolee: Linux Kernel it was kind of a surprise.
13. Emily: when there was controversy in the Kernel it came mostly from outside
14. Taylor: I agree
15. JN: there is a possibility about some kind of pain. People already participating have privilege and should accept a little bit of pain to improve things for everyone
16. Peff: the project attracted people interested in decentralized projects. We don’t have centralized mechanisms. We don’t have a way to block people on the mailing list. What does it mean to get sanctions?
17. Garima: historically I don’t think I have benefited from enforcement. I have benefited from support. What about people who didn’t have the support I had. Maybe putting more energy in bringing people in would work better.
18. Dscho: Outreachy was great. I could give attention back. Maybe we can do pairing? We could offer to support some people interested in getting mentored. We could write a blog post where we propose to mentor.
19. Mentor list idea
20. Stolee: people could be matched on the mailing list.
21. Taylor: is there an advantage compared to other
22. JN: the mailing list is a common place and I like it but in practice it means it is very intimidating. It is a hurdle. The feel of what the community is based on guesses or some sub parts of what they read.
23. Taylor: discovery issue. Another mailing list is easier to discover.
24. James: I am pretty new to mailing list. It was terrifying to send a first email.
25. Taylor: should discussions be always on the mailing list or should there be issues
26. JN: irc channel is pretty good for user help. If someone wants to contribute they are accommodating themselves. It becomes a compromise.
27. Emily: asking for a mentor on the mailing list is very unusual and terrifying.
28. Peff: every avenue introduced only get a subset of all the people on the mailing list. It’s a fight to get enough people
29. Emily: having less people in a mentoring mailing list could be a feature as it would be less intimidating
30. Brian: we could post about the mentor list or something else so that it appears on Google.
31. Pratik: GSoC and Outreachy do a great job. Microprojects do a good job.
32. Taylor: could have messages forward up to the mailing list.
33. James: maybe we can improve the FAQ or something
34. Peff: the Community page tries to do this, improvements welcome!
35. Jonathan: we should meet people where they are, DM them on Twitter, separate mailing list etc. Promised segue: fear of the mailing list - if you don’t know how the project will handle problematic behavior then that affects the decision to participate
36. Peff: 95% of benefit of CoC is positively documenting the behaviours we do want! Working out all the enforcement mechanisms isn’t super helpful.
37.  Brian: in the past we’ve asked argumentative/disagreeable people not to come back. Want the community to be positive overall. Bringing in other kinds of people is a good goal.
38. Jonathan: example Brian mention, Junio asked them to stop. Took a long time to get there. Felt like a lot of damage was done on the journey.
39. Peff: everyone new the guy was behaving uncollaboratively, but tried to help the individual become a constructive part of the community. Didn’t help. Not sure what a CoC would have done?
40. Stolee: wouldn’t it have helped by being able to point to the CoC, rather than hand waving nebulously.
41. Peff: this person would try to work around rules. Would violate informal style guide. Maintainer would say we do it this way then they would argue if it’s not formalized I can do it anyway I want. Make it broad or rules lawyering kind
42. Taylor: exhaustive doc can never be written. Have none, or have one that people try to lawyer around?
43. Peff: I want a doc
44. JN: Contributor Covenant does a good job for the most part.
45. JN: Considering test case individual, were focussed on coding guidelines. At least they were aware or paying attention? Collateral damage, individual was a role model to others.
46. Outreachy
47. We need micro projects, mentors, …
48. Christian: I am planning to do something about it
49. Garima: I think the “welcome to the mailing list” email needs to be improved as well. It is currently quite dry and almost cold. Make it more inviting with helpful “here’s how you get started with xyz” links would be great. For instance, the blog on working the mailing list itself, the code of conduct, the contributors doc, best practices etc.


Discussion 4: commit-graph
1. Stolee: appreciate the community involvement, fixing bugs and testing. Thanks Peff for fixing bug while I was on paternity leave.
2. Stolee: most of the original plan is done. Incremental writes, build on fetch are recent improvements.
3. Stolee: bloom filters coming soon!!
4. Taylor: not sure we’ll use multi commit graph. Very excited about bloom filters.
5. Stolee: very excited about incremental commit graph - huge gain at Microsoft.
6. Stolee: what’s next!? Ideas, suggestions etc.
7. Dscho: blog post by JN, blame information could be interesting.
   1. JN: I have no memory of this
1. Taylor: GitHub has a custom blame tree implementation.
2. Peff: Know which paths each commit touches would be plenty.
3. Stolee: seems like blame doesn’t benefit in the prototype bloom filter yet.
4. Peff: you, me, JT spoke about bloom filters with touched paths, vs other information which would yield similar outcomes. Could store raw tree diff output, but it also solves other things. Have you considered other formats? Rejected such ideas?
5. Stolee: benefit of storing all this extra information. Bloom filter only stores 10bits.
6. Peff: assume master list of paths and perhaps objects too.
7. Stolee: haven’t given much thought. How would this work with 4 million commits, 3 million files per commit. Each commit is only changing 100 files or so. Computing the diff isn’t hard, except doing it very many times.
8. Peff: will review past discussions
9. Stolee: I think it was the blame tree
10. Peff: wildcards was the problem, can’t enumerate the paths the commit touched. Only ask was this path touched. Still need a master path list.
11. Taylor: if you’re enumerating the path list, the results are going to be pretty bad.
12. Stolee: similar to blame tree, if you work ahead of time, you can do the hashes just one. Not constantly rehashing. Just a bit comparison. Maybe some value
13. Stolee: never built this feature. Which history calls take longer than 1 second? Author calls - open loads of commits and check author. Create author list, with integer pointer. Wanted compressed list rather than linear list stopped me from doing this previously. Git log stolee will show me everything with partial match.
14. Peff: we’d also benefit from an author commit graph of sorts
15. Stolee: generation number - only places it matters is where date leads to wrong priority. Plans for how to make it work. Implementation details are not super trivial. Probably not high priority.
16. Peff: rolled out 30 mins ago! Still finding corner cases and opportunities to use it. No major show stoppers.


Discussion 5: partial clone server side
1. Dscho: very challenging! Very free form - insane burden on the server. Bitmaps/cones can be used in a pack.
2. Peff: fetching initial partial clone, subsequent fetches?
3. Dscho: can’t predict which delta objects to use. Worst case, unpack all the delta chains and then have no compression whatsoever.
4. Peff: won’t unpack the delta for you, but you might not have the base object. Terrible N+1?
5. Dscho: JT I recall something different (microphone problems)
6. JT:  protocol forces it send everything.
7. JN: catchup case as JT describes. Other case is max blob size. Compute using haves and wants, then apply the filter.
8. Dscho: worst case is not ideal.
9. JN: clarify, if I checkout, I haven’t provided any haves.
10. Dscho: concerned about individual blobs, need to get 500 blobs to do a diff, needs to unpack, then repack.
11. JN: we considered this, so we could send haves from the diff, but not implemented.
12. Dscho: concerned about impact of partial clone. Reminds me of CocoaPods shallow clone.
13. JN: own experience on the server. Partial clone is a substitute, and much cheaper. Shallow clone depth 1 requires tree walk, but bitmap makes it faster.
14. Peff: Clarifying CocoaPods, terrible, but same as ls-tree. Worse is shallow clone and then repeatedly fetch. Degenerate case when shallow fetch crosses merge boundary. Both spend tonnes of CPU and then end up not very shallow.
15. JN: follow up fetches have been with partial and shallow.
16. Peff: rely heavily on reachability bitmaps. Don’t work at all with filters. Have a patch to make them work with no blobs and blob limits. Won’t be possible with sparse partial.
17. Dscho: will reachability bitmaps help with incremental fetch?
   1. Peff: no
   2. Dscho: could we do something?
   3. Peff: after repacking, the most recent object is delta’d in the other direction. Bigger things should be base, which generally follows time. Clone checkout is fine, but over time it becomes worse. VFS for Git probably have models for this.
   4. Dscho: we cache everything.
   5. Peff: if you ask me for object X, but as a delta against Y, expand X or send both X and Y which uses more bandwidth, but much cheaper CPU wise. Helped a little in some cases, didn’t help egregious case that inspired me. In partial clone close, having the base object IS good. Need heuristics about chain length/size, limiting to 120% of size for example
1.  Dscho: how close is GitHub?
   1. Taylor: could turn it on.
   2. Peff: partial clone faltered by chicken and egg. We would like to start enabling and not make a big deal. Treat it like a beta. Already turned on for a few projects internally. Maybe just one.
   3. Peff: had segfaulting bugs, bitmap thing is a show stopper.
1. Christian: reachability bitmaps, same a bloom filters?
   1. Peff: no. heavily compressed, don’t bitmap every one – select some commits in history, and then walk from that commit.
   2. Stolee: problem with bloom filters is handling maybe. Need to do the work to verify. With reachability, get maybe you have to fallback to reachability walk which is very expensive.
1.  JN: delta chains, are they long?
   1. Dscho: locally yes, but not sure about Azure repos.
   2. Peff: did timings. Anything over 50 is crazy. Really, 10 is not much worse. Instead of having a chain, you have a tree.
   3. Dscho: apologies for the 250.
   4. Peff: it was pure superstition. Quite funny.
   5. JN: what params is GitHub using?
   6. Peff: we use 50. If you push a really long chain, we’ll break it. We pull between packs and ended up 1000 deep
1. James: what about client UX
   1. Taylor: once usage comes, we’ll document
   2. Peff: we need a straight simple solution for sparse checkout
   3. Stolee: macros that recently merged - feature.largerepos to be able to do certain things
1. Dscho: discoverability of new features is really important.
2. Stolee: working on something closer to a layer on top of Git for VFS. The VFS layer should become thinner and thinner. More to come before next contributor summit.
3. Taylor: do you have long term visions for VFS for Git?
   1. Stolee: Long term, no one needs it.
   2. Stolee: Still restricted to GVFS protocol for now. Azure doesn’t support partial clone or protocol v2.


Discussion 6: batteries not included
1. Elijah: filter-branch work brought this to mind. Can we remove non-core things? People seemed interested, but not anytime soon. Where would it go? When should we discuss? Git imerge, sizer, etc
2. Stolee: git-svn, git-p4 could be removed. Not core to what Git users need.
3. Taylor: no objections, removing filter branch seems a little more scary. Other approach is wait till everyone uses Elijah’s tool.
4. Peff: implying a replacement needs to be provided. Not always true. There are things that are relatively unmaintained things that could be pulled out.
5. Elijah: i did extract the history of filter branch with a self standing copy. Show how it could be removed.
6. JN: seems reasonable
7. Peff: no reason not to include under git/, I’d be happy to maintain since my involvement. Tool isn’t going away. Just maintainership changes.
8. Stolee: all these different places that use Git will need to ship this other thing too.
9. JN: not so bad for most.
10. Taylor: what about the user who is ignorant of this change? Doesn’t know they need to install a debian package.
11. Dscho: script with error that points to new location
12. Dscho: did you use filter-branch or repo to extract filter branch?
   1. Elijah: filter-repo of course!!
1. Peff: problem with filter branch is arbitrary code with all sorts of unspeakably bad things.
2. Taylor: but what about the 99% who are surprised? Could there be a wrapper that converts?
3. Elijah: not just a command line tool, but library to create new filtering tools. There is a proof of concept that passes the filter branch tests that sits on top of filter repo.
4. Peff: seems like it could be horrible. (Elijah: yep, sure is.)
5. Taylor: helper to teach people about filter repo.
6. JN: what do we want git.git to provide? Sounds like some people are interested in removing git-svn etc --- what is in scope to keep? Perhaps we should define principles.
   1. Peff: yes…
   2. JN: I’ll start a conversation on the mailing list
   3. Elijah: Take into account the effect on translations
1. Dscho: foreign SCM connectors are also candidates for being pushed out from git.git
2. Peff: gitk seems to require the additional dependency Tcl/Tk
A. git-gui, too, but seems to be used on Windows
B. Taylor: gitk user questions seem to come up regularly on the Git mailing list
3. Peff: gitweb
4. Jonathan N.: git daemon
A. Dscho maybe replace with an HTTP backend?
B. Jonathan N.: but would be the same maintenance burden as daemon. instaweb approach seems nicer
5. JN: what should we include?
   1. Dscho: git request pull not used widely - only linux and busy box
   1. Elijah: where would we advertise what is being pushed out?
   2. Elijah: where would we let users know about useful tools like imerge or sizer?
   3. Dscho: often discover new tools through Rev News, but not many people know about it.
   1. Elijah: and it’s news, so you have to go back and read old posts.
   2. Peff: too bad we don’t have a blog…


Discussion 7: rerere
   1. Philip O: I have a patch series with conflicts in pu and next, hard to tell people how to resolve the conflicts. Not much documentation on this so that an author can provide the conflict resolution to others. Don’t understand what the script does, particularly since it was changed from shell to C
   2. Taylor: send rebased series? Or export rebase cache to send as an email. Challenge, send merge indications.
   3. Philip O: there is a training script which will go over an existing set of merges to learn the fix, but there isn’t corresponding to take learnings from someone else
   4. JN: comes up and contributor docs don’t explain what to do. Rerere is nice, but not well documented.
   1. Contributors can push their merge commit to another repo for others to look at.
   2. Conflicts are not guaranteed stable over time, so sharing a conflict resolution data has a limited shelf life.
   1. Taylor: what Peff and I do, we take changes from upstream, do the merge, create diff between conflicted states. Challenge of diff machinery. Varies based on diff settings and merge driver.
   2. Philip O: would like “here’s what I prepared earlier” so that some people can enjoy convenience.
   3. JN: need to better advertise the habit of pushing merge commit somewhere
   4. JN: there was a proposal of improving git show to understand how conflicts have been resolved
   5. Dscho: this makes a tonne of sense. Context of rerere is to help quickly resolve the same problems in different branches. Rerere doesn’t help me on Git for Windows.
   6. JN: fundamentally, two separate problems: show something for review, and record the final, resolved state
   7. Dscho: why not show the range-diff between the patch series and a rebased version?
   8. JN: see two next steps: (1) advertise "please push the merge commit" in SubmittingPatches and (2) implement remerge-diff!
   9. Dscho: mentioned Pijul as an SCM that has nice internal representations of merge conflicts and resolutions.


Discussion 8: GitHub alternates, commit graph
   1. Taylor: sharing about our fork of Git and work we’ve been doing. Two big perf projects over last 6-8 months:
   1. Improve use of alternates with receive-pack
   2. Enable commit graphs for all 100M repos
   1. Peff: difficulty is huge amounts of noise on the small scale. We’ll keep collecting data to get a better sense of impact of commit graph.
   2. Taylor: other than upstream patches by Peff, very smooth. Running 2.22. Updating commit graph with all reachable commits by maintenance job (run at a minimum time or after certain level of activity)
   3. Garima: reachable commit graphs across all the forks
   4. Peff: version 2 of the generation numbers. Not sure where we’d see this manifest.
   5. Garima: new topic on an old commit is where most problems emerge, but this isn’t very frequent
   6. James: we’re running stock Git, excited about feature flags and making more of an effort test experimental features earlier. Recently worked hard to catchup.
   7. JT?: we’re using JGit at Google, so no commit graph.
   8. JN: reftable was a big performance win and working well.
   9. James: Christian is working on reftables, probably getting back on to this now that multiple promisor remotes is in pu or next.
   1. Taylor: Chris is doing the same. Lots of branches… https://github.com/chriscool/git/tree/reftable86
   1. Taylor: anyone want to talk about alternates?
   2. Dscho: when you rollout new Git versions, how do you do it?
   1. Taylor: staged rollout, one server, to one rack, to everywhere. Peff and I check, tperf, then rollout.
   2. Peff: scientist was all ruby. It might be possible to compare diff output between version, but disk state is difficult.
   3. Peff: because replication strategy sits above Git, replicas never sit in the same rack. Now you are in a situation where there are replicas running old version. Older deploy wins if there is an inconsistency.
   4. Talyor: frequent checksums to keep on top of things.
   5. Peff: not scientist, but pseudo-science perhaps
   1. Taylor: no major challenges, run 1 release + 2 weeks behind
   1. Deploy once a day or so
   1. JN: advertising support vs implementing protocol capability. Separate round trips.
   2. Taylo: been doing deduplication with alternates for a long time with fork networks.
   1. Special environment variable to setup custom alternate refs
   1. James: any changes to Git to support spokes?
   1. Talyor: not really. Have a helper to coordinate the three phase commit for refs. Not a true three phase commit, but its safe in the ways you’d expect it to be
   2. Taylor: one change is a quota tool to limit a machine from using too much resource per user per repo. Some light interaction in fork of Git to halt when monitoring says so!
   1. Dscho: thank you for satisfying our curiosity.


Discussion 9: Multipack index
   1. Stolee: status report! From client perspective essentially done. Take all the idx files and make one that goes over all of them. Used by VFS for Git. Do an incremental repack every day. Do this in the background without disrupting. Next day we expire the old packs. It’s how we handle having lots of prefetch packs
   2. Stolee: opportunity to have different packs for trees etc. Big amount of work. Lots more information needed in mindex file
   3. JN: could you elaborate?
   4. Stolee: Reachability index would increase in size
   5. Stolee: not going to do anymore is incremental, we just do it daily on incremental repack (maintenance).
   6. JN: not a principled objection?
   7. Stolee: correct, just not a priority for us. Happy to review!


Discussion 10: workflow and tooling
   1. JN: “Patches Carved on Stone Tablets” is positive about mailing list workflow, projects are stubborn. On list, various areas raised are:
   1. Using mailing list as medium for sending patches is less obvious - GitGitGadget has helped, but more work to be done?
   2. Related, joys of programming today is having test suite run quickly on someone else's CI
   3. Bug tracker
   1. Dscho: the most important decision maker is not here: Junio.
   2. JN: role of the maintainer - newcomers often expect that the maintainer will drive the direction of the project. In the Git project, this isn’t so. Contributor should judge consensus.
   3. (lots and lots more discussion)
   4. Stolee: GitGitGadget took away most pain points about their contributions
   5. Peff: GitGitGadget shows that Junio does not need to be involved in decisions how to improve the workflow
Discussion 11: Git Merge conference suggestions
   1. Planning for next Git Merge: probably March, probably North America, with a Contributors’ Summit if people want
   2. Traditional format: single track, workshop day before main conference
   3. Peff: maybe more cross-user/developer breakout groups
A. Stolee: interested in it!
B. JeffH: might be a good venue to learn about users’ pain points
C. JeffH: maybe do Contributors’ Summit afterwards, to talk about freshly learned things?
D. JeffH: could also talk more freely about things that are announced in the main conference (GVFS, Git LFS)
   4. Peff: maybe more structured format than just a round table? Workshop with users with their laptops out.
A. Elijah: giving a technical workshop or talk might make it easier to obtain travel funding from employers
   5. Concerns about being able to fill a full Git Merge day of talks?
A. We’re pretty much at a point where most talks are from end users’ perspective
B. Developers can learn a lot from the users
   6. Peff: maybe talks in the morning, and related workshops in the afternoon?
Discussion 12: CDN: best server-side strategies
      1. Dscho: intro (what would it be good for? Large repositories, geo-distribution, resumability)
      2. Dscho: question is how/when to generate them, how to put them on CDN, how to decide which CDN URL to suggest to clients
      3. Jonathan Tan/Nieder: current working hypothesis is to collect commits of the past <N> hours, put them in a pack, serve that pack from CDN
      4. Peff: could use bitmaps to decide about packs
      5. Jonathan Tan: we plan on using packs with date/time cutoffs with all commits reachable from then-current refs
Discussion 13: Bi-Weekly standup: still useful? (attendance is getting sparse)
      1. Elijah: should we maybe switch to Zoom or something?
      2. Peff: “I don’t find them useful at all ;-)”
      3. Jonathan Nieder: background: started as an exchange of ideas between Google/Microsoft, we tried to make it more public
      4. Stolee: got side-tracked, but still find them useful
      5. Peff: most of it could happen on the mailing list, too
      6. Jonathan Nieder: find it useful, sometimes “need mentorship myself”
      7. Peff: find synchronicity annoying
      8. Thomas: find IRC useful mostly outside standups
      9. Dscho: replies on mailing lists can be annoyingly slow, it is asynchronous by design
      10. Peff: it is a major commitment (like the 8 hours of Contributors’ Summit)
      11. Jonathan Nieder: probably most useful for people who would feel hesitant to “bother” people on the mailing list, e.g. giving GSoC/Outreachy students a time when they are expected to talk and others to listen
      12. Dscho: time is awkward, it’s 7pm on a Friday for me, i.e. cuts into my weekend. Proposing new time: Monday, same time, every two weeks, starting this coming Monday? Nobody objected, Dscho will send a mail.
Discussion 14: Any interest in having or setting up a planet.git.org?
      1. Examples: https://planet.gnome.org/, https://planet.debian.org/
      2. Will open an issue on https://gitlab.com/git-scm/blog/issues/
It’s a wrap!


Thank you all! The record of this meeting is in these notes. While the video was recorded, it is a huge file, and the notes are more useful anyway.
________________
Chat log day 1
11:01:34             From  Phillip Wood : Philip - At least it mean we can tell each other apart
11:10:49             From  Christian Couder : GitLab people are going to take notes in  https://docs.google.com/document/d/1Yp6tz_JgUYjoofTDogtosLsdykwiAyYu9yM42yTuFA4/edit# but Everyone can contribute to it!
11:25:26             From  Josh Steadmon : Been contributing for about a year, work @ Google with Jonathan, Jonathan, and Emily. Have worked mostly on trace2 lately
11:25:51             From  Pratik Karki(prertik) : Hi, I'm Pratik Karki. I was a GSoC
11:25:56             From  Pratik Karki(prertik) : '18 student
11:26:06             From  Pratik Karki(prertik) : I worked on built-in rebase.
11:26:36             From  Jonathan Nieder : https://public-inbox.org/git/pull.316.git.gitgitgadget@gmail.com/
11:28:00             From  Dscho : Thanks, Jonathan!
11:29:19             From  Jonathan Nieder : VFS for Git illustrated that sparse checkout and partial clone play nicely together
11:31:43             From  Jonathan Nieder : With increased use of sparse checkout, we'll also get more benefit out of improvements to the index file format
11:31:55             From  Dscho :  Yes!
11:32:01             From  Jonathan Nieder : Making operations O(working set size) instead of O(total size)
11:37:33             From  Jonathan Nieder : checkout and diff already batch
11:37:49             From  Jonathan Nieder : (by checkout, I mean unpack-trees)
11:38:22             From  Jonathan Nieder : For grep with partial clone, we'll need to add support to the protocol
11:38:34             From  Jonathan Nieder : Since you really want to only fetch blobs that match the pattern
11:38:54             From  Jonathan Nieder : (Likewise for blame)
11:38:56             From  Dscho : But `git grep` already accepts pathspecs.
11:39:02             From  Jonathan Nieder : I mean the grep pattern
11:39:05             From  Dscho : Aren't they already respected in partial clones?
11:39:12             From  Jonathan Nieder : E.g. "git grep -e <symbol>" shouldn't fetch files that don't match <symbol>
11:39:27             From  Jeff King : I think there are two levels: you could say "grab this so I can grep it". More efficient is "please grep this for me, and then hand me back the resulting blobs".
11:39:42             From  Dscho : Big burden on the server.
11:39:46             From  Jeff King : But there may be room for both, depending on how much work the server is willing to do for you.
11:39:54             From  Jonathan Nieder : What Peff said
11:40:14             From  Jonathan Nieder : I may be biased since I'm surrounded by people comfortable with indexing :)
11:40:22             From  Dscho : :-)
11:48:03             From  Jonathan Nieder : kewillford: cleaning up on "git commit" sounds good to me
11:52:15             From  Emily Shaffer : it writes the result even in the case of an automerge? or only when there's a conflict that needs intervention
11:52:33             From  Jonathan Nieder : The intent is the latter, but it sounds like there may be some edge case bugs of the former category
11:57:36             From  Elijah Newren : Yeah, it'd be preferable to only write the result in the case of a conflict, but that's not yet always the case.
11:58:37             From  Jonathan Nieder : We've used the partial clone client side for a while, but have been using JGit on the server side
11:59:37             From  Jeff King : jrnieder: Most of the issues we hit were around `clone --filter=sparse:oid`.
11:59:52             From  Jonathan Nieder : oh, right
12:00:31             From  Jonathan Nieder : we haven't used that at all, as mentioned before. I like the intent around it (pre-canned sparse patterns) but given that it's had zero real-world exposure I would likely remove it if I ran the world
12:00:34             From  Jeff King : I agree that might not be the direction we want to point people long term (in favor of blob-limiting), but it was at least a thing I tried pretty early on in playing with the feature.
12:00:51             From  Jonathan Nieder : (as mentioned before on list, I mean)
12:05:24             From  Jonathan Nieder : Could imagine this being a different mode for pathspecs. Have a "pathspec magic" to widen to outside the cone
12:05:37             From  Jonathan Nieder : That way, if I use '-- "*.c"', I would get things within the cone
12:06:11             From  Jeff King : Yeah, I'd agree with that.
12:06:15             From  Dscho : Good idea with that magic!
12:06:42             From  Jonathan Nieder : BTW, do we have a gitpathspec(7) manpage yet? :)
12:07:33             From  Jonathan Tan : Yeah and I can type here if I have an opinion
12:10:52             From  Jonathan Nieder : gitignore and "git update --assume-unchanged"
12:10:58             From  Jonathan Nieder : *update-index
12:11:28             From  Jonathan Nieder : gitster has written lots of "fun with" docs, like https://git-blame.blogspot.com/2016/05/fun-with-new-feature-in-recent-git.html
12:11:47             From  Jeff King : Yeah, those "fun with" are a great example of what I'd like to see on a blog.
12:12:36             From  Phillip Wood : That's a good point peff
12:12:51             From  Jonathan Nieder : I think it's a good way to start fleshing out your thinking, to say something a little more controversial / less settled
12:13:36             From  Philip Oakley : Much of the blog and RevNews articles can get lost relative to users looking at manual pages.
12:13:41             From  Jonathan Nieder : like in https://git-blame.blogspot.com/2015/10/fun-with-recreating-evil-merge.html: 'If this proves to be a viable approach, it would make sense to do these procedures inside "rebase --first-parent" or something.'
12:14:22             From  Jonathan Nieder : +1 to reviewers nudging people toward the "let's fix the docs and fix the commands now that you've identified the issue"
12:14:24             From  Philip Oakley : The docs themselves don't really have a section that can hold these generic user 'how to snippets / guidance.
12:14:34             From  Jonathan Nieder : There's no opportunity for that if people don't try writing the post in the first place
12:14:50             From  Jonathan Nieder : "git help workflows" has some howto stuff
12:14:55             From  Jonathan Nieder : also Documentation/howto
12:15:28             From  Jonathan Nieder : there's a lot of variance between command / concept pages but some have some of that kind of content in the EXAMPLES section, too
12:15:41             From  Philip Oakley : Often the signposting wasn't as great as we hope or believe for real users
12:15:54             From  Jonathan Nieder : I think you're overestimating our hope :)
12:16:53             From  Philip Oakley : We underestimate how often users do read the obvious stuff (e.g. 5% vs 1% ;-)
12:17:28             From  Phillip Wood : The documentation does not always do a good job of introducting high level concepts and ideas. The man pages tend to be very detailed and quite low level, they don't always do the best job of explaining how different commands work together.
12:18:16             From  Jonathan Nieder : > The documentation does not always do a good job of introducing high level concepts and ideas.
+1,000,000. The user manual makes an attempt at this but is underloved. The Pro Git book has done some filling in of the gap
12:18:37             From  Jonathan Nieder : c.f. the example of "where's the gitpathspecs(7) page" from earlier today
12:19:30             From  Philip Oakley : We aren't great at linking to the concepts, glossary, cli etc pages, or checking that tey explain the concepts well and are up to date
12:20:27             From  Philip Oakley : Isn't there also the Google summer of Docs we could avail ourselves of..
12:20:53             From  Jeff King : The book content is decent, and I think makes an attempt to have this kind of high-level content in away that is revised over time (and explicitly solicits community input)> But being a book and having such a large scope, I think people are hesitant to make big changes to it, or add whole new concepts.
12:22:00             From  Pratik Karki(prertik) : Agree with Emily.
12:22:26             From  Jonathan Nieder : https://developers.google.com/season-of-docs/docs/admin-guide looks like Season of Docs is in autumn (we missed this year's application period)
12:23:25             From  Pratik Karki(prertik) : Taylor's blogs on GitHub discussing Git release are really good.
12:23:45             From  Phillip Wood : >c.f. the example of "where's the gitpathspecs(7) page" from earlier today
12:24:22             From  Phillip Wood : The pathpecs are documented in gitglossary but it took me several minutes to find them
12:24:51             From  Jonathan Nieder : for comparison, organization like https://gerrit-review.googlesource.com/Documentation/
12:25:13             From  Jonathan Nieder : guides, tutorials, reference, concepts
12:26:24             From  Philip Oakley : There is the `git help -g` for the guides ...
12:26:41             From  Jonathan Nieder : *nod*
12:27:12             From  Jonathan Nieder : in that list, attributes and hooks are reference docs
12:27:20             From  Jonathan Nieder : and modules
12:27:56             From  Jonathan Nieder : in general, the "git help" improvements over time have been very nice
12:29:03             From  Philip Oakley : One issue I've had is the view that the man pages are only for reference of those who already understand the command ..
12:29:30             From  Jonathan Nieder : huh. I hope we can squash that view :)
12:29:50             From  Philip Oakley : When I introduces the help -g it was because of the difficulty of realising that they were there
12:29:52             From  Jonathan Nieder : unless you mean view by users, in which case it's a fair criticism
12:29:53             From  Emily Shaffer : It's hard to discover a command when you need to write "git help <command>" to learn about it :)
12:30:43             From  Philip Oakley : brb 2 mins...
12:30:47             From  Dscho : We need a chat bot with AI ;-)
12:31:24             From  Jonathan Nieder : https://gitirc.eu/helping.html triggers have worked well (with humans acting as the AI)
12:40:26             From  Jonathan Tan : There have been a few topics suggested on the mailing list too
12:40:38             From  brian carlson : I think those are all great topics.
12:41:02             From  Zeger-Jan van de Weg, Gitaly : Didn't know reset had an interactive mode, great!
12:41:05             From  Jonathan Tan : https://public-inbox.org/git/20190806014935.GA26909@google.com/
12:41:10             From  James Ramsay – Senior Product Manager : https://gitlab.com/git-scm/blog
12:41:36             From  Jonathan Nieder : \o/ thanks for setting it up
12:41:49             From  Dscho : Yay!
12:44:48             From  Jonathan Nieder : I think you're referring to contrib/examples
12:45:03             From  Jonathan Nieder : Documentation/contribute sounds nice to me
12:45:09             From  Jonathan Nieder : more generally, more organization within Documentation
12:46:28             From  Jonathan Nieder : gitcontributing(7): Nice idea!
12:50:15             From  Jonathan Nieder : "my first contribution" has a bit about that
12:50:44             From  Jeff King : A blog post surveying all of the mutt hacks that people use might be interesting, but I fear it would also scare everyone away.
12:52:29             From  Taylor Blau : I would be happy to do just that, but I also think that it would scare people off.
12:52:51             From  Emily Shaffer : I also want to contribute to that, I <3 mutt (if only because I can write emails in vim)
12:52:51             From  Dscho : Yep, I don't have a whole lot of positive things to say about submodules...
12:53:08             From  Taylor Blau : Dscho, I think I remember you complaining about submodules two years ago at dinner in Brussels… ;-).
12:53:17             From  Taylor Blau : It’s good to see that you have really let it go since!
12:53:25             From  Dscho : Hahaha!
12:55:36             From  Jonathan Nieder : https://lwn.net/Articles/443531/ "the platform problem"
12:55:50             From  Elijah Newren : +1 to some coverage of the index file
12:55:51             From  Phillip Wood : +1 for a high level overview and detailed docs for the index
12:56:46             From  Phillip Wood : When I started contributing I looked through Documentation/technical but most of the documents I tried to read just listed someone who was going to write it in the future
12:57:36             From  Jonathan Nieder : > listed someone who was going to write it in the future
 I think we should consider removing those. The intent is good but the effect may be more like "cookie licking"
12:59:12             From  Phillip Wood : >I think we should consider removing those
12:59:49             From  Phillip Wood : I agree, they don't serve any useful purpose
13:00:10             From  Jeff King : Yeah, most of those are 10+ years old. If the people haven't been guilted into writing the docs by now, I don't think it's going to work.
13:03:00             From  Emily Shaffer : I actually used one of those in the talk I mentioned... not as a good example :P
13:15:06             From  Emily Shaffer : this seems to me to tie well into a little of the previous topic - inviting diverse types of contribution also
13:15:15             From  Jeff King : Yeah, agreed Emily.
13:15:19             From  Emily Shaffer : +10000 to CoC, i thought we had one already and was mistaken. the contributor covenant is great
13:16:12             From  Emily Shaffer : I did a lot of work on another project (openbmc) getting a CoC introduced and adopted, and a large part of that was getting volunteers for the escalation path in case of a violation
13:16:37             From  Emily Shaffer : Hi Taylor, I'm a woman who led last topic ;)
13:18:54             From  Emily Shaffer : I wonder if a mentorship pairing area is a good way to make the project more accessible?
13:19:20             From  Emily Shaffer : I think we also lack a good issue tracker - having somewhere for wannabe contributors to look and see what work is wanted is really important. Right now the learning curve is VERY high
13:19:51             From  Dscho : I opened up https://github.com/gitgitgadget/git/issues for that purpose, as a test balloon.
13:20:03             From  Jonathan Nieder : there's also https://crbug.com/git
13:20:24             From  Dscho : (I was about to mention that, too, just didn't find the URL that fast.)
13:20:34             From  Emily Shaffer : I vote we dig into the issue tracker item on mainstream chat given the history of that topic
13:20:42             From  Pratik Karki(prertik) : I'm also non-white :)
13:21:16             From  Dscho : Jonathan Tan is also not your typical Caucasian ;-)
13:21:37             From  Matheus Tavares : >I wonder if a mentorship pairing area is a good way to make the project more accessible?
I think the mentorship idea is great. One of the greatest things in participating in GSoC for me was having mentors to directly ask questions and get feedback.
13:23:58             From  Pratik Karki(prertik) : Great idea Dscho.
13:25:15             From  Phillip Wood : I've got to drop out for a while, hopefully I'll be back later. Having a way to connect potential contributors to mentors would be really great.
13:25:51             From  Matheus Tavares : >I think we also lack a good issue tracker

(about issue trackers and first issues for newcomers, I tried to list some here. Maybe it helps in some way: https://matheustavares.gitlab.io/posts/first-steps-contributing-to-git#where-to-contribute Please, let me know if something is missing or outdated)
13:26:23             From  Emily Shaffer : +1 to JRN, that's exactly what I was going to say.
13:26:40             From  Pratik Karki(prertik) : This is really good write, Matheus. Thank you for this.
13:26:46             From  Emily Shaffer : It is also VERY scary to post to the mailing list where people are going about their Important Business to say "I'm new and don't know what I'm doing"
13:28:10             From  Jonathan Nieder : https://groups.google.com/forum/#!forum/git-users
13:28:58             From  Stolee : https://gitlab.com/git-scm/blog/issues/5
13:29:00             From  Emily Shaffer : +100! It's very scary
13:29:05             From  Stolee : (thanks Garima for that link)
13:34:07             From  Jonathan Nieder : Junio sends "A note from the maintainer" for each release
13:34:27             From  Jonathan Nieder : I agree, similar posts are a good way to make things discoverable
13:35:01             From  Jonathan Nieder : May be that I'm saying that in part because I'm used to it from FAQs in Usenet :)
13:36:00             From  Philip Oakley : Adding to Brian's comment, we could have occasional 'New Contibutions' note, that expands and separates from the release notes bit about new contributors
13:36:05             From  Emily Shaffer : It's a good point, we don't want to burn out all the mentors :)
13:36:55             From  Rohit : Can't we just advice using GitGitGadget until "beginners" are familiar with the mailing list?
13:37:33             From  Emily Shaffer : But at least then it's tagged
13:37:37             From  Philip Oakley : There should also be a note that clarifies that Git is a critical version storage and verification system, so that reviews will be firm but fair, because of it's criticality in some areas.
13:37:38             From  Emily Shaffer : "tagged"
13:39:39             From  Emily Shaffer : +1, like many vintage FOSS projects there's a lot of "if you're 'in' you know how to use these tools" - IRC, mailing list, etc
13:40:08             From  Emily Shaffer : I tried to cover part of the ML from patch perspective in MyFirstContrib
13:40:23             From  Dscho : "Vintage FOSS" ;-)
13:40:33             From  Emily Shaffer : ;)
13:41:02             From  Emily Shaffer : like a fine wine-is-not-an-emulator
13:41:06             From  Philip Oakley : Also that contributions and emails  don't need to be even perfect ..
13:41:07             From  Jeff King : Hand-crafted artisanal FOSS.
13:41:18             From  Pratik Karki(prertik) : :)
13:42:19             From  Matheus Tavares : >I tried to cover part of the ML from patch perspective in MyFirstContrib
As a feedback, colleagues here at my university reported they are much more confortable with joining the community after following MyFirstContrib. So, thaks for that :)
13:42:41             From  Philip Oakley : For diversity we should also be going out and getting target groups (any group, but don't scatter gun)
13:42:42             From  Emily Shaffer : !!!! Thank you for that feedback, that makes me so happy that it's being read
13:47:30             From  Emily Shaffer : I think being able to point to something like this as "prior art" is useful
13:48:17             From  Emily Shaffer : has everyone read the Contributor Covenant? I think it strikes a good balance between broad and detail
13:48:30             From  Dscho : I agree.
13:48:35             From  Dscho : That's what we use in Git for Windows.
13:48:37             From  brian carlson : Yeah, that was what the version I personally was going to propose.
13:48:48             From  Emily Shaffer : https://contributor-covenant.org
13:49:00             From  Stolee : https://github.com/git-for-windows/git/blob/master/CODE_OF_CONDUCT.md
13:49:36             From  Philip Oakley : Need to make sure the words are international, not just written from one community view
13:50:09             From  Philip Oakley : Also we need to be inclusive if we are to have diversity, rather than limiting.
13:50:12             From  Emily Shaffer : Philip's point makes me feel more firmly that, like crypto, we shouldn't try to roll our own
13:50:34             From  brian carlson : I have to head out, but I hope to see you all tomorrow.
13:51:03             From  Jonathan Nieder : see you, Brian. Thanks for your thoughts today
13:52:19             From  Emily Shaffer : I'm happy to participate in enthusiastic review for CoC
13:52:42             From  Jonathan Tan : The website explains my main concern better: "Before adopting the Contributor Covenant take the time to discuss and decide how to deal with problems as they emerge. Document the policy and procedure for enforcement, and add it to your README or in another visible, appropriate place."
13:52:46             From  Stolee : Yes, we will want lots of positive reinforcement for this.
13:53:04             From  Pratik Karki(prertik) : Awesome.
13:53:06             From  Emily Shaffer : I agree with point about having a veteran contributor post the review
13:53:08             From  Jonathan Nieder : Jonathan Tan, +1
13:53:33             From  Jonathan Tan : But I agree with having this. I'm not personally affected (like Garima, I had a lot of help from giants when I first started), but I think that it will help many people.
13:53:38             From  Philip Oakley : We also need to dismantle the implicit, unrealised white male geek aspects
13:54:06             From  Jonathan Nieder : Sorry about that
13:54:28             From  Elijah Newren : +1 on the Git-For-Windows style CoC
13:54:50             From  Stolee : (I think Peff has a loud keyboard)
13:54:57             From  Pratik Karki(prertik) : +1
13:54:59             From  Jeff King : Philip: Yeah, that part is really hard. You want to maintain a balance where people can be themselves and not coldly professional. But without veering too far into weird in-jokes.
13:55:49             From  Jonathan Nieder : An example mentoring project: https://kernelnewbies.org/KernelMentors
13:56:28             From  Jeff King : jrn: Yeah, I like the general gist of that page.
13:56:45             From  Jonathan Nieder : Sounds like it would be helpful for git@vger.kernel.org to send a more helpful "welcome message" to new subscribers too
13:56:55             From  Matheus Tavares : Maybe not exactly what we are looking for, but here's another mentoring example https://www.x.org/wiki/XorgEVoC/
13:56:59             From  Jeff King : I have no idea what that welcome message even says, or who wrote it.
13:58:01             From  Emily Shaffer : as an aside, given the previously mentioned demographic of this summit, i feel really happy hearing how positively all of this is being discussed. big thanks everybody - i think we have a good community :)
13:58:56             From  Jeff King : I'm of the opinion that we're mostly nice and welcoming people, but we have a hard time advertising and demonstrating that.
13:59:06             From  Jeff King : But that might be a subjective opinion. :)
13:59:27             From  Pratik Karki(prertik) : I agree Git community is nice and welcoming,
14:01:59             From  Philip Oakley : Tolerance isn't mentioned in the CoC I had a discussion on the https://github.com/git-for-windows/git/pull/661
14:03:35             From  Jonathan Nieder : https://public-inbox.org/git/200902130045.59395.jnareb@gmail.com/
14:04:14             From  Stolee : Sounds Good, Dscho!
14:05:04             From  Emily Shaffer : peff - fyi google has a meeting coming up Friday specifically to brainstorm outreachy projects
14:05:44             From  Jeff King : Emily: Great!
14:09:31             From  Jonathan Nieder : I don't remember this :)
14:10:18             From  Pratik Karki(prertik) : https://bugs.chromium.org/p/git/issues/detail?id=18&q=&colspec=ID%20Type%20Status%20Owner%20Summary%20Modified
14:10:39             From  Jonathan Nieder : ahh, right
14:10:47             From  Jonathan Nieder : (shorter url: https://crbug.com/git/18)
14:11:01             From  Pratik Karki(prertik) : Sorry.
14:13:31             From  Jonathan Nieder : can use huffman coding if you want variable-length identifiers
14:14:29             From  Jonathan Nieder : in general this feels like a perfect application for bloom filters, though
14:14:40             From  Jonathan Nieder : since the effect of false positives is not so terrible
14:15:41             From  Jonathan Nieder : ahh, e.g. '*.c' pathspecs
14:16:02             From  Dscho : Or `Documentation/`
14:16:03             From  Jonathan Nieder : can mix leading paths and file extensions into the bloom filter but that approach only goes so far
14:16:52             From  Jeff King : Yeah, Documentation/ is easy because we can hash all prefixes of paths. But wildcards are much more unbounded.
14:17:21             From  Jonathan Nieder : I think '*a*' being slow is reasonably intuitive
14:18:15             From  Jonathan Nieder : but even 'Documentation/*.c' is hard to accelerate. You can only search for "changes Documentation/ and changes a .c file" with the approach I described
14:18:58             From  Jeff King : Yeah, but if you short-circuit the "changes Documentation/" part it can still give a big speedup.
14:19:32             From  Jonathan Nieder : ship it :)
14:20:13             From  Jonathan Nieder : On the server side, we'll likely be doing some generation number experimentation next year
14:20:44             From  Jonathan Nieder : Will keep the list informed (and cc stolee). If anyone else makes progress, we're very interested
14:22:23             From  Jonathan Nieder : Do you mean partial clone or packfile URIs, or their combination?
14:23:11             From  Jonathan Nieder : Our experience is that we hate long delta chains in general, even without partial clone
14:23:43             From  Jonathan Tan : sorry can you repeat the question
14:24:33             From  Dscho :             Sorry Jonathan N. ;-)
14:25:17             From  Philip Oakley : Shouldn't the partial/sparse spec be exchanged with the server so it knows what it's bases are.
14:26:07             From  Jeff King : The problem is the spec isn't always clear (or even remembered by the client!). Think something like "I cloned long ago with no blobs larger than 100k". But since then I fetched some of the objects. And maybe did some more fetches with other blob sizes.
14:26:35             From  Jonathan Tan : Philip Oakley: that might be a good idea. Right now the server assumes the client has everything, so it may send deltas, and the client will refetch the delta bases if they are needed during pack processing
14:27:09             From  Jonathan Tan : And to be clear, this is during "normal" fetches (to commits) when we sand "have" lines as usual.
14:27:38             From  Jonathan Tan : When doing the missing-object lazy fetch, we don't send "have" lines, so the server will send full objects.
14:27:50             From  Philip Oakley : My y thought was this 'server' was a second home PC that interacted with say main laptop so acted as a local 'backup' without being fully populated.
14:30:18             From  Jonathan Nieder : thank you!
14:31:31             From  Jonathan Nieder : The protocol relies on "have"s and "want"s. When you're doing the lazy fetch of blobs, everything hinges on what "have"s you pass
14:32:52             From  Jonathan Nieder : The pack delta heuristics work great on the client
14:33:00             From  Jonathan Nieder : On the server I don't think we've really investigated it well
14:34:38             From  Jonathan Nieder : yes, I like it
14:36:05             From  Jonathan Nieder : Yes please :)
14:37:45             From  Jonathan Nieder : Bloom filters are a probabilistic representation of a set
14:38:05             From  Jonathan Nieder : EWAH bitmaps are a compressed (mostly run-length encoding based) representation of an exact set
14:43:23             From  Jonathan Nieder : Would love a "git partial-clone" manpage
14:43:27             From  Jonathan Nieder : and probably a command
14:44:15             From  Pratik Karki(prertik) : +1
14:45:02             From  Jonathan Nieder : I think the thing to stitch these all together will be VFS for Git
14:45:18             From  Jonathan Nieder : i.e. we should ship the end-to-end VFS thing as part of Git
14:45:22             From  Jeff King : I hope that VFS for Git can go away in favor of an option to switch these together.
14:45:39             From  Jeff King : When step 1 is "install this kernel level filesystem driver", it seems like a pretty big hurdle.
14:46:01             From  Jonathan Nieder : if we make OS developers happy enough, they can install it by default :)
14:46:43             From  William Baker : > if we make OS developers happy enough, they can install it by default :)
14:46:57             From  William Baker : On Windows the filter does ship with the OS
14:47:29             From  Philip Oakley : sparse and partial need to be in the glossary so we can be sure we are not talking about shallow...
14:48:08             From  Emily Shaffer : agree with Philip - there's a discoverability issue with sparse/partial in that the name doesn't really match the flags used to turn it on
14:48:13             From  Emily Shaffer : partial especially
14:48:52             From  Philip Oakley : I can never remember which is which ;-)
14:53:52             From  Philip Oakley : filter-branch: maybe host copy at https://github.com/git
14:54:00             From  Jeff King : Yeah, exactly.
14:54:12             From  Pratik Karki(prertik) : True.
14:58:13             From  Pratik Karki(prertik) : https://github.com/newren/git-filter-repo
Chat log day 2


From Emily Shaffer to Everyone: (10:59 AM)
 good morning-ish again all
From Pratik Karki(prertik) to Everyone: (11:00 AM)
 It's night time in Nepal :)
From Emily Shaffer to Everyone: (11:00 AM)
 you get to stay up pretty late! wishing you lots of coffee
From Jeff King to Everyone: (11:00 AM)
 In the words of the great philosopher Alan Jackson, "It's 5 o'clock somewhere".
From Pratik Karki(prertik) to Everyone: (11:01 AM)
 Thank you. I did here about, "It's Friday somewhere" by Aaron Patterson.
From Me to Everyone: (11:05 AM)
 Thanks, Jonathan.
From Dscho to Everyone: (11:05 AM)
 Anybody taking notes?
From Elijah Newren to Everyone: (11:06 AM)
 I took some notes yesterday
From Dscho to Everyone: (11:06 AM)
 Didn't the GitLab people start a Google Doc?
From Pratik Karki(prertik) to Everyone: (11:06 AM)
 Yeah
From Emily Shaffer to Everyone: (11:06 AM)
 https://docs.google.com/document/d/1Yp6tz_JgUYjoofTDogtosLsdykwiAyYu9yM42yTuFA4/edit?usp=sharing the gitlab doc
From Dscho to Everyone: (11:06 AM)
 Thank you!
From Emily Shaffer to Everyone: (11:06 AM)
 If I take notes I'll miss the meeting content :) hope someone else is a good multitasker
From brian carlson to Everyone: (11:19 AM)
 I’ve used the git protocol in a highly restricted local network where anonymous clones were needed but HTTPS wasn’t viable due to lack of certificates.
From Jonathan Nieder to Everyone: (11:24 AM)
 https://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools
From Jeff King to Everyone: (11:27 AM)
 https://git-scm.com/downloads/guis is another list. I don't actively curate it, but people do submit PRs to update it from time to time.
From Jonathan Nieder to Everyone: (11:27 AM)
 Should "git help" advertise rev-news?
From Emily Shaffer to Everyone: (11:28 AM)
 LOL thanks for the enthusiasm Peff
From Me to Everyone: (11:28 AM)
 Ha ha ha
From Thomas Gummerer to Everyone: (11:34 AM)
 I did document the rerere format/logic to the best of my understanding a while ago in Documentation/technical/rerere.txt
From Jonathan Nieder to Everyone: (11:36 AM)
 merge.conflictstyle, etc
From Me to Everyone: (11:36 AM)
 Yes, the nice thing about Peff and I is that we use the exact same merge settings :).
From Thomas Gummerer to Everyone: (11:37 AM)
 rerere does try to take the differences in merge.conflictStyle into account, so different settings there would work when exchanging rerere resolutions
From Emily Shaffer to Everyone: (11:38 AM)
 being able to export rerere cache would help us out a lot with a workflow where we rebase a set of patches on top of next in a brand-new clone every week or so... :)
From Jonathan Nieder to Everyone: (11:39 AM)
 Hm, if you're repeatedly rebasing, wouldn't any conflicts you run into be likely to be novel?
From Me to Everyone: (11:39 AM)
 .qfg Oops, wrong window.
From Jonathan Nieder to Everyone: (11:40 AM)
 https://public-inbox.org/git/CABPp-BFQJZHfCJZ1qvhvVcMd-_sOfi0Fkm5PexEwzzN+Zw2akw@mail.gmail.com/ has some discussion of remerge-diff
From Jeff King to Everyone: (11:40 AM)
 jrn: Sometimes. My workflow is to merge all of my topics to 'next' to create a daily driver. So I resolve first there. Then later, as the upstream thing I conflict with hits master, I rebase on top of it and get the same conflict.
From Phillip Wood to Everyone: (11:40 AM)
 I've got a branch based on next with my topics merged into it, rebasing that on Junio's next tends to give the same conflicts if the topic itself hasn't changed Being able to share resolutions between a desktop and laptop would be useful as well
From Garima Singh to Everyone: (11:43 AM)
 What if we added rerere to features.experimental?
From Jonathan Nieder to Everyone: (11:43 AM)
 rerere.enabled is 'false' by default, could be a good candidate for including in features.experimental
From Jonathan Nieder to Everyone: (11:43 AM)
 Unless it's too experimental for that :)
From Me to Everyone: (11:43 AM)
 Totally agree with your first comment, jrn.
From Garima Singh to Everyone: (11:50 AM)
 Junio could use "git restore <your merge> <conflicted file>"
From Jonathan Tan to Everyone: (11:51 AM)
 Let's say I have A -> B -> <merge> but I want A -> <merge>: "git restore <merge> <file>" would include the changes in B, right? (And I don't want the changes in B)
From Jeff King to Everyone: (11:52 AM)
 Garima: one trick with that is he may not have merged the same two things. So taking your end result verbatim might lose changes that are unrelated. He really needs to take the changes you did during the merge, and then apply them on top of his state. Sort of the difference between a cherry-pick and "git checkout <commit> <paths>"
From Pratik Karki(prertik) to Everyone: (11:52 AM)
 Good suggestion Dscho.
From Garima Singh to Everyone: (11:53 AM)
 (Stolee is at Garima's keyboard, so all stupid ideas are his)
From Phillip Wood to Everyone: (11:53 AM)
 >Sort of the difference between a cherry-pick and "git checkout <commit> <paths>"
From Jonathan Nieder to Everyone: (11:54 AM)
 I see two next steps: (1) advertise "please push the merge commit" and (2) implement remerge-diff!
From Dscho to Everyone: (11:55 AM)
 Yeah, right! ;-)
From Phillip Wood to Everyone: (11:55 AM)
 Exactly - I've cherry-picked merges while I'm rebasing to  get the conflict resolution from a previous rebase
From Me to Everyone: (11:58 AM)
 https://pijul.org/  https://arxiv.org/pdf/1311.3903.pdf
From Jeff King to Everyone: (12:00 PM)
 Having an actual `log --remerge-diff` is tricky because of all of the merge refactoring needed. But in the meantime, generating _one_ remerge diff, if you don't mind dirtying the working tree, is pretty easy: if you have the merge as $merge, then just "git checkout $merge^1; git merge $merge^2; git diff $merge" So if people would like to experiment with sending the result to the list, that's an easy starting point.
From Elijah Newren to Everyone: (12:04 PM)
 Peff: the simple remerge-diff you suggest does have some downsides.  E.g. in the case of a D/F conflict, merge-recursive puts the file at an alternate location that isn't tracked in the index, so a diff will show that file as having simply been removed in the merge, which is a bit weird.
From Jonathan Nieder to Everyone: (12:05 PM)
 It comes up when you have a new topic branch branched from a very old commit E.g. a fix or revert based on an old bug
From Jeff King to Everyone: (12:06 PM)
 Right, that new commit would have a very low generation and we'd delay visiting it.
From Jonathan Nieder to Everyone: (12:08 PM)
 E.g. if I "want <topic>" and "have <master>" and don't have bitmaps, this could waste time walking to find out what objects to send bitmaps save you though :)
From Me to Everyone: (12:15 PM)
 https://github.com/chriscool/git/tree/reftable86
From Dscho to Everyone: (12:15 PM)
 yay for revision management in branch names
From Garima Singh to Everyone: (12:16 PM)
 refs/heads/reftable-FINAL_FINAL_v4
From Garima Singh to Everyone: (12:23 PM)
 Roughly how many commits is GitHub carrying forward?
From Me to Everyone: (12:23 PM)
 I’ll check...
From Me to Everyone: (12:24 PM)
 $ git log --oneline github ^master | wc -l     2542 $ git log --oneline --no-merges github ^master | wc -l     1817
From Dscho to Everyone: (12:24 PM)
 You could, just for fun, no really, hear me out, call `git rebase -ir` with those patches, just to see whether they would apply in some sort of way...
From Me to Everyone: (12:25 PM)
 Our total diff to upstream is: 127 files changed, 3644 insertions(+), 607 deletions(-)
From Dscho to Everyone: (12:25 PM)
 (Side note: `git rev-list --count --no-merges master..GitHub`)
From Garima Singh to Everyone: (12:25 PM)
 thanks!
From Dscho to Everyone: (12:26 PM)
 For comparison, diff between v2.23.0 and v2.23.0.windows.1:
 185 files changed, 8802 insertions(+), 727 deletions(-)
From Jonathan Nieder to Everyone: (12:30 PM)
 https://lwn.net/Articles/798631/ is an example practice for this kind of thing
From Jonathan Tan to Everyone: (12:30 PM)
 Regarding tracking upstreaming, I vaguely recall the Linux kernel community discussing Change-Ids :-)
From Jonathan Nieder to Everyone: (12:30 PM)
 long thread starting at https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2019-August/006739.html
From Jonathan Nieder to Everyone: (12:33 PM)
 https://gerrit-review.googlesource.com/c/gerrit/+/91253
From Philip Oakley to Everyone: (12:37 PM)
 a variant of replace for commit messages ?
From Dscho to Everyone: (12:37 PM)
 `git replace` still requires the original objects to be present, no?
From Emily Shaffer to Everyone:  06:56 PM
GGG does have CI via Azure Pipelines right?
From Garima Singh to Everyone:  06:56 PM
If CI = PR Builds, then yes
From Emily Shaffer to Everyone:  06:57 PM
ok, yes. let me say "presubmit build and test" instead of CI
From Garima Singh to Everyone:  06:57 PM
and git.git has an azure-pipelines.yml, too
From Me to Everyone:  06:57 PM
Indeed.
git.git has AzDO and Travis support.
From Emily Shaffer to Everyone:  06:57 PM
I think there's no reason Junio is a blocker for folks standing up a presubmit builder that listens to the ML (or snowpatch, or whatever)
From Garima Singh to Everyone:  06:58 PM
I once tried building a "mailing list to PR" converter. Emails are a _very noisy_ medium.
From Phillip Wood to Everyone:  06:58 PM
Dscho - does that mean we run tests on windows before submitting a pull request on GGG then?
From Garima Singh to Everyone:  06:58 PM
GGG PR builds run Linux, Mac, and Windows build & test
From Emily Shaffer to Everyone:  06:59 PM
Whoever wrote that on MS end I'm really curious about how that went, because I was playing with writing essentially that :)
From Garima Singh to Everyone:  06:59 PM
I'll see what I can dig up.
From Emily Shaffer to Everyone:  06:59 PM
thanks!
From Me to Everyone:  06:59 PM
Phillip, what Garima said: yes.
From Phillip Wood to Everyone:  06:59 PM
Garmia said I need a PR, I was asking about presumbit
From Garima Singh to Everyone:  07:00 PM
If you create a PR, the builds will run. It won't submit to the ML until you type "/submit"
From Me to Everyone:  07:01 PM
You can also just register your GitHub fork with Azure Pipelines.
Then it will run on all your branches ;-)
From Emily Shaffer to Everyone:  07:02 PM
I worry about moving away to some tool because we trade one kind of usability (nice UX) for another (regional blocking - GH has been in news for blocking users in some countries) (slack continues to lack accessibility features making it unusable for folks with some kinds of disabilities) etc
I don't have a good solution :) but think it's worth mentioning
From Pratik Karki(prertik) to Everyone:  07:02 PM
Agree with Emily.
From Philip Oakley to Everyone:  07:02 PM
Maybe we need a way (at a destination) of at least converting emails that have HTML to plain text so they become acceptable at that level for those finding it difficult to make plain text.
From Phillip Wood to Everyone:  07:03 PM
Thanks Dscho, I've done that with travis but it would be good to be able to run the windows tests early before I'm ready to open a PR. I'll register with Azure Pipelines
From Emily Shaffer to Everyone:  07:03 PM
Philip - lots of other MLs do similar, I think that'd be useful
From Philip Oakley to Everyone:  07:05 PM
yes, a 'sanitize' mail address would be useful.
I think the PR process can narrow the people focus, while the mail list does create a bazaar or mellee of people
From Pratik Karki(prertik) to Everyone:  07:05 PM
True.
From Philip Oakley to Everyone:  07:06 PM
creating 'community' can be hard...
From Jonathan Nieder to Everyone:  07:06 PM
thank you
From Emily Shaffer to Everyone:  07:08 PM
it's true gerrit doesn't give rangediff, but I don't think you get that easily via emailed patches either (unless you apply it all - which you can do very easily from Gerrit)
if i understood the meaning - "i want to review the diff from master to branch-head"
From Jonathan Nieder to Everyone:  07:09 PM
https://groups.google.com/d/msg/repo-discuss/92PqVTBTbXI/Y_MaYVOsAgAJ
From Elijah Newren to Everyone:  07:10 PM
I absolutely do NOT want to review an entire branch as a single diff.  That's what I find most objectionable about GitHub and most others.  That's the one thing Gerrit got right -- treating commits as the unit of review.
From Phillip Wood to Everyone:  07:11 PM
You can comment on individual commits on GitHub but it gets a bit disjointed
From Elijah Newren to Everyone:  07:11 PM
Gerrit added submission of multiple commits making it closer to my ideal of commit-as-unit-of-review, and topic-as-unit-of-merging.
From Emily Shaffer to Everyone:  07:11 PM
ah, sorry to misunderstand. Do you mean because the cover letter gives you a summary - this whole branch is n LOC changed - and Gerrit doesn't?
ah, merge time
From Pratik Karki(prertik) to Everyone:  07:11 PM
Elijah: *nod*
From Emily Shaffer to Everyone:  07:11 PM
thanks for clarifying!
From Elijah Newren to Everyone:  07:12 PM
Though I still hate Change-Ids and refs/for/ from gerrit.
From Jonathan Nieder to Everyone:  07:12 PM
our protocol v2 plans would get rid of refs/for/
From Elijah Newren to Everyone:  07:12 PM
ooh, I'm intrigued.
From Jonathan Nieder to Everyone:  07:13 PM
for Change-Ids, I think there's room for Git itself to do something similar in a more graceful way
e.g. like the "git evolve" proposal
From Emily Shaffer to Everyone:  07:15 PM
recently I heard about a couple projects moving to some solution with mailing list and maybe also issue tracking? I'll see if I can find my notes and the name of the solution
From Garima Singh to Everyone:  07:18 PM
Garima: as someone who worked on Azure Pipelines: Wohoo!
From Emily Shaffer to Everyone:  07:19 PM
meta, can we take a break after this topic? my dog is asking to go outside :)
From Jeff King to Everyone:  07:20 PM
Emily: Good idea!
From Philip Oakley to Everyone:  07:21 PM
It's also knowing the problems we are trying to solve (or problems that the current solution solved)
From Me to Everyone:  07:26 PM
JRN if you want to set up snowpatch, I'd be curious to see it in action (hopefully it does not take too much work?)
From Emily Shaffer to Everyone:  07:27 PM
It seems to me like Gerrit is 95% towards something people want to use, with the exception of:
- Change-Id / refs/for/* - which is I think close to being unneeded
- Needing to use the web UI - maybe we can bot around that, it's possible to have bots post review in Gerrit I think?


So maybe this is a situation where it makes sense to wait for the project to mature for a little longer and check back later
From Me to Everyone:  07:28 PM
Emily, I personally found the UI of Gerrit quite overwhelming and not only a little bit confusing. I think I would require training to use it.
From Emily Shaffer to Everyone:  07:31 PM
It has been a long time since I was new to Gerrit UI (it is the first review tool i ever used, so I guess I am biased towards it too) - I think good guides exist, though
Or, if not, I bet they would like to see a Gerrit 101 tutorial contribution ;)
From Pratik Karki(prertik) to Everyone:  07:32 PM
That would be great :)
From Me to Everyone:  07:32 PM
What I would like even better would be changes in the UI that make it more intuitive to use (i.e. more similar to other UIs I use every day).
From Emily Shaffer to Everyone:  07:34 PM
that's also valid - I think the point I was trying to make with "we are constrained to web UI and this is bad" is that everyone has a different set of UIs they wish it were similar to, so I think it's infeasible to hope the UI becomes pleasing to everyone
for me, I'd like to keep doing reviews in vim too :) so if I could do reviews in vim and export the comments to gerrit, it'd be happy. But that's likely not the experience you're talking about.


Not to say "we should choose one and pressure Gerrit developers" - but to say "it'd be nice to choose a tool which lets us use whatever workflow works well for us"
From Phillip Wood to Everyone:  07:34 PM
I've got to go now. Thanks everyone it's been really interesting
From Emily Shaffer to Everyone:  07:35 PM
o/
From Jonathan Nieder to Everyone:  07:38 PM
BoFs
From Pratik Karki(prertik) to Everyone:  07:41 PM
Will the contributor's summit be livestreamed? Or maybe video be shared?
From Emily Shaffer to Everyone:  07:42 PM
I would like to do workshops!
From Jonathan Nieder to Everyone:  07:44 PM
yes! :)
From Jonathan Tan to Everyone:  07:44 PM
Pratik: I don't know, but for your reference, this has been discussed before: https://public-inbox.org/git/87h8jyrtj6.fsf@evledraar.gmail.com/ (search for "remote A/V participation"
From Emily Shaffer to Everyone:  07:48 PM
I was thinking the same thing Peff
From Pratik Karki(prertik) to Everyone:  07:55 PM
(and Pratik's flaky internet connection)
From Jonathan Nieder to Everyone:  07:55 PM
Which Jonathan? :)
From Jeff King to Everyone:  07:56 PM
Pratik: I missed your comment earlier. I believe the main conference was live-streamed last year (and maybe would be this year, though if we have a ton of little rooms that's harder). The contrib summit was streamed in zoom. A few people watched but didn't talk. I do have the recording somewhere, but it's not publicly available.
Related question: what do people want to do with the recording of this summit?
From Philip Oakley to Everyone:  07:59 PM
JN that note about largefile threshold helps me understand an issue I have with the >4Gb Windows file tests - I need to do loose tests first..
From Jonathan Tan to Everyone:  08:05 PM
I compared multiple promisor remotes and CDN offloading here: https://public-inbox.org/git/20190506191901.212221-1-jonathantanmy@google.com/
And here: https://public-inbox.org/git/20190219201022.237430-1-jonathantanmy@google.com/
From Emily Shaffer to Everyone:  08:08 PM
I think I've been able to drum up reviews on stuff from the standup
From Emily Shaffer to Everyone:  08:17 PM
I like the idea of using #git-devel more actively than we do now, although last time I mentioned that in front of other Git contributors I got pretty well shouted down :)
preventing duplication of labor also seems like a good job for a bug tracker
From Philip Oakley to Everyone:  08:18 PM
Monday is better
From Emily Shaffer to Everyone:  08:19 PM
sgtm
From Jeff King to Everyone:  08:19 PM
In my experience we have less of a problem with duplication of labor, and more of a problem with not enough labor.
From Jonathan Nieder to Everyone:  08:19 PM
thanks, dscho
From Emily Shaffer to Everyone:  08:19 PM
er,that's google for "yes i like it"
From Taylor Blau to Everyone:  08:19 PM
Don’t forget to call jrn, too.
From Jonathan Nieder to Everyone:  08:19 PM
:)
From Emily Shaffer to Everyone:  08:20 PM
agree with dscho, what is it? can you overview
From Pratik Karki(prertik) to Everyone:  08:20 PM
https://planet.gnome.org/
From Emily Shaffer to Everyone:  08:20 PM
oh, i'd aggregate my personal blog to that
From Matheus Tavares to Everyone:  08:20 PM
another example: https://planet.debian.org/
From Jonathan Nieder to Everyone:  08:20 PM
you export an RSS feed with what you want to get aggregated
and then the Planet software consumes / reposts that
From Emily Shaffer to Everyone:  08:22 PM
that sounds really cool to learn a little more about folks socially/personally
+1
From Jonathan Nieder to Everyone:  08:23 PM
We could open an issue at https://gitlab.com/git-scm/blog/issues and organize that way
From Garima Singh to Everyone:  08:23 PM
good idea
From Jonathan Nieder to Everyone:  08:24 PM
thanks, it's a nice idea
From Garima Singh to Everyone:  08:24 PM
thanks everyone!
From Jonathan Tan to Everyone:  08:24 PM
thanks everyone
From Emily Shaffer to Everyone:  08:24 PM
thanks very much for organizing it all, this was cool to attend
From Pratik Karki(prertik) to Everyone:  08:24 PM
Thanks. Happy Saturday.
From Pratik Karki(prertik) to Everyone:  08:27 PM
+1
From Emily Shaffer to Everyone:  08:29 PM
the notes in the doc are pretty much verbatim he-said she-said, right?
From Jonathan Tan to Everyone:  08:31 PM
sounds good
From Jonathan Nieder to Everyone:  08:32 PM
(https://public-inbox.org/git/BF65DE67-42F0-4BFD-A2EF-E12DA48B8B4F@jramsay.com.au/T/#t)
From Emily Shaffer to Everyone:  08:32 PM
thanks everyone, great to associate faces
o/
From Jonathan Nieder to Everyone:  08:32 PM
ciao all
From Pratik Karki(prertik) to Everyone:  08:33 PM
Thanks all!
[a]Compressed list of manual topics (by my count):
- How to make non-patch contributions (reviewing others' patches, providing help in the ML, etc)
- How to make non-code contributions (doc, translation, etc)
- How to use the mailing list - reading, replying, mutt configs?
- History of submodules - caveats, gotchas, design direction, etc
- Packfiles - history, intent, howto
- Index file 101
[b]I opened issues for some of these yesterday in the GitLab project you linked.