On Thu, 26 Sep 2019, Eric Wong wrote: > James Ramsay <james@xxxxxxxxxxxxxx> 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@xxxxxxxxx/ 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@xxxxxxxxx/ 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@xxxxxxxxxx/ 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@xxxxxxxxxxxxxxx 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@xxxxxxxxx/ 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@xxxxxxxxxxxxxx/ 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@xxxxxxxxxxxxxxxxxxx/ (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@xxxxxxxxxx/ And here: https://public-inbox.org/git/20190219201022.237430-1-jonathantanmy@xxxxxxxxxx/ 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@xxxxxxxxxxxxxx/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.
