{"thread":{"id":"63290","subject":"Collaborative community interview for Git's 20th anniversary","startedAt":"2025-04-14T12:31:44Z","lastAt":"2025-05-02T05:38:06Z","messageCount":6,"participants":["Kaartic Sivaraam","Luca Milanesio","Lucas Seiki Oshiro","Elijah Newren"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"516093","messageId":"85ea4aa0-c595-4f0b-a2ac-d0113aca464a@gmail.com","threadId":"63290","inReplyTo":null,"subject":"Collaborative community interview for Git's 20th anniversary","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2025-04-14T12:31:14Z","receivedAt":"2025-04-14T12:31:44Z","isPatch":false,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"Hello all,\n\nAs part of the Git's 20th year anniversary, we from the Git Rev News \nteam are thinking of doing a community interview where we would share a \nlist of questions that we've prepared and we would like to welcome \nanswers from anyone in the community for them. We could gather the \nanswers for them upto a particular time (like 25/April or so) and begin \ncurating the answers into a special interview for this month's edition. \nThe questions are below. Feel free to respond with your answers to this \nmail thread. Let me know if I've missed to include any particularly \ncompelling question.\n\n   - What's your favorite Git trick or workflow that you wish more people\n     knew about?\n\n   - What was your worst Git disaster, and how did you recover from it?\n\n   - If you could go back in time and change one design decision in Git,\n     what would it be?\n\n   - Which Git feature or improvement over the past 20 years do you think\n     had the biggest impact on your workflow?\n\n   - What Git problem that existed 10 years ago has been most\n     successfully solved?\n\n   - Which Git commands or workflows do you think are still misunderstood\n     or underutilized today?\n\n   - What's one Git based project, tool, or extension you think deserves\n     more recognition from the community?\n\n   - What Git feature or capability surprised you most when you first\n     discovered it?\n\n   - What's your boldest prediction about how version control might look\n     in another 20 years?\n\n\nLooking forward to see interesting answers. :-)\n\n--\nSivaraam for the Git Rev News team.\n\n"},{"id":"516095","messageId":"04A328E9-1146-4D4A-84E7-456FFEB66A5A@gmail.com","threadId":"63290","inReplyTo":"85ea4aa0-c595-4f0b-a2ac-d0113aca464a@gmail.com","subject":"Re: Collaborative community interview for Git's 20th anniversary","fromName":"Luca Milanesio","fromEmail":"luca.milanesio@gmail.com","sentAt":"2025-04-14T12:37:27Z","receivedAt":"2025-04-14T12:37:40Z","isPatch":false,"sender":{"key":"luca.milanesio@gmail.com","avatar":"https://gravatar.com/avatar/64e45570bb8baaba9a566592150e6c7341a300e314501a944cb95b0bc1380f49?d=mp&s=160"},"body":"\n\n> On 14 Apr 2025, at 13:31, Kaartic Sivaraam <kaartic.sivaraam@gmail.com> wrote:\n> \n> Hello all,\n> \n> As part of the Git's 20th year anniversary, we from the Git Rev News team are thinking of doing a community interview where we would share a list of questions that we've prepared and we would like to welcome answers from anyone in the community for them. We could gather the answers for them upto a particular time (like 25/April or so) and begin curating the answers into a special interview for this month's edition. The questions are below. Feel free to respond with your answers to this mail thread. Let me know if I've missed to include any particularly compelling question.\n> \n>  - What's your favorite Git trick or workflow that you wish more people\n>    knew about?\n> \n>  - What was your worst Git disaster, and how did you recover from it?\n\nI suspect to be one of the worst offenders :-)\nhttps://www.infoq.com/news/2013/11/use-the-force/\n\nThankfully I was using Gerrit Code Review and the replication plugin: the refs were not lost but just rewind and we could reset all the correct SHA1s for all of them.\n\n> \n>  - If you could go back in time and change one design decision in Git,\n>    what would it be?\n\nUse SHA-256 straight away, as it was published 24 years ago and already existed at the time Git was designed.\n\nLuca.\n\n> \n>  - Which Git feature or improvement over the past 20 years do you think\n>    had the biggest impact on your workflow?\n> \n>  - What Git problem that existed 10 years ago has been most\n>    successfully solved?\n> \n>  - Which Git commands or workflows do you think are still misunderstood\n>    or underutilized today?\n> \n>  - What's one Git based project, tool, or extension you think deserves\n>    more recognition from the community?\n> \n>  - What Git feature or capability surprised you most when you first\n>    discovered it?\n> \n>  - What's your boldest prediction about how version control might look\n>    in another 20 years?\n> \n> \n> Looking forward to see interesting answers. :-)\n> \n> --\n> Sivaraam for the Git Rev News team.\n> \n> \n\n"},{"id":"516103","messageId":"AE27429C-97B1-4226-8F30-5B635A050498@gmail.com","threadId":"63290","inReplyTo":"85ea4aa0-c595-4f0b-a2ac-d0113aca464a@gmail.com","subject":"Re: Collaborative community interview for Git's 20th anniversary","fromName":"Lucas Seiki Oshiro","fromEmail":"lucasseikioshiro@gmail.com","sentAt":"2025-04-14T15:04:55Z","receivedAt":"2025-04-14T15:05:11Z","isPatch":false,"sender":{"key":"lucasseikioshiro@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12701580?v=4"},"body":"Hi!\n\n>  - What's your favorite Git trick or workflow that you wish more people\n>    knew about?\n\nEverything related to code archaeology (git grep, `git log -S/-G`, \n`git log -L` and `git bisect`). Those are my primary debugging tools and\nevery time I explained them to other people they find them mind-blowing\nand useful. And they also started loving it :-)\n\n>  - What was your worst Git disaster, and how did you recover from it?\n\nI don't remember something that I did, but I remember a simple and\ncurious disaster: our deploy workflows stopped working, only leaving a\nmessage like \"cannot fetch ambiguous reference `master`\". I decided to\ninvestigate what happened and I found out that someone by mistake (I\ndon't know how) created a tag called `master` and pushed it to GitHub.\nBy the time we used the `master` branch for deploy, and the workflows\ndidn't know if they should use the `master` branch or tag. GitHub didn't\nhave a feature for deleting tags through the web interface, so we\nthought \"what should we do?\".\n\nThe solution was to run `git push origin :refs/tags/master`. Simple, but\nnot obvious. A classic case where it only required a screw to be turned,\nbut all the hard work was to find which screw should be turned.\n\n>  - If you could go back in time and change one design decision in Git,\n>    what would it be?\n\nPerhaps writing a more abstract CLI. After studying Git a little more\ndeeper it makes sense for me, but I would group the functionality into\nmore high-level subcommands and would make the flags and options more\nconsistent across the subcommands.\n\nFor example, Docker CLI have all the image operations under\n`docker image` and all the network operations under `docker network`.\nIf I want to delete an image, I use `docker image rm`, if I want to\ndelete a network, I use `docker network rm`, and so on. I would make\nGit CLI work based on that idea, for example:\n\n- git branch add my_branch\n- git branch delete my_branch\n- git branch list\n- git remote add my_remote ...\n- git remote delete my_remote\n- git remote list\n- git tag add my_tag\n- git tag delete my_tag\n- git tag list\n\nWith some shorter alias, just like Docker has `docker rmi` and\n`docker rm`.\n\n>  - Which Git feature or improvement over the past 20 years do you think\n>    had the biggest impact on your workflow?\n\nSorry, but I can't answer. I am from a generation that started\nprogramming when Git was already the de facto VCS so I can't compare a\nworld that has it with a world that doesn't have.\n\n>  - What Git problem that existed 10 years ago has been most\n>    successfully solved?\n\nSorry again, but 10 years ago I was only starting to use Git and when I\nstarted to use more complex features they already were there.\n\n>  - Which Git commands or workflows do you think are still misunderstood\n>    or underutilized today?\n\nI think squash merges and submodules are really misunderstood, yet they\nare the opposite of being underutilized. Sadly I saw several people\nusing them in daily basis, based on the wrong idea of what they are and\nthen using them incorrectly.\n\nWhat I think it is underutilized is the full power of commits of being\na good source of documentation and good resource for, again, performing\ncode archaeology that may help understanding what the code does and\ndebugging it. Several developers treat the commits as just checkpoints.\n\n>  - What's one Git based project, tool, or extension you think deserves\n>    more recognition from the community?\n\nPerhaps it would be better to leave this question for other less known\ntools. But if want a answer, I think:\n\n- Delta (https://github.com/dandavison/delta) is a really cool to format\n  the diff-related outputs;\n\n- Kworkflow (https://kworkflow.org/) is a powerful tool for contributing\n  to the Linux kernel source code (I should also try it for contributing\n  to the Git source code);\n\n- Merge drivers in general. diff3 works in most cases but it is only\n  based on pure diffs, without performing deeper operations based on the\n  file format they are merging.\n\n>  - What Git feature or capability surprised you most when you first\n>    discovered it?\n\nAs you may have noticed, I'm really a fan of Git archaeology :-), so I\nwould say all that I mentioned in the first answer. But my favorite is\nstill bisect. It's an egg of Columbus and I everyone that I have shown\nit to was equally amazed by it!\n\n>  - What's your boldest prediction about how version control might look\n>    in another 20 years?\n\nI still see Git as the dominant VCS in the future, but I think more\nGit-based VCSs (like jujutsu) will arise. Just like we have today\nprogramming languages built on top of the stack of the other languages\n(e.g. Clojure, Kotlin and Scala on JVM, TypeScript on JS), networking\nprotocols written on top of other protocols (e.g. QUIC on UDP, gRPC\non HTTP) and so on.\n\nThe Git core is simple, flexible, transparent and powerful and there's\nstill room for people using it directly in several creative ways. Once\nI saw a project using it as a backend for a NoSQL database\n(https://www.kenneth-truyers.net/2016/10/13/git-nosql-database/), who\nknows how many use cases we still have for it.\n\n> Sivaraam for the Git Rev News team.\n\nIt was a pleasure to answer that!\n\nPS: can I share your questions in local Git communities?\n\n"},{"id":"516641","messageId":"CABPp-BH2yH4iJ28Bo7Q=uryu68LLk7a0Tvb2SzAbAiHK8QpRug@mail.gmail.com","threadId":"63290","inReplyTo":"85ea4aa0-c595-4f0b-a2ac-d0113aca464a@gmail.com","subject":"Re: Collaborative community interview for Git's 20th anniversary","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2025-04-23T22:41:59Z","receivedAt":"2025-04-23T22:42:11Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Mon, Apr 14, 2025 at 5:31 AM Kaartic Sivaraam\n<kaartic.sivaraam@gmail.com> wrote:\n>\n> Hello all,\n>\n> As part of the Git's 20th year anniversary, we from the Git Rev News\n> team are thinking of doing a community interview where we would share a\n> list of questions that we've prepared and we would like to welcome\n> answers from anyone in the community for them. We could gather the\n> answers for them upto a particular time (like 25/April or so) and begin\n> curating the answers into a special interview for this month's edition.\n> The questions are below. Feel free to respond with your answers to this\n> mail thread. Let me know if I've missed to include any particularly\n> compelling question.\n>\n>    - What's your favorite Git trick or workflow that you wish more people\n>      knew about?\n\nrange-diff.  The ideas behind it ought to be the basis for code\nreview, IMO.  Commits should be the unit of review (including commit\nmessages as a fundamental and primary thing to be reviewed), and a\nseries of commits should be the unit of merging.  I dislike most code\nreview tools, because they get one or both of those things wrong.\nGetting both of those things right naturally leads to range-diff or\nsomething like it being a very important part of the workflow, at a\nminimum for detecting which commits in a series are unmodified and\nwhich have been updated and need to be further reviewed.\n\n>    - What was your worst Git disaster, and how did you recover from it?\n\nMy worst Git-related disaster wasn't with Git directly but with our\nGit hosting software we used at a prior job, Gerrit.  'twas a\n\"startup\" that was still forming good practices.  We had both a\nproduction and a staging instance.  The staging instance was seeded\nwith a copy of production data so we could do scale testing...but that\nseeding process was a multi-step manual thing; it hadn't been\nautomated.  One step was, as best I recall, \"drop database gerrit\",\nfollowed by loading the production copy of the mysql database (this\nwas long before NoteDB arrived).  And as many readers probably have\nguessed by now, I was on the wrong host one day when I ran that\ncommand.\n\nThe actual git repositories were still intact, but the review metadata\nwas toast.  Luckily, we had a backup from about 7 hours earlier, so we\ncould recover the older review metadata and with some hackery fix the\nmysql metadata mismatch with the newer repository contents.  And since\nGerrit emailed folks comments from reviews as they were posted, we\ncould tell people to look at their emails for the pieces we couldn't\nrecover.\n\nIt was a really long night trying to fix things.  Some folks told me\nthey thought I was going to throw up just looking at me.  But I\nlearned how wonderful it was to be at a company with blameless\npost-mortems, and I appreciated the many folks who reached out to tell\nme stories of mistakes they had made.  They were more interested in\nwhether we learned our lesson and put processes into place to prevent\nrepeats, and I definitely did both.\n\nI did, of course, also get some good-natured ribbing, such as people\nsaying I got to play the part of little Bobby Tables once (see\nhttps://xkcd.com/327/ if you don't know that reference).  I kindly\nreminded them that I didn't drop a table -- I dropped the whole\ndatabase (plus, it wasn't injection, it was just running a command in\nthe wrong location) .  Also, one of my colleagues helpfully modified\nthe prompt on production to be red and bold, \"This is PROD Gerrit\",\nand the prompt on staging to be green, \"This is staging Gerrit; it's\nokay to drop database here!\"  The prompts ended up not mattering since\nI automated the process, and made sure the process just error'ed out\nif run on prod instead of staging.  But the prompt persisted for many\nyears anyway, because I thought it was a hilarious way to poke fun at\nmy blunder.\n\n>    - If you could go back in time and change one design decision in Git,\n>      what would it be?\n\nThe index.  For a few reasons.\n\n1) Performance.\n\n1a) The index is pervasive throughout the codebase, and while it works\ngreat for small repositories, it means that many operations are O(size\nof repository) instead of O(size of changes).  sparse indices help,\nbut the code has to be carefully audited for sparse indices to work\nwith each codepath, and even then there tends to be a fallback of\njust-load-everything-anyway because the data structure doesn't lend\nnicely to just expanding a little more.\n\n1b) An under-appreciated aspect of the performance improvements that\ncame from our new merge strategy, merge-ort, were due to dispensing\nwith the index as the primary data structure.  The index had two\nproblems:\n1b-1) first of all it meant loading every path in the repository,\nwhich would have prevented ort's optimization to avoid recursing into\nsubtrees when unnecessary (an optimization that often made merges e.g.\n50x faster).  Sparse indices didn't exist back then, but even if they\nhad we would have had to complicate them significantly in order to\nhave their sparseness be determined by renames and the intersection of\nmodified paths on the two sides of history instead of having\nsparseness determined by user-defined path rules; I think that'd have\nbeen much more complicated than just dispensing with the index as the\ndata structure, but we didn't even have sparse indices back then\nanyway.\n1b-2) Second, the use of the index as done in the old merge strategy,\nmerge-recursive, resulted in O(N^2) behavior since entries (including\nconflicted higher order stages) had to be inserted in sorted order.\nDeleting entries didn't have the same O(N^2) problem due to some\ntricks to queue the deletion for later, but attempting to do the same\nfor insertions was far from straightforward and I believe would have\nrequired making some other data structure primary and then forming the\nindex at the end. (Note that the primary data structure used, whatever\nit is, cannot just have a list of things to insert, it also needs to\nbe checked for various properties intermingled with insertions...and\nthose sometimes relied on the fact that the index was sorted for quick\nlookups.)\n\n(Note that a tree-structured index rather than a linear index would\nresolve these problems.  But retrofitting the entire codebase is\nprobably never going to happen...)\n\n2) Cognitive Complexity.\n\nThe funny thing is, although I say this, I use the index all the time.\nI use `git add -p` a lot.  I very much need to slice and dice my\nchanges into different commits, and tend to have dirty changes that I\ndon't want pushed.\n\nBut slicing and dicing before things are committed, as opposed to\nbeing able to slice and dice after, is a choice that adds a lot of\ncomplexity to the user interface and does so even for users who aren't\ninterested in slicing and dicing commits.  We don't have a\nsufficiently flexible set of tooling for slicing and dicing commits\nafter-the-fact within git to switch to a post-commit-slice-and-dice\nworkflow even today, but I suspect that some of the ideas from JJ\nwould or could be much better than the methods I use today in git to\nslice and dice commits.\n\n>    - Which Git feature or improvement over the past 20 years do you think\n>      had the biggest impact on your workflow?\n\nSpeed.\n\nBeing able to instantly switch branches (in smaller repos, sure, but\nCVS and SVN couldn't pull it off even in small repos) was a game\nchanger.\n\n>    - What Git problem that existed 10 years ago has been most\n>      successfully solved?\n\nMerging and rebasing with lots of renames (and generally merging\nwithout a worktree or index).  I'm obviously a bit biased on this\npoint, but that doesn't mean I'm wrong.  ;-)  It used to be awful and\nworks great now.\n\nRelatedly, merging without a worktree or index was problematic; you\nhad to either use an alternative merge strategy with limited\ncapabilities, or use something other than git (e.g. libgit2).  But now\ngit handles it well with its default merge strategy.\n\n>    - Which Git commands or workflows do you think are still misunderstood\n>      or underutilized today?\n\nrange-diff is very under-utilized, but I already discussed that above.\n\n>    - What's one Git based project, tool, or extension you think deserves\n>      more recognition from the community?\n>\n>    - What Git feature or capability surprised you most when you first\n>      discovered it?\n>\n>    - What's your boldest prediction about how version control might look\n>      in another 20 years?\n\nI'm more interested in what storms might be brewing along that path,\nand what we might be able to do to avoid them.  In particular, some\nquestions and observations in that area:\n\n  * With monorepos growing ever larger, do we have\nhard-to-workaround-or-fix design decisions that pose scaling\nchallenges?  e.g.\n    * the index data structure\n    * per-directory .gitignore files, per-directory .gitattribute files, etc.\n  * ...or do the prominent Git forges have hard-to-workaround-or-fix\ndesign decisions that'll give Git a reputation for not scaling?  e.g.\n    * making refs/pull/NNN/merge a public ref and excessively\nimplicitly updating it\n  * Will we face a crisis of interest?  e.g.\n    * git is currently written in C.  Even if that's not a liability\nalready, coupled with \"decades\" I think it is.  Young developers\nprobably don't want to learn C, and older ones who already know C may\nworry about C becoming a Fortran or Cobol.\n    * Companies employing git developers think \"git already won\" and\nredeploy those engineers on other problems\n  * Will the combination of issues above result in folks who want\nimprovements deciding their best bet is not improving git but in\ncreating/funding an alternative?  Will that snowball?\n\nTo me, the entry of new projects like jj and sapling suggest the above\nare real concerns already rather than just theoretical.  Both projects\nhave compelling things that git lacks.  I like the friendly\ncompetition, and the jj and sapling developers are awesome to talk to\nat Git Merge conferences.  But there is a risk that this friendly\ncompetition mirrors that of Git and Mercurial from years past, and\nthat Git at some future point down the road ends up on the other side\nof that history and gets largely displaced by the alternatives.  I'd\nrather not see that happen, but I sometimes wonder if we're taking\nenough measures to avoid marching towards such an outcome.\n"},{"id":"517083","messageId":"e41dd273-faa8-4b23-bbf6-dc7b0d512f08@gmail.com","threadId":"63290","inReplyTo":"CABPp-BH2yH4iJ28Bo7Q=uryu68LLk7a0Tvb2SzAbAiHK8QpRug@mail.gmail.com","subject":"Re: Collaborative community interview for Git's 20th anniversary","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2025-05-02T05:35:29Z","receivedAt":"2025-05-02T05:35:38Z","isPatch":false,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"Hi Luca, Lucas and Elijah,\n\nThank you very much for your interesting and detailed answers! Apologies \nfor the delay in getting back to you on this. I've finally curated your \nanswers into this month's draft. You can check the same here:\n\n \nhttps://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-122.md#community-interview\n\nKindly let me know in case of any corrections.\n\nThank you again for taking the time to give us your answers for this \nanniversary special edition :-)\n\nLucas,\n\n> PS: can I share your questions in local Git communities?\n\nI know its a bit too late to answer this. But feel free to do so if you \nstill want to. We can possibly include interesting responses in the next \nedition :-)\n\n--\nSivaraam for the Git Rev News team.\n"},{"id":"517084","messageId":"b37ce020-a3f8-4666-ae7a-99301a175a9a@gmail.com","threadId":"63290","inReplyTo":"e41dd273-faa8-4b23-bbf6-dc7b0d512f08@gmail.com","subject":"Re: Collaborative community interview for Git's 20th anniversary","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2025-05-02T05:37:57Z","receivedAt":"2025-05-02T05:38:06Z","isPatch":false,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"Excuse the noise. Include Luca and Lucas in the thread.\n\nOn 02/05/25 11:05, Kaartic Sivaraam wrote:\n> Hi Luca, Lucas and Elijah,\n> \n> Thank you very much for your interesting and detailed answers! Apologies \n> for the delay in getting back to you on this. I've finally curated your \n> answers into this month's draft. You can check the same here:\n> \n> \n> https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-122.md#community-interview\n> \n> Kindly let me know in case of any corrections.\n> \n> Thank you again for taking the time to give us your answers for this \n> anniversary special edition :-)\n> \n> Lucas,\n> \n>> PS: can I share your questions in local Git communities?\n> \n> I know its a bit too late to answer this. But feel free to do so if you \n> still want to. We can possibly include interesting responses in the next \n> edition :-)\n> \n> -- \n> Sivaraam for the Git Rev News team.\n"}]}