Welcome to the 74th edition of Git Rev News, a digest of all things Git. For our goals, the archives, the way we work, and how to contribute or to subscribe, see the Git Rev News page on git.github.io.

This edition covers what happened during the month of March 2021.

• --no-edit not respected after conflict

  Renato Botelho explained in an email to the mailing list that while he was reverting multiple commits using the --no-edit option, there was a conflict he resolved using git mergetool. After that though, the revert was not respecting the --no-edit option anymore for the next commits, so for each of them an editor was opened for him to review the commit messages.

  After brian m. carlson replied to him asking for the set of commands he used or a reproduction test case, Renato provided a test case which shows that indeed after git revert --continue the --no-edit option, that was provided in the initial git revert --no-edit commit1 commit2 ... commitN command, doesn't seem to be taken into account anymore.

  Elijah Newren thanked Renato, confirmed he could reproduce the issue and said he started working on a patch that fixed the issue as well as a similar one he had found. The next day though Elijah replied to himself saying the issue turned out to be messier than expected.

  He provided tables showing that the behavior (launching an editor or not) could depend on a number of factors: the command (revert or cherry-pick), the use of a terminal or not, before or after a conflict, which option (--edit, --no-edit or no option) had been passed. The tables also showed that Elijah had some doubts in some cases.

  Elijah for example was not sure what should be done after a conflict when neither --edit nor --no-edit had been specified and when there was no terminal. It was not clear if an editor should be launched as it was likely to fail if there was no terminal.

  Junio Hamano, the Git maintainer, replied to Elijah saying that when there is a conflict and when reverting (instead of cherry-picking), the default (that is, --no-edit is not provided) should be to give the user a chance to explain the conflict resolution or the reason for reverting in the commit message. If there is no terminal though, the process is likely automated and launching an editor might fail the operation for no good reason.

  Elijah then thanked Junio, sent a proper patch to the mailing list fixing the issue and asked Renato to give it a try. Renato replied that the patch worked indeed and thanked Elijah.

  Philip Oakley and Phillip Wood first replied to Elijah's patch, which was quite complex, with only minor comments. Elijah and Junio both replied to their comments. Then Elijah sent a version 2 of his patch that only included typo fixes and comment clarifications to address Philip's and Phillip's suggestions.

  Johannes Schindelin, alias Dscho, replied to this new version of the patch. He first said, as a tangent, that we should move away from the "Unix shell script heritage", especially what he called "the awful let's write out one file per setting strategy". He would like the project to use the JSON or the INI (like Git's own config files) format instead. He recognized that it might not be an easy switch though, as some users might unfortunately rely too much on such implementation details.

  Dscho also made a number of small code suggestions. One was about how the variable encoding of the edit related options is checked. Another one was to get rid of an assert() statement that Elijah's patch introduced. While Elijah agreed with the first one, he disagreed about the second, which started a small discussion about the value of assert() between Elijah, Junio and Dscho, with Ævar Arnfjörð Bjarmason chiming in. Elijah eventually suggested replacing the assert() statements using a new BUG_ON() macro.

  About Dscho's tangent that we should stop writing one file per setting and use a standard format instead, Elijah said he was glad talking about this because it generates a number of issues. Some of these issues are related to the different control structures and code duplication for different operations (like git cherry-pick and git rebase) because of the differences in writing the settings.

  Another issue is some wasted time in the sequencer (which is used by both git cherry-pick and git rebase). There is unnecessary process forking and a lot of useless disk writing (to update the index and the working directory but also to write all the individual control files). This started a sub-thread where Dscho, Phillip Wood, Junio and Elijah discussed if it was actually necessary to often write many small files to disk. The conclusion seemed to be that we would need to check if some hooks are configured or not, so that if they are not, we can avoid writing a lot between each commit which is processed. Dscho said that "for example, if no pre-commit hook was installed that needs to be run, there was no need to update the worktree nor HEAD until the rebase is done".

  Meanwhile Elijah sent a version 3 of his patch that took into account all the suggestions Dscho had made, including the removal of the assert() statement. Dscho gave his "Reviewed-by:" and the patch has since been merged into the 'master' branch.

• Who are you and what do you do?

  I'm Yann, and for the last few years I've been working on the Blade/Shadow "stream a Gaming PC" service, and currently looking for the next adventure.

• What would you name your most important contribution to Git?

  I can't say that one particular thing stands out by itself. In volume I certainly contributed more to "third-party" tools: Cogito initially, then StGit (which I'm happy to see has recently received more activity and a 1.0 release), then more recently git-reintegrate. In git.git, I've mostly contributed small patches here and there when it itched too much, and a number of bug reports and suggestions.

• What are you doing on the Git project these days, and why?

  I've been mostly dormant there lately, and I've been a happy user all that time, both in dayjob and in personnal projects. To me that tells a lot on the maturity of the project.

  I've started to feel a new itch regarding git rebase -i, when iterative work requires to go back-and-forth between patches before finishing the rebase (something StGit did quite well, and possibly something most users don't need). I only posted a PoC and some ideas a couple of weeks ago, and that's likely to be my next venture into Git if time allows.

• If you could get a team of expert developers to work full time on something in Git for a full year, what would it be?

  On my first contact with Git shortly after Linus published his first version, one thing stood out for me as non-intuitive after using all those former tools: the "record only the content and not by which operation we got there" motto, which leaves to git diff the work of reconstructing the "which operation" part. Yet, soon after it struck me as probably the most brilliant aspect in Git's design.

  Today there are a handful of such operations that Git can detect, and then use when merging to make things easier: essentially renames and copies. Yet, so many other high-level operations can be made on code, and are not easy enough to merge: code restructuring inducing reindents (think Python) and symbol renaming are the first that come to mind.

  This probably should be done as language-specific diff/merge tools, but those tools would likely want to share a common core. Providing such support would likely help many projects, and enable smoother workflows.

• If you could remove something from Git without worrying about backwards compatibility, what would it be?

  The current git rebase syntax, which feels so counter-intuitive today.

• What is your favorite Git-related tool/library, outside of Git itself?

  Recently the tool that has helped me most is git-reintegrate, it simplifies so much the iterative integration process with WiP branches. It still has a couple of rough edges, but as long as you don't use submodules and don't have to hand over the integration task to others too often, it runs really smoothly.

• Git 2.31.1,
• Git for Windows 2.31.1(1)
• GitHub Enterprise 3.0.5, 2.22.11, 2.21.19, 3.0.4, 2.22.10, 2.21.18, 3.0.3, 2.22.9, 2.21.17
• GitLab 13.11.1, 13.11, 13.10.3, 13.9.6, and 13.8.8, 13.10.2, 13.10.1, 13.9.5, and 13.8.7
• Bitbucket Server 7.12
• Gerrit Code Review 3.3.3, 3.2.8, 3.1.13
• GitKraken 7.5.5, 7.5.4, 7.5.3
• GitHub Desktop 2.7.2, 2.7.1, 2.7.0
• TortoiseGit 2.12.0

Events

• GitHub is announcing the Global Maintainer Summit on June 8--9th.

Various

• Technology internships meet open source in Outreachy on GitLab's blog is about recent Outreachy interns working on Git.
• Enhanced Productivity with Git in Visual Studio (in upcoming version 16.10).

Light reading

• Optimizing git’s merge machinery, #3 by Elijah Newren on Palantir Blog.
• A look under the hood: how branches work in Git by Tobias Günther on The Overflow -- the Stack Overflow blog.
• Experiment on your code freely with Git worktree by Seth Kenlon (Red Hat) on Opensource.com.
• 5 commands to level-up your Git game: git whatchanged, git stash, git worktree, git cherry-pick and managing $HOME with Git, by Seth Kenlon (Red Hat) on Opensource.com.
• A practical guide to using the git stash command by Ramakrishna Pattnaik on Opensource.com.
• Scanning for secrets in Git repositories automatically, by Jake Edge on LWN.net.
• How we ship code faster and safer with feature flags by Alberto Gimeno on GitHub Blog.
  • Feature flags were one of solutions to hiding partial features in trunk based development, one of the patterns for managing source code branches in Martin Fowler's article of the same name, covered in Git Rev News Edition #63 and mentioned in #73.
• How to Set Up Continuous Integration for a Monorepo Using Buildkite by Subash Adhikari on freeCodeCamp.
• How to Use Git and Git Workflows -- a Practical Guide by John Mosesman on freeCodeCamp.
• Improving shell workflows with fzf by Sebastian Jambor. The fzf tool was mentioned alongside git-fuzzy (that uses it) in Git Rev News Edition #64.
• Git email flow vs GitHub flow: Comparing the GitHub and GitLab pull request workflow to the Git built-in email workflow, by Martijn Braam (2020).

Git tools and sites

• posh-git is a PowerShell module which provides Git/PowerShell integration. It also provides tab completion support for common Git commands, branch names, paths, and more.

This edition of Git Rev News was curated by Christian Couder <christian.couder@gmail.com>, Jakub Narębski <jnareb@gmail.com>, Markus Jansen <mja@jansen-preisler.de> and Kaartic Sivaraam <kaartic.sivaraam@gmail.com> with help from Yann Dirson, Elijah Newren and Sven Strickroth.