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 personal 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.
Events
Various
Light reading
git whatchanged, git stash, git worktree, git cherry-pick and
managing $HOME with Git,
by Seth Kenlon (Red Hat) on Opensource.com.git stash command
by Ramakrishna Pattnaik on Opensource.com.Git tools and sites
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.