rn-122: include answers from various community members

Author: sivaraam

rev_news/drafts/edition-122.md

@@ -189,11 +189,343 @@ This edition covers what happened during the months of March and April 2025.
 ## Community interview
 
 _Editor note: For Git's 20th anniversary, we are doing an exclusive collaborative
-community interview and curating answers from various community members. Also,
-there's a short Q&A with our zealous, inclusive and tireless maintainer that
-follows below._
+community interview and curating answers of various community members. Also,
+there's a [short Q&A](#short-qa-with-our-maintainer-junio-c-hamano) with our
+zealous, inclusive and tireless maintainer that follows below._
+
+
+- **What's your favorite Git trick or workflow that you wish more people
+  knew about?**
+
+  [_Thalia Rose_][thalia]: For rebase-heavy workflows, `git range-diff` is incredibly
+  useful. To compare against upstream, use `git range-diff @{u}...@`,
+  and to compare against the previous HEAD, use `git range-diff @{1}...@`.
+
+  [_Lucas Seiki Oshiro_][seiki]: Everything related to code archaeology
+  (`git grep`, `git log -S/-G`, `git log -L` and `git bisect`). Those are
+  my primary debugging tools and every time I explained them to other
+  people they find them mind-blowing and useful.
+  And they also started loving it :-)
+
+  [_Elijah Newren_][elijah]: [`range-diff`][range-diff]. The ideas behind
+  it ought to be the basis for code review, IMO.  Commits should be the
+  unit of review (including commit messages as a fundamental and primary
+  thing to be reviewed), and a series of commits should be the unit of
+  merging.  I dislike most code review tools, because they get one or
+  both of those things wrong. Getting both of those things right naturally
+  leads to `range-diff` or something like it being a very important part
+  of the workflow, at a minimum for detecting which commits in a series
+  are unmodified and which have been updated and need to be further reviewed.
+
+
+- **What was your worst Git disaster, and how did you recover from it?**
+
+  [_Thalia Rose_][thalia]: When I was first starting with Git, I wanted to make a repo
+  to preserve my first coding project when I was twelve, a bunch of VBS scripts.
+  I had assumed that Git maintained file modification timestamps, so I deleted
+  the originals because they were now redundant. I now no longer know exactly
+  when I wrote them and have been careful about timestamps ever since.
+
+  [_Luca Milanesio_][luca]: I suspect to be one of the worst offenders :-) [ [ref](https://www.infoq.com/news/2013/11/use-the-force) ]
+
+  Thankfully 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.
+
+  [_Lucas Seiki Oshiro_][seiki]: I don't remember something that I did,
+  but I remember a simple and curious disaster: our deploy workflows
+  stopped working, only leaving a message like "cannot fetch
+  ambiguous reference `master`". I decided to investigate what happened
+  and I found out that someone by mistake (I don't know how) created a
+  tag called `master` and pushed it to GitHub. By the time we used the
+  `master` branch for deploy, and the workflows didn't know if they
+  should use the `master` branch or tag. GitHub didn't have a feature
+  for deleting tags through the web interface, so we thought
+  "what should we do?".
+
+  The solution was to run `git push origin :refs/tags/master`. Simple,
+  but not obvious. A classic case where it only required a screw to be
+  turned, but all the hard work was to find which screw should be turned.
+
+  [_Elijah Newren_][elijah]:
+  My worst Git-related disaster wasn't with Git directly but with our
+  Git hosting software we used at a prior job, Gerrit.  'twas a
+  "startup" that was still forming good practices.  We had both a
+  production and a staging instance.  The staging instance was seeded
+  with a copy of production data so we could do scale testing...but that
+  seeding process was a multi-step manual thing; it hadn't been
+  automated.  One step was, as best I recall, "drop database gerrit",
+  followed by loading the production copy of the mysql database (this
+  was long before [NoteDB][notedb] arrived).  And as many readers
+  probably have guessed by now, I was on the wrong host one day when
+  I ran that command.
+
+  The actual git repositories were still intact, but the review metadata
+  was toast.  Luckily, we had a backup from about 7 hours earlier, so we
+  could recover the older review metadata and with some hackery fix the
+  mysql metadata mismatch with the newer repository contents.  And since
+  Gerrit emailed folks comments from reviews as they were posted, we
+  could tell people to look at their emails for the pieces we couldn't
+  recover.
+
+  It was a really long night trying to fix things.  Some folks told me
+  they thought I was going to throw up just looking at me.  But I
+  learned how wonderful it was to be at a company with blameless
+  post-mortems, and I appreciated the many folks who reached out to tell
+  me stories of mistakes they had made.  They were more interested in
+  whether we learned our lesson and put processes into place to prevent
+  repeats, and I definitely did both.
+
+  I did, of course, also get some good-natured ribbing, such as people
+  saying I got to play the part of little Bobby Tables once (see
+  [this xkcd comic][bobby-tables] if you don't know that reference).
+  I kindly reminded them that I didn't drop a table -- I dropped the whole
+  database (plus, it wasn't injection, it was just running a command in
+  the wrong location).  Also, one of my colleagues helpfully modified
+  the prompt on production to be red and bold, "This is PROD Gerrit",
+  and the prompt on staging to be green, "This is staging Gerrit; it's
+  okay to drop database here!"  The prompts ended up not mattering since
+  I automated the process, and made sure the process just error'ed out
+  if run on prod instead of staging.  But the prompt persisted for many
+  years anyway, because I thought it was a hilarious way to poke fun at
+  my blunder.
+
+
+- **If you could go back in time and change one design decision in Git,
+  what would it be?**
+
+  [_Luca Milanesio_][luca]: Use SHA-256 straight away, as it was
+  published 24 years ago and already existed at the time Git was designed.
+
+  [_Lucas Seiki Oshiro_][seiki]: Perhaps writing a more abstract CLI. After
+  studying Git a little more deeper it makes sense for me, but I would group
+  the functionality into more high-level subcommands and would make the flags
+  and options more consistent across the subcommands.
+
+  For example, Docker CLI have all the image operations under
+  `docker image` and all the network operations under `docker network`.
+  If I want to delete an image, I use `docker image rm`, if I want to
+  delete a network, I use `docker network rm`, and so on. I would make
+  Git CLI work based on that idea, for example:
+
+    - `git branch add my_branch`
+    - `git branch delete my_branch`
+    - `git branch list`
+    - `git remote add my_remote ...`
+    - `git remote delete my_remote`
+    - `git remote list`
+    - `git tag add my_tag`
+    - `git tag delete my_tag`
+    - `git tag list`
+
+  With some shorter alias, just like Docker has `docker rmi` and
+  `docker rm`.
+
+  [_Elijah Newren_][elijah]: The index.  For a few reasons.
+
+  1. Performance.
+     1. The index is pervasive throughout the codebase, and while it works
+     great for small repositories, it means that many operations are O(size
+     of repository) instead of O(size of changes).  [sparse indices][sparse-index]
+     help, but the code has to be carefully audited for sparse indices to
+     work with each codepath, and even then there tends to be a fallback of
+     just-load-everything-anyway because the data structure doesn't lend
+     nicely to just expanding a little more.
+
+     2. An under-appreciated aspect of the performance improvements that
+     came from our new merge strategy, [`merge-ort`][merge-ort], were due
+     to dispensing with the index as the primary data structure.  The index
+     had two problems:
+        1. first of all it meant loading every path in the repository,
+        which would have prevented ort's optimization to avoid recursing into
+        subtrees when unnecessary (an optimization that often made merges e.g.
+        50x faster).  Sparse indices didn't exist back then, but even if they
+        had we would have had to complicate them significantly in order to
+        have their sparseness be determined by renames and the intersection of
+        modified paths on the two sides of history instead of having
+        sparseness determined by user-defined path rules; I think that'd have
+        been much more complicated than just dispensing with the index as the
+        data structure, but we didn't even have sparse indices back then
+        anyway.
+
+        2. Second, the use of the index as done in the old merge strategy,
+        `merge-recursive`, resulted in O(N^2) behavior since entries (including
+        conflicted higher order stages) had to be inserted in sorted order.
+        Deleting entries didn't have the same O(N^2) problem due to some
+        tricks to queue the deletion for later, but attempting to do the same
+        for insertions was far from straightforward and I believe would have
+        required making some other data structure primary and then forming the
+        index at the end. (Note that the primary data structure used, whatever
+        it is, cannot just have a list of things to insert, it also needs to
+        be checked for various properties intermingled with insertions...and
+        those sometimes relied on the fact that the index was sorted for quick
+        lookups.) <br/><br />
+        (Note that a tree-structured index rather than a linear index would
+        resolve these problems.  But retrofitting the entire codebase is
+        probably never going to happen...)
+
+    2. Cognitive Complexity. <br/>The funny thing is, although I say this,
+    I use the index all the time. I use `git add -p` a lot.  I very much
+    need to slice and dice my changes into different commits, and tend to
+    have dirty changes that I don't want pushed. <br /> <br />
+    But slicing and dicing before things are committed, as opposed to
+    being able to slice and dice after, is a choice that adds a lot of
+    complexity to the user interface and does so even for users who aren't
+    interested in slicing and dicing commits.  We don't have a
+    sufficiently flexible set of tooling for slicing and dicing commits
+    after-the-fact within git to switch to a post-commit-slice-and-dice
+    workflow even today, but I suspect that some of the ideas from [JJ][jujutsu]
+    would or could be much better than the methods I use today in git to
+    slice and dice commits.
+
+
+- **Which Git feature or improvement over the past 20 years do you think
+  had the biggest impact on your workflow?**
+
+  [_Lucas Seiki Oshiro_][seiki]: Sorry, but I can't answer. I am from a
+  generation that started programming when Git was already the de facto
+  VCS so I can't compare a world that has it with a world that doesn't have.
+
+  [_Elijah Newren_][elijah]: Speed.
+
+  Being able to instantly switch branches (in smaller repos, sure, but
+  CVS and SVN couldn't pull it off even in small repos) was a game
+  changer.
+
+
+- **What Git problem that existed 10 years ago has been most
+  successfully solved?**
+
+  [_Lucas Seiki Oshiro_][seiki]: Sorry again, but 10 years ago I was only
+  starting to use Git and when I started to use more complex features they
+  already were there.
+
+  [_Elijah Newren_][elijah]: Merging and rebasing with lots of renames
+  (and generally merging without a worktree or index).  I'm obviously
+  a bit biased on this point, but that doesn't mean I'm wrong.  ;-)
+  It used to be awful and works great now.
+
+  Relatedly, merging without a worktree or index was problematic; you
+  had to either use an alternative merge strategy with limited
+  capabilities, or use something other than git (e.g. [libgit2][libgit2]).
+  But now git handles it well with its default merge strategy.
+
+
+- **Which Git commands or workflows do you think are still misunderstood
+  or underutilized today?**
+
+  [_Lucas Seiki Oshiro_][seiki]: I think [squash merges][squash-merge] and
+  [submodules][submodule] are really misunderstood, yet they are the opposite
+  of being underutilized. Sadly I saw several people using them in daily basis,
+  based on the wrong idea of what they are and then using them incorrectly.
+
+
+  What I think it is underutilized is the full power of commits of being
+  a good source of documentation and good resource for, again, performing
+  code archaeology that may help understanding what the code does and
+  debugging it. Several developers treat the commits as just checkpoints.
+
+  [_Elijah Newren_][elijah]: `range-diff` is very under-utilized, but I
+  already discussed that above.
+
+
+- **What's one Git based project, tool, or extension you think deserves
+  more recognition from the community?**
+
+  [_Lucas Seiki Oshiro_][seiki]: Perhaps it would be better to leave this
+  question for other less known tools. But if you want an answer, I think:
+
+   - [Delta](https://github.com/dandavison/delta) is a really cool to
+   format the diff-related outputs;
+
+   - [Kworkflow](https://kworkflow.org/) is a powerful tool for
+   contributing to the Linux kernel source code (I should also
+   try it for contributing to the Git source code);
+
+    - Merge drivers in general. `diff3` works in most cases but it is
+    only based on pure diffs, without performing deeper operations based
+    on the file format they are merging.
+
+
+- **What Git feature or capability surprised you most when you first
+  discovered it?**
+
+  [_Lucas Seiki Oshiro_][seiki]:  As you may have noticed, I'm really
+  a fan of Git archaeology :-), so I would say all that I mentioned
+  in the first answer (i.e., `git grep`, `git log -S/-G`, `git log -L`
+  and `git bisect`). But my favorite is still [bisect][bisect].
+  It's an egg of Columbus and everyone that I have shown it to
+  was equally amazed by it!
+
+
+- **What's your boldest prediction about how version control might look
+  in another 20 years?**
+
+  [_Lucas Seiki Oshiro_][seiki]: I still see Git as the dominant VCS
+  in the future, but I think more Git-based VCSs (like [Jujutsu][jujutsu]
+  will arise. Just like we have today programming languages built on top
+  of the stack of the other languages (e.g. Clojure, Kotlin and Scala on
+  JVM, TypeScript on JS), networking protocols written on top of other
+  protocols (e.g. QUIC on UDP, gRPC on HTTP) and so on.
+
+  The Git core is simple, flexible, transparent and powerful and there's
+  still room for people using it directly in several creative ways. Once
+  I saw [a project using it as a backend for a NoSQL database][git-backend-nosql],
+  who knows how many use cases we still have for it.
+
+  [_Elijah Newren_][elijah]: I'm more interested in what storms might be
+  brewing along that path, and what we might be able to do to avoid them.
+  In particular, some questions and observations in that area:
+
+  * With monorepos growing ever larger, do we have hard-to-workaround-or-fix
+    design decisions that pose scaling challenges?  e.g.
+      * the index data structure
+      * per-directory .gitignore files, per-directory .gitattribute files, etc.
+  * ...or do the prominent Git forges have hard-to-workaround-or-fix
+    design decisions that'll give Git a reputation for not scaling?  e.g.
+     * making refs/pull/NNN/merge a public ref and excessively
+       implicitly updating it
+  * Will we face a crisis of interest?  e.g.
+     * `git` is currently written in C.  Even if that's not a liability
+       already, coupled with "decades" I think it is.  Young developers
+       probably don't want to learn C, and older ones who already know C
+       may worry about C becoming a Fortran or Cobol.
+     * Companies employing Git developers think "git already won" and
+       redeploy those engineers on other problems
+  * Will the combination of issues above result in folks who want improvements
+    deciding their best bet is not improving Git but in creating/funding
+    an alternative? Will that snowball?
+
+  <br />
+  To me, the entry of new projects like [JJ][jujutsu] and [sapling][sapling]
+  suggest the above are real concerns already rather than just theoretical.
+  Both projects have compelling things that git lacks.  I like the friendly
+  competition, and the JJ and sapling developers are awesome to talk to
+  at Git Merge conferences.  But there is a risk that this friendly
+  competition mirrors that of Git and Mercurial from years past, and
+  that Git at some future point down the road ends up on the other side
+  of that history and gets largely displaced by the alternatives.  I'd
+  rather not see that happen, but I sometimes wonder if we're taking
+  enough measures to avoid marching towards such an outcome.
+
+
+[thalia]: https://discord.com/channels/1042895022950994071/1361310935427584213/1361316878819131452
+[luca]: https://public-inbox.org/git/[email protected]/
+[seiki]: https://public-inbox.org/git/[email protected]/
+[elijah]: https://public-inbox.org/git/CABPp-BH2yH4iJ28Bo7Q=uryu68LLk7a0Tvb2SzAbAiHK8QpRug@mail.gmail.com/
+[squash-merge]: https://git-scm.com/docs/git-merge#Documentation/git-merge.txt---squash
+[submodule]: https://git-scm.com/docs/git-submodule
+[bisect]: https://git-scm.com/docs/git-bisect
+[range-diff]: https://git-scm.com/docs/git-range-diff
+[sparse-index]: https://git-scm.com/docs/sparse-index
+[merge-ort]: https://git-scm.com/docs/merge-strategies#Documentation/merge-strategies.txt-ort
+[jujutsu]: https://github.com/jj-vcs/jj?tab=readme-ov-file#introduction
+[git-backend-nosql]: https://www.kenneth-truyers.net/2016/10/13/git-nosql-database
+[notedb]: https://www.gerritcodereview.com/notedb.html
+[bobby-tables]: https://xkcd.com/327/
+[libgit2]: https://libgit2.org/
+[sapling]: https://sapling-scm.com/
 
-TODO
 
 ### Short Q&A with our maintainer, Junio C Hamano