Hi! > - What's your favorite Git trick or workflow that you wish more people > knew about? 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 :-) > - What was your worst Git disaster, and how did you recover from it? 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. > - If you could go back in time and change one design decision in Git, > what would it be? 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`. > - Which Git feature or improvement over the past 20 years do you think > had the biggest impact on your workflow? 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. > - What Git problem that existed 10 years ago has been most > successfully solved? 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. > - Which Git commands or workflows do you think are still misunderstood > or underutilized today? I think squash merges and submodules 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. > - What's one Git based project, tool, or extension you think deserves > more recognition from the community? Perhaps it would be better to leave this question for other less known tools. But if want a 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? 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. But my favorite is still bisect. It's an egg of Columbus and I 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? I still see Git as the dominant VCS in the future, but I think more Git-based VCSs (like 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 (https://www.kenneth-truyers.net/2016/10/13/git-nosql-database/), who knows how many use cases we still have for it. > Sivaraam for the Git Rev News team. It was a pleasure to answer that! PS: can I share your questions in local Git communities?
