Welcome to the 96th 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 months of January and February 2023.
Bug?: ORIG_HEAD incorrect after reset during git-rebase -i
Erik Cervin Edin sent an email to the mailing list with steps to reproduce a behavior that he didn’t like. The steps consisted of an interactive rebase during which a commit was edited and a reset which was performed while editing the commit.
After editing, git rebase --continue finished the rebase. But then
Erik expected ORIG_HEAD to point to the tip
of the rebased branch before the rebase, while instead it pointed to
the HEAD before the reset.
ORIG_HEAD is one of the pseudo-references that some Git commands
use, like FETCH_HEAD, MERGE_HEAD, and a few others.
Phillip Wood replied to Erik saying that it was expected that git
reset would change ORIG_HEAD to HEAD just before it was
performed. He suggested using the reflog with something like
branch-name@{1} where branch-name is the branch being
rebased and the @{1} part indicates the previous entry in the
reflog for the branch.
Erik replied that he knew about the reflog but just expected
ORIG_HEAD to be reset to .git/rebase-merge/orig-head at the end of
the rebase. .git/rebase-merge/orig-head is an internal file that
stores the tip of the branch before a rebase operation.
Philippe Blain replied to Erik that he just hit the same bug. He also said that he was confused by the rebase documentation and supplied the series of commands he used to get hit.
Phillip Wood replied to both Erik and Philippe Blain that if we
changed the behavior to make ORIG_HEAD point to the tip of the
branch before it was rebased, some people might not be happy as they
might expect git reset to have changed ORIG_HEAD. Other people
might expect on the contrary that ORIG_HEAD was always set to the
tip of the branch before the rebase when the rebase stopped, which
would mean that git rebase --continue would always need to make
sure ORIG_HEAD fulfilled that expectation.
Phillip said he thought the situation was confusing and he didn’t see a way to make it clearer.
Philippe Blain agreed that some people might rely on the current behavior and said he would send documentation updates to make things clearer.
He then sent
a patch series
consisting of small changes to the documentation of a number of
commands: cherry-pick, merge, rebase and reset, as well as
to the documentation about Git revisions.
Junio Hamano, the Git maintainer, commented on some wordings, which after short discussions led Philippe to send a version 2 of his series with very few changes.
This version was accepted and later merged into the master branch.
Various
Light reading
squash command of the interactive rebase.The notebook also mentions
Pangeo Forge (like Conda Forge, but for data),
Intake (lightweight package for finding, investigating, loading and disseminating data), and
Flat Data - formerly GitHub OCTO
(to bring working sets of data to your repositories, based on the
“Git scraping” approach pioneered by Simon Willison
(mentioned in Git Rev News Edition #68)).
See also Git Rev News #82,
which mentions tools for version controlling database schemas, version controlling queries,
data versioning, etc. – all taken from articles on DoltHub Blog.
Easy watching
Git tools and sites
git refresh, git pushback and git done.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 Bruno Brito.