Git Rev News: Edition 38 (April 18th, 2018)
Welcome to the 38th 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 2018.
- rebase -i: offer to recreate merge commits (written by Jacob Keller)
Johannes Schindelin has worked to replace
git rebase, which has many known flaws, by a new
--recreate-merges, which aims to replace the functionality of
--preserve-merges in a way that fixes the known issues.
When the patch series was sent to the list, Sergey Organov brought up
--recreate-merges is still (true to its name) recreating the
merges from scratch, thus losing any content they might have contained,
such as fixes.
He pointed to a strategy for cherry-picking the merge commit. Others chimed in to state that they share concerns and would like to see the ability to preserve the merge resolutions properly.
Johannes replied that this does not make sense because the cherry-pick
solution does not work when you drop or re-order commits. The goal of
--recreate-merges is to allow the same level of freedom as with
regular interactive rebases. Using the
strategy of just cherry-picking the merge commit will
result in any changes before that merge being dropped.
Junio Hamano, the Git maintainer, chimed in that Johannes was correct,
if for example the side branch you are merging dropped a commit during
the rebase, you absolutely do not want to use the simple
git cherry-pick -m1
Sergey replied that he had only intended the use of cherry-pick as an explanation facility, and that a proper strategy would be required to actually implement and allow history editing.
Some discussion about
--preserve-merges and compatibility with scripts
(i.e. should we change or fix it? – or should we deprecate it?)
- Rebasing merges: a journey to the ultimate solution (Road Clear) (written by Jacob Keller)
After the discussions in the above article Sergey posted an
outline of a potential method for actually rebasing a merge (as
opposed to recreating it from scratch) which used a process of
git cherry-pick -mN of the merge onto each topic branch being
merged, and then merging the result.
Igor Djordjevic and Jacob Keller, alias Jake, chimed in hoping to prove by example that the solution could work. Johannes replied that he was skeptical and pointed out possible flaws.
A few examples were tried, but it was proven that the original algorithm did not work, as dropped commits could end up being replayed into the merge commits, turning them into “evil” merges.
Further suggestions to the strategy were proposed and tested, ultimately resulting in Sergey proposing a fix to his method, specifically using the original merge commit as a merge base during the final step.
Some discussion occurred about
merge -s ours and how any rebasing
strategy should avoid attempting to understand the semantics of the
Phillip Wood suggested an alternative idea for keeping the merge conflicts by merging the changes from each rebased branch back into the parent merge branch. This was immediately understood by Johannes and suggested as a potential for the default implementation.
Sergey replied that he thinks the solution produces the same result as his updated strategy, at least when none of the strategies produce any conflicts.
Johannes suggested that he was open to using Phillip’s strategy but was worried about syntax. He did not want to introduce inconsistent behavior of the new “merge” command.
Despite Sergey believing that the two strategies were equivalent, Johannes was not convinced.
Discussion about the syntax for the new “rebase a merge” todo command
continued. Johannes landed on the idea of adding an option
-R to the
merge command line to indicate that it was rebasing a merge (vs creating
a new merge).
Phillip suggested that we re-use “pick” but thought it might be a bit
too magical. He then adjoined that it is indeed too magical, and is
--preserve-merges mistake all over again. He suggested
it was a shame to have merge mean both recreate a merge and rebase a
merge, but didn’t have a good answer.
Igor suggested that “pick” was more natural, and that we should extend
it to properly support picking merge commits in a way that was not
Johannes stated he did not like the extension of “pick” because it makes it harder to understand which lines are actually merges and which are not.
Johannes replied that Sergey’s strategy is actually worse than Phillip’s from a functional point of view, because it has potential to produce conflicts multiple times. The discussion continued and became heated, with both Johannes and Sergey unable to reach a consensus.
Discussion about “pick” vs
merge -R continued, with Igor and Sergey
stating that they thought extending “pick” syntax would be better than
merge -R syntax.
Some further discussion about backward compatibility of the todo list format and of options for it followed.
Kaartic Sivaraam sent a patch to the mailing list that fixed
git branch -l output when an interactive rebase is performed
and when the interactive rebase was started from a remote branch
or when HEAD was detached.
Eric Sunshine replied to Kaartic that
git branch -l is a
--create-reflog not for
--list, and suggested some
small improvements along with adding a couple of new tests.
Kaartic then wondered why
git branch -l prints a list of branch
-l is not a shorthand for
--list, and agreed to
implement Eric’s suggestions.
Jeff King, alias Peff, replied to Kaartic that
-l just sets the
“reflog” variable to 1, and then, as the command defaults to
when there is no other command line option, the branch names are
printed, which just ignores the “reflog” variable.
Peff also explained that
-l is probably never used in practice as it
is the default to create a reflog, so it’s “historical and quite
-l is a shortcut for
--create-reflog and not for
Eric then suggested making
-l mean sometimes
--list, but Peff didn’t like that and suggested instead to
either complaining when
-l is used in list mode or deprecating and
-l first and then maybe after a significant amount of time
repurposing it as a shortcut for
Then Eric replied to Kaartic with a few small additional suggestions and with a patch that adds the new tests which Eric had previously suggested.
Meanwhile Kaartic agreed to Peff’s suggestions. Those suggestions
were discussed a bit more by Jacob Keller, alias Jake, and Junio
Hamano, the Git maintainer, who agreed to the plan to deprecate
-l, then to drop it, and eventually re-establish it as shortcut
Peff then sent a patch series doing all that. The series was reviewed by Eric and Jake.
Kaartic reworked his original patch to improve
git branch --list
output and sent to the mailing list a
second version of it
along with Eric’s patch adding new tests.
Peff’s patch series has been merged into the ‘next’ branch and Kaartic’s patch series will probably also be merged there, too.
Developer Spotlight: Jiang Xin
Who are you and what do you do?
I am a Chinese, live in Beijing, China. Almost at the same time when Linus wrote the first line of code for Git, I started to work as a self-employed open source consultant. At that time, I didn’t know Git yet, so I chose SVN and Redmine as the main products to start my consultant career. After working as a Git consultant for Huawei for one year, I accepted Huawei’s offer in Dec, 2015.
What would you name your most important contribution to Git?
As a developer, the most important contribution to Git is interactive
git clean. One day a guy (reader of my book) lost his work by running
git clean -fand asked me for help. I wanted to do something, so I sent patches to Git, and it became this feature:
git clean --interactive.
As a Huaweier, I also have contributed some fixes for corner cases I met at work:
As a Chinese, the most important work I have done is that I wrote a book on Git, and the book was published in 2011. As soon as I received the first copy of my book, I sent one to Junio. :) I open-sourced the book in https://github.com/gotgit/gotgit, and you can read it from http://www.worldhello.net/gotgit/. Meanwhile, I wrote an e-book for GitHub: http://www.worldhello.net/gotgithub; it is also written in Chinese, but did not publish it because I feel it is hard to track changes of the GitHub UI, and the book might become obsolete very quickly.
I became Git l10n coordinator to help Junio for l10n management in early 2012. Now there are 11 fully supported language packs for Git, and this work is very valuable for those who are not good at English.
What are you doing on the Git project these days, and why?
Now I am working in Huawei for the internal Git platform with multiple data centers distributed in China. There are many cool features I am working on. For example: Git central workflow and Git-CDN.
Git central workflow is something like Gerrit. No forking before sending pull request, no special git hook on client side, no “Change-ID” in the commit message, and we use pull request for review. We also developed a client side program named “git-mm” to help our users to manage multiple git modules, or just a single git repository.
Git-CDN is a reverse proxy for Git. I wrote a program named
git-upload-pack-proxyto handle data syncing and data caching across different data centers.
We have also some enhancements on Git, and I wish I can contribute them back to Git one day.
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?
When I was developing the Git reverse proxy, I found the Git protocol is a bit complicated and not very efficient. For example, if a client wants to fetch a single branch, the server still needs to send thousands of references as refs-advertisement. We can improve it.
(EDIT: Stefan Beller pointed out that there would be great improvements in protocol v2, a simpler and less wasteful protocol, which had already been merged from the bw/protocol-v2 topic branch to Git next branch.)
If you could remove something from Git without worrying about backwards compatibility, what would it be?
git-gc, I think. If a repository is as big as 10 GB,
git-gcwill be quite slow. If we designed a new storage model for Git without garbage collection, it would be great.
What is your favorite Git-related tool/library, outside of Git itself?
- Library: libgit2
- L10n: Emacs po-mode
- Git RPC: Gitaly
- Git v2.17.0, v2.17.0-rc2, v2.17.0-rc1, and v2.16.3
- Git for Windows 2.17.0 and 2.16.3
- GitHub Enterprise 2.13.1, 2.12.9, 2.11.15, 2.10.21, 2.13.0, 2.12.8, 2.11.14, and 2.10.20
- GitLab 10.5.5, 10.6, 10.6.1, 10.6.2, Security Release 10.6.3, 10.5.7, and 10.4.7, and 10.6.4
- Bitbucket Server 5.9
- Github Desktop 1.1.1
- GitKraken 3.5.0 and 3.5.1
- libgit2 0.27.0-rc3 and 0.27.0
- Gerrit Code Review 2.5.1
- The videos of the 2018 Git Merge talks have been released.
- Git developers contacted by an advanced alien species, a 1st of April announcement.
- New YouTube Channel GerritForge TV, dedicating events and tutorials to the Gerrit Code Review community.
- Git 2.17 is now available – a look at some of the most interesting new features from the last few versions of Git
- Generating a changelog based on merge commits by Andries
- git log – the Good Parts, based on author’s material from the book Learn Git the Hard Way
- 14 tips and tools to resolve conflicts with Git by Nicola Paolucci, from 2015
- There is a series of articles by Joe Neeman about mathematical underpinnings of Pijul distributed version control system, which is based like Darcs on theory of merges. Pijul was mentioned in Git Rev News #9 and #24:
- Release Notes using Fastlane by Tom Wilson, about how to deal with Android version code that is dynamically generated based on git revision history
- Reimplementing “git clone” in Haskell from the bottom up by Stefan Saasen - March 2013
- Putting the I back in IDE: Towards a Github Explorer - what Git and Github could look like with truly deep editor integration
- Merging Done Right: Semantic Merge, about Plastic SCM’s SemanticMerge paid tool, presented on Git Merge 2018 (event covered by Git Rev News Edition 37)
Git tools and sites
- Guiffy, the advanced cross-platform diff/merge
- gitworkflow repository is a documentation repository for gitworkflows: see How the Creators of Git do Branching, by Raman Gupta (mentioned in Git Rev News Edition 27)
- git-immersion repository for git-immersion excercise guided tour
- commit -> public-inbox link helper script by Johannes Schindelin was posted on git mailing list
- kaizenboard - GitHub issues on a Kanban board
This edition of Git Rev News was curated by Christian Couder <email@example.com>, Jakub Narębski <firstname.lastname@example.org>, Markus Jansen <email@example.com> and Gabriel Alcaras <firstname.lastname@example.org> with help from Jiang Xin, Jacob Keller, Luca Milanesio, Sergey Organov and Kaartic Sivaraam.