| title | layout | date | author | categories | navbar | |
|---|---|---|---|---|---|---|
Git Rev News Edition 37 (March 21st, 2018) |
default |
2018-03-21 12:06:51 +0100 |
chriscool |
|
false |
Welcome to the 37th 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 from the month of February 2018 up to the Git Merge conference on March 7th and 8th 2018.
- Git Merge 2018 conference
Another exciting Git Merge happened this year, this time in the lovely city of Barcelona in Catalonia, Spain. Surrounded by crazy skaters, two days full of Git happened, with a couple of add-on events on both ends.
- A few days before the conference Jeff King, alias Peff, posted a Git / Software Freedom Conservancy status report (2018) and a git-scm.com update.
- The usual Git Contributor Summit was held in parallel to the workshop day. Alex Vandiver provided a nice write-up of the event, which felt more focused on concrete projects than in the last years. Be sure to read through the replies that add more information, still.
- In his Opening Session of the Git Merge, Brett Smith from the Software Freedom Conservancy invited everyone to have a moment of silence in memory of Shawn Pearce (see edition 36).
- Plastic SCM's Semantic Merge was not only presented in a talk, but made available as a bot called "mergedroid" that applies the same merge conflict resolution to Pull Requests on GitHub.
- A big theme this year was to apply Git to files other than source code:
- Stephen Hathaway detailed how designers use Git to work on visual design.
- William Chia described how GitLab uses Git to collaborate on documents.
- The xltrail product makes it possible to use Git to manage Excel files (this was demo'ed between talks by Felix Zumstein).
Hilco Wijbenga explained to the mailing list that sometimes when a rebase fails because of rebase/merge conflicts, he would like to "rewind" the rebase to an earlier commit and restart from there. This would be useful for example when the earlier commit is the right commit where a conflict should be fixed.
His current solution is to abort the rebase and start over with
git rebase --interactive and then "edit" commits. This doesn't work
well though when a lot of conflicts have already been resolved before
the earlier commit he would "rewind" to, because, when the original
rebase is aborted, all the work that already went into resolving
conflicts is lost.
Brian Carlson replied to Hilco that in this case he unstages all the
changes from the index, then makes the change that should have gone
into the earlier commit, uses git commit --fixup (or --squash),
and then restages the rest of the changes and continues with the
rebase. He can then use git rebase -i --autosquash afterwards to
insert the fixup commit into the right place.
Hilco replied to Brian that he ends up doing that too, but it doesn't work well when the fixup commit is not easy to move to the right place.
Jeff King, alias Peff, replied to Hilco's original email saying that
git rerere should help reapplying conflict resolutions. He also
suggested to "simply pick the resolved state at each step" when
repeating the rebase, using for example git tag failed to remember
the failed attempt, and then git checkout failed~4 -- to pick
conflict resolutions from the failed attempt.
Peff alternatively suggested "rewinding" using git reset --hard and
then, after fixing the earlier commit, using git cherry-pick to
cherry-pick commits with conflict resolutions from the failed attempt.
Johannes Schindelin, alias Dscho, also replied to Hilco. Dscho first suggested basically the same workflow as Peff's alternative suggestion.
He then suggested an alternative strategy which consists in copying parts of the $GIT_DIR/rebase-merge/done file to the beginning of the $GIT_DIR/rebase-merge/git-rebase-todo file, instead of cherry-picking commits. This copying would in effect "rewind" the original rebase.
Dscho mentioned that a new interactive rebase subcommand could be created to facilitate using this strategy. The new subcommand could "make use of the fact that the interactive rebase accumulates mappings between the original commits and the rewritten ones" in the $GIT_DIR/rebase-merge/rewritten-list file.
Phillip Wood also replied to Hilco's first email suggesting something
similar as Dscho's alternative strategy. Phillip suggested using
git log --pretty="pick %h %s" <earlier_commit>.. followed by
git rebase --edit-todo to edit the git-rebase-todo file, and then
git checkout <earlier_commit> to rewind.
In a subsequent email replying to himself Dscho elaborated on a
possible new subcommand. He proposed
git rebase --replay-latest-commits 3 and a slightly different way to
copy commits to the git-rebase-todo file so that it contains commits
with resolved merge conflicts.
Phillip replied to Dscho that it's the reason why he actually uses
git log --pretty="pick %h %s" <earlier_commit>.. to get the lines
that should be pasted at the beginning of the git-rebase-todo file.
Peff replied to Dscho suggesting a "general form" of Dscho's proposal
that would be called git rebase --rewind and that could "undo" the
prior rebase command whatever it is.
Jacob Keller, alias Jake, chimed in to support Peff's suggestion and Hilco's wish of "a --rewind that simply tracks the point of each history and can reset back to each".
- Git v2.17.0-rc0
- Git for Windows v2.17.0-rc0
- Github Enterprise 2.9.23, 2.10.18, 2.10.19, 2.11.12, 2.11.13, 2.12.6, 2.12.7
- Gitlab 10.5, 10.5.1, 10.5.2, 10.5.3, 10.4.5, 10.3.8, 10.5.4
- Github Desktop 1.1.0
- GitKraken 3.4.0, 3.4.1
- libgit2 0.26.1, 0.26.2, 0.26.3
- LibGit2Sharp 0.24.1
Various
- Building Windows: 4 million commits, 10 million work items. Microsoft talks on Ars Technica about some of the work it’s done to move Windows development to VSTS (Visual Studio Team Services), the company's source control, item tracking, integration and testing system (Git and GVFS is a part of it).
- GitHub introduces support for committing together with co-authors, via "Co-authored-by:" trailers at the end of the commit message.
- Git's history simplification is explained nicely on Microsoft's documentation site.
Light reading
- Code Review Isn't Evil. Security Through Obscurity Is. by Sydney Li, Nate Cardozo, and Jeremy Malcolm
- Nobody's just reading your code by Stephen Malina, about guiding exploration
- That Thing About Commit Messages by Zarah Dominguez
- High-level Problems with Git and How to Fix Them by Gregory Szorc
Git tools and sites
- The GVFS effort (scaling Git to support massive repositories) starts developing MacOS support.
- Michael Haggerty announced a new tool called git-sizer to "compute various size-related metrics for your Git repository".
- Gitkube is a tool for building and deploying docker images on Kubernetes using
git push. - nbdime –- diffing and merging of Jupyter Notebooks
- Easily back up your Github repositories and/or issues with Github::Backup
- rpm-ostree update system, based on OSTree / libostree, which is described as "Git for operating systems" -- where atomic versions are managed in a Git repository, used by Project Atomic from Red Hat and the Fedora Project
- git-hooks by Benjamin Meyer is a tool for managing project, user, and global git hooks
- The Git® Notes for Professionals book, compiled from Stack Overflow Documentation dump (sunsetted project)
This edition of Git Rev News was curated by Christian Couder <[email protected]>, Jakub Narębski <[email protected]>, Markus Jansen <[email protected]> and Gabriel Alcaras <[email protected]> with help from Johannes Schindelin and Patrick Steinhardt.