Welcome to the fifth 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 June 2015.
As part of a school project, Antoine DELAITE, Remi GALAN ALFONSO, Remi LESPINET, Guillaume PAGES and Louis-Alexandre STUBER, from Ensimag, contributed to Git. As a warm-up, they implemented a am.threeWay configuration variable to have git am use -3 by default (will be in Git 2.5). Some patch series are being polished to allow git bisect to use an arbitrary pair of terms instead of good and bad, an improved management of list of addresses and aliases in the --to, --cc and --bcc options of git send-email, a more verbose output for git status when ran during a rebase -i session, and a safety feature for git rebase to avoid dropping lines by mistake in the todo-list.
Both of the Git project Google Summer of Code
students, Paul Tan and Karthik Nayak have passed the midterm evaluation and are doing well. Karthik is working on
unifying the implementations of git branch -l, git tag -l, and git for-each-ref
and Paul is working on porting git-pull from shell to C
and on porting git-am from shell to C too.
git worktree command (written by Eric Sunshine)The linked-worktree facility allows multiple working directories to share a
single repository, with (typically) a different branch checked out in each
worktree. Introduced more than half a year ago to provide integrated and
platform-agnostic support for similar functionality long supplied by the
Unix-only and somewhat fragile contrib/git-new-workdir script,
linked-worktrees recently migrated to the master branch, but is not
yet part of any release.
As originally implemented, creation of linked-worktrees was accomplished
via git checkout --to <path> <branch>, and cleanup of leftover
administrative files after manual deletion of <path> was done with git
prune --worktrees. However, a recent unrelated change to git prune led
to a
discussion
that concluded that worktree-related maintenance functionality didn’t
belong in git prune.
Consequently, Nguyễn Thái Ngọc Duy submitted a
patch
which introduces a new git worktree command, and relocates git prune
--worktrees functionality to git worktree prune.
Eric Sunshine then further fleshed out git worktree with a
patch
which relocates git checkout --to functionality to git worktree new.
A lengthy
discussion
ensued, which eventually led to a second version, consisting of 23
patches,
and which names the command git worktree add, rather than git worktree
new, and gives the documentation some needed attention.
Aside from documentation updates, several other user-visible changes arrive
with the second version. For instance, while preparing worktree-creation
functionality for the move from git checkout to git worktree, Eric
discovered and fixed a bug where git checkout --to <path> HEAD~1 would
instead incorrectly checkout HEAD~2 at <path>.
The second version also introduces convenience enhancements. In
particular, the <branch> in git worktree add <path> <branch>, is now
optional. When omitted, a new branch is created automatically based upon
<path>, as if -b $(basename <path>) had been provided (where
-b <new-branch> creates a new branch). For example, given
git worktree add ../hotfix, a new branch named hotfix is created and
checked out into new worktree ../hotfix, as if
git worktree -b hotfix ../hotfix HEAD had been specified.
Finally, the question was
raised
whether git checkout --ignore-other-worktrees should be retired and git
checkout --force overloaded to subsume its duties, however, Junio was not
thrilled
by the idea.
Max Kirillov proposed a patch to warn when a conversion from a character set to another character set could not happen because iconv has not been compiled into Git.
Iconv is one of the few C libraries that people can compile either in or out of Git. Most of the time though they choose to compile it in, because it makes it possible to convert text, like commit messages, between character sets, as long, of course, as the requested character sets are installed on the system.
For example when one uses git-am to create a commit from a patch sent in an email, git-mailinfo is called to extract from the email the information needed to create the commit. When doing that git-mailinfo also by default tries to use iconv to convert the commit message, the author name and the author email from the email encoding to UTF-8.
Junio Hamano, the Git maintainer, replied to Max’s patch with:
I actually am OK if the user gets exactly the same warning between the two cases:
iconv failed to convert in the real
reencode_string_len()we compiled out
iconv()and real conversion was asked.and this patch is about the latter; I do not think it is reasonable to give noise only for the latter but not for the former.
and later Junio explained:
After all, if you had to convert between UTF-8 and ISO-2022-JP, the latter of which your system does not support, whether you use iconv-disabled build of Git or iconv-enabled build of Git, we pass the bytestream through, right? Your patch gives warning for the former (which is a good starting point if we want to warn “user expected them to be converted, we didn’t” case) but does not do anything to the latter, even though users of the iconv-disabled build is more likely to be aware of the potential issue (and are likely to be willing to accept that) than the ones with iconv-enabled build that runs on a system that cannot convert the specific encoding.
Hopefully Max will send an updated patch that will take Junio’s suggestion into account.
Eric Raible reported the following:
Upon returning from a vacation, I was looking at what people had been up to, and discovered on merge in which a colleague had resolved a merge incorrectly. It turns out that he has pushed many merges over the past year which had conflicts in my code, and now I don’t trust any of them.
So naturally I want to check each of them for correctness.
I know about “git log -p -cc SHA – path”, but it really doesn’t show just the conflicts so there’s just too much noise in that output.
I use kdiff3 to resolve conflicts, so I’m looking for a way to visualize these already-resolved conflicts with that tool.
Johannes Schindelin, aka Dscho, suggested the following shell script to recreate the merge conflicts and then compare the resulting commit with the existing one:
mergecommit=$1
# probably should verify that the working directory is clean, yadda yadda
# recreate merge conflicts on an unnamed branch (Git speak: detached HEAD)
git checkout $mergecommit^
git merge $mergecommit^2 ||
die "This merge did not have any problem!"
# compare to the actual resolution as per the merge commit
git diff $mergecommit
Michael J Gruber replied to Dscho that, as we often get this type of request, it might be a good idea to better support the above.
Junio Hamano then pointed to
a patch series from last September by Thomas Rast
that implements a new --remerge-diff option for git log to show
what a conflict resolution changed. Unfortunately, though the feature
looks promising at least to Michael, it looks like some more work is
needed to properly integrate this feature into Git.
Dscho, when he originally replied to Eric, also suggested the following command to list all the merge commits created by one colleague in the current branch:
git rev-list --author="My Colleague" --parents HEAD |
sed -n 's/ .* .*//p'
And Michael noticed that using the --merges option would be better
than using sed to filter the merge commits. Something like the
following could do it:
git rev-list --author="My Colleague" --parents --merges HEAD
Right now git log supports the following date related options:
--date-order
--author-date-order
--date=(relative|local|default|iso|iso-strict|rfc|short|raw)
But H.Merijn Brand noticed two problems with those options.
First he found that dates shown by git log --date=local do not
respect the LC_TIME locale configuration.
Jeff King, aka Peff, replied:
Right, we use our own routines for formatting the dates, and not strftime. And it probably should stay that way in general, as git’s output is often meant to be parsed.
That being said, I do not think it would be wrong to have a date-mode that just showed strftime(“%c”), or some other arbitrary strftime string. You could then set log.date as appropriate for human consumption.
To that H.Merijn suggested the implementation of the following options
--date=lc, --date=lc_time and --date=locale.
The second issue H.Merijn reported was that git log with either
--date-order or --author-date-order does not order the commit by
date.
To that Peff replied:
Correct. The documentation says:
–date-order Show no parents before all of its children are shown, but otherwise show commits in the commit timestamp order.
[…]
There is not a simple way to show commits in arbitrary order without respect to parentage. I think you’d have to do something like:
git log –format=’%at %H’ | sort -rn | cut -d’ ‘ -f2 | git log –stdin –no-walk
And H.Merijn said that the option names are misleading, and suggested a gitk option for Peff’s script.
It looks like no gitk option has been developed yet for the above, but
Peff sent a patch series
to implement --date=format:... which can produce the same output as the
--date=... options H.Merijn suggested about his first issue.
As Peff’s patch series uses strftime()
to process the format passed in --date=format:..., a discussion
about how to manage a potential strftime() failure when it is passed a
bogus format ensued.
git-multimail 1.1.0 and 1.1.1 were released. git-multimail is a tool to send notification emails for pushes to a git repository. It is also available in the contrib/hooks/multimail/ directory of Git’s source tree (the new version will be distributed with Git 2.5).
Various
Light reading
Git tools and sites
git commit --amend, but it allows you to ‘inject’ your changes into commits further back in history using git rebase (no license)This edition of Git Rev News was curated by Christian Couder <christian.couder@gmail.com>, Thomas Ferris Nicolaisen <tfnico@gmail.com> and Nicola Paolucci <npaolucci@atlassian.com>, with help from Eric Sunshine <sunshine@sunshineco.com>, Junio C Hamano, Matthieu Moy and Johannes Schindelin.