Welcome to the 24th 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 January 2017 and the Git Merge 2017 conference which happened in Brussels on February 2nd and 3rd 2017.
Git Contributor Summit
The Git Merge 2017 conference took place in Brussels on February 2nd (workshops and contributor summit) and 3rd (main conference day). Quite some of the attendees seamlessly joined the FOSDEM think tank right after the Git Merge after-party. For those interested in the “runtime side of life”, the Config Management Camp in Ghent offered yet another 2 days to get exhausted.
On February 2nd, as part of the Git Merge, a Git Contributor Summit had been organized. While both Lars Kruse’s and Ed Thomson’s blogs, listed in the “Events” section below, very nicely express the great atmosphere at the summit, and Johannes Schindelin, alias Dscho, sent a collaborative report written by the contributors, here are the unconference’s agenda items:
Erik van Zijst presented Atlassian’s “clone bundles” approach, which had been added to Mercurial some years ago, was later included in Bitbucket.
Atlassian would like to add it to Git, but would like to discuss the approach first.
Stefan Saasen had sent an email about it a few days before the Summit.
The main motivation for this feature are CPU and I/O usage on the server side.
The feature would be good for large collections of repos, e.g. the set for Android; the Google “repo” tool would be an alternative.
One alternative would be the design of the Git protocol version 2, with capabilities negotiation first.
Jeff King, alias Peff, suggested to keep the solution as simple as possible (as an example, a sliced history etc. would be nice to have, but things could get quite complicated).
One downside is that it could take twice the disk space if the bundle is not generated on the fly.
At present, the Atlassian client is a script
mimicking git clone, while a proper solution would
involve the Git client.
Peff expressed his willingness to help Atlassian on this subject.
The solution is experienced as more efficient, but no real statistics / conclusions for real world repos are available yet.
Jeff King, alias Peff, presented a “1 minute version” of the current status of the Software Freedom Conservancy; details available on the mailing list. (See also the next article in this edition of Git Rev News.)
The SFC acquired git-scm.com, maintained by Peff.
Most effort is spent on trademark/policy work.
Christian Couder and Ævar Bjarmason presented “Big repos”.
The topic is very related to the „references database“ item below, and deals with improved rebase / staging (split index).
The main idea is to make the git client faster for
some index related operations (that is, git status).
Some work on a daemon for file system notifications in the background (inotify) has been done by Duy Nguyen and David Turner, and a rework was planned, but the present contributor is currently busy with other things.
On Windows, there is no inotify feature available (also applies to some Unix flavours).
Some discussion arose whether the Windows journal feature or Watchman was the appropriate road to follow.
The participants with really large repos shared their experience.
Stefan Beller presented the git submodule state.
Instead of git submodules, Android with its 1000
Git repos uses the repo tool; the Android
repositories are somewhat unrelated, and most
contributors just work in 1 or 2 repos.
Regarding submodules, actually the fetch is parallelized, checkout is being worked on, next are worktree and submodules.
Inside Git, there is no real module awareness for submodules yet, so each and every Git module needs to be made „submodule ready“.
At present, one Git process is spawned for each repo, which is quite slow on Windows.
The submodules design is considered not to be optimal yet; as an example, subsets are not possible.
Within Gerrit, project changes lead to superproject changes, which might collide, and end up in superproject merge conflict mess.
David Turner considered merge conflict helpers for submodules.
Johannes Schindelin remarked that offloading such issues to tools like Gerrit looks suboptimal.
The topic was concluded with a short discussion on
git bisect with submodules.
Jacob Vosmaer presented the GitLab solution for Gitaly, aka „Git RPC“.
GitLab tries to get away from NFS, and would like to see a LRU disk cache, as the NFS cache not good enough for heavy use.
The question is how far only GitLab is affected (vs. the general community).
Use case example are bad refs and storing diffs.
The work on the Git cache started, but is stalled at present; it will be MIT licensed (uses both Git and Mercurial code).
Johannes Schindelin started a brainstorming session about “Better tools for reviews and contributions”; see also his post Clarification about “Better tooling for reviews”, was Re: Google Doc about the Contributors’ Summit
The mailing list currently drops contributions via mailers which produce HTML or mixed code. It is too difficult for people to supply patches by mail; the “it worked for me, should work for others, too” approach (“and then everybody failing is stupid”) is considered simply wrong. One of the rejected clients is Microsoft Outlook, the other is Gmail, the main problem being the handling of white space. Perhaps some tool might help with transmitting code corrections with white space. In general, patches would be better attached to mails than just placed inline.
It is problematic to follow long threads (e.g. one thread stalling for 8 months), while the state of patches discussed is sometimes unclear.
Often, reviewers’ suggestions are lost in the clutter of the mailing list threads, and no tool helps us to catch those issues.
It happens from time to time that the latest iteration
of a patch series was not picked up before merging to
master, and we have no tools that help us prevent that.
The “What’s cooking” emails
are sent only to the mailing list, but none of the original
contributors are Cc:ed in that email. At present, the
“what’s cooking” email is mostly generated in an automated
way from the todo branch
using special-purpose shell scripts.
Is there a way to get from the mail client directly into the mentioned source code?
The Git terminology is sometimes strange (“outside this room, nobody uses the term ‘re-roll’”), the Git glossary is hard to find, and could be improved; using terms only the email community uses does not improve readability for others outside the list “inhabitants”.
Johannes regularly submits other peoples’ patches, and would like to see better tool support for this use case. Peff asked whether we need different terms, or better concepts?
Regarding patches, the maintainer decides when and where they are merged / implemented. The maintainer workflow may prevent us from just using GitHub Pull Requests. Whether to merge or rebase is then finally a manual decision of the maintainer, independently of what the author intended. A longer discussion arose around this subject; Stefan Beller mentioned that a similar problem appeared in the Linux Kernel world (especially on the Intel side), and now the Kernel community says “it can be ok to attach patches if you cannot do otherwise”. Johannes emphasized his willingness to establish tools which help to improve the situation. It was mentioned that code/commit notes should point to mailing list where appropriate. Josh Triplett steered the discussion toward distributed review tools, and mentioned that there is already a data format for that purpose: ReviewDB. This format, however, would need to be extended to allow for addressing the issues raised in the discussion.
Carlos Martín Nieto presented the state of the references database, to get them away from the file system.
A recurring problem seems to be that usable databases do not have a Java implementation (e.g. lmdb last tried); this would help GitHub but still have the potential to split the Git community.
According to Peff, Git currently reads the whole packref file into memory – mmap could help but would need a lot of refactoring.
An important question is whether it is a client or a GitHub hosting problem; some workflows could cause unhealthy numbers of refs on a client, too.
At present, not all race conditions fixed yet. The final solution should be portable to JGit / libgit2.
After the efforts of David Turner, there is now an appropriate ref API within Git.
Brendan Forster presented the gitignore „spec“.
The goal is to be more standardized and robust (that is, understandable).
Docs should be more structured.
One problem is that different implementations of Git, and other tools use gitignore, but implement the stuff differently.
An interesting question would be if we could have a common minimal implementation of gitignore in a generally reusable library.
Git attributes has similar problems (reading attributes from files in the Index is a nightmare, in some case with read / change / read / change / read sequences (or the like) involved).
Josh Triplett presented “Git commit refs, tag refs, and compatibility (future of git-series)”.
Junio has suggested a different type of Git refs (in-tree, like hard links).
Compatibility: support old clients / libgit either on repo level, or unless an operation hits an object type unknown for the old version (the latter being more complicated).
Use cases should be implemented as easy as possible.
Would be great to disallow the capability per repo.
Other topics:
Git / Software Freedom Conservancy status report
At the previous Git Contributor Summits which were also part of the previous Git Merge conferences, Jeff King, alias Peff, used to give a talk about the status of the Git project as part of the Software Freedom Conservancy.
It used to be a detailed talk about the different aspects of what the Git “Project Leadership Committee” (PLC) which represents Git in the Conservancy and the Conservancy itself are doing.
This is an important report as the PLC consists only of Junio Hamano, Shawn Pearce, and Peff, so most the community otherwise doesn’t know what happens in some areas of the Git project, like legal and money related things.
This year, though, Peff sent detailed reports in emails to the mailing list just before the Contributor Summit, and at the Summit his one minute long talk consisted in referring everyone to these emails.
The main report gives a bit of background, and then details the financials of the project. There is not a lot of news there, as the Git project is not much interested in raising fund as it has not a lot of expenses. The main report also talks a bit about mentoring, but for the git-scm.com domain and trademark activities, it refers to separate emails that Peff sent at around the same time as the main one.
The “git-scm.com status report” email is indeed quite long and informative. It was surprising to learn that the Git project got control of the git-scm.com and git-scm.org domains and the associated web site this year, and interesting to know what technologies and hosting services the web site has been using.
This report was then posted and discussed on Hacker News. This in turn seems to have attracted a number of new people toward the project. Some of them replied to Peff’s email and proposed to help him maintain and improve the web site.
Other people seem to have been the reason why Peff subsequently sent an email about Software Freedom Conservancy donations telling that “a lot of people offered financial assistance” and that “we don’t have a dire need for money to keep hosting the site”, and pointing people back to the main report he previously sent, as well as suggesting people donate directly to Conservancy’s general fund or become Conservancy Supporters.
The email that Peff sent about “Git trademark status and policy” had also a lot of interesting details, but has not attracted much public interest.
Git Merge 2017 — General Sessions
“Intro & Welcome - Software Freedom Conservancy”
Karen Sandler, Software Freedom Conservancy
Karen wrote about her intro talk in Git Merge and FOSDEM 2017!:
For me, FOSDEM this year started two days early with Git Merge, the annual Git conference. Git Merge is organized by GitHub, and so far in all three years of its organization the conference has donated the proceeds from ticket sales to Conservancy! I’d been hoping to get to Git Merge one of these years, so I was very excited with the organizing team asked me to do an talk introducing Conservancy.
I got to kick off the conference, and introduced myself by explaining how investigating my heart condition and defibrillator caused me to become passionate about software freedom. I then delved into what Conservancy does and in particular talked about some of the work we’ve done with Git. The talk had a good impact, and all day long I was able to speak with people who were excited about Conservancy and thinking about the ethics of all of our software. It’s always especially thrilling to speak at our member projects’ conferences. I love meeting up with leadership committee members and also putting faces to the names that we see go by while monitoring the activities of our projects.
Karen has a pacemaker (implanted defibrillator) and was worried about what software it runs on. Everyone knows that software is potentially buggy. She asked to see the source code, but was refused, as the software is proprietary.
That was the kick-off for starting the Software Freedom Conservancy. The conservancy does legal work, handle foundations and fundraising. They give advise on licensing and trademark protections. Git is one of SFC member projects.
Karen’s defibrillator is a metaphor for all the software out there that we rely on - as she said:
We’re only as free as the software that we use.
“Top Ten Worst Repositories to host on GitHub”
Carlos Martin Nieto, GitHub
Carlos give insights into some of the challenges that GitHub meets when hosting their 14 million user infrastructure. What makes repo “the worst” varies: a huge amount of files, data, forks, tags, contributors or pushes.
Here are some of the worst Carlos showcased:
An everyday example is a community that is organizing commit wars; thousands of users committing to the same repo, at the same time, so see who gets in: commitwars/commitwars
Another is repository hosting mirror of 9gag, with 365GB of data, and 300-400MB pushed every 10 minutes: gambuzzi/gambuzzi.github.io
There are projects that are just large, with long history and/or large number of files, like torvalds/linux, with 42GB data on disk.
Other just go to the extreme with the use of GitHub-based workflow, that is with extensive use of pull-requests and issues, like kubernetes/kubernetes with 24K pull requests in total, and 5K+ open issues, plus 12K closed.
Carlos has this to say about first two:
Please don’t
“Scaling Git at Microsoft”
Saeed Noursalehi, Microsoft
Saeed talked about scaling Git at Microsoft with more that 30K developers. When they started with the humongous Windows repository it would literally take (almost) days to clone the repository. Git’s assumptions generally work well for reasonable repositories - but it is still a problem to be solved. It was beyond help of Git LFS and similar solutions.
They have implemented GVFS - Git Virtual File System; which is an open-source project, just released by Microsoft. This helped them a lot with this Windows repo:
Git experience on Windows repo (with GVFS)
12 hrs5 mins - clone
3 hrs30 secs - checkout
8 mins4 secs - status
30 mins13 secs - commit
GVFS is basically a file system driver combined with a read-object hook in Git, and a persistent daemon process driving said hook. The read-object hook is a new concept that Microsoft has introduced to Git. This solution allows for (their fork of) Git to populate files and download objects (commits, trees, blobs) on demand.
Saeed started a live demo on a VSO. He has shown how the files got populated (“hydrated”), that is their content downloaded, on first access (on first use). You could also see live the JSON-based protocol used to communicate with GVFS daemon (service).
The trees doesn’t grow in to the skies - when asked about
searching globally in your repo - answer was “Yes, that will
still be very painful”. Browsing history was also a problem, as
it would “hydrate” objects; though in Q&A session there was a
suggestion of running git log on server, like for centralized
version control systems.
Currently GVFS is limited to MS Windows, and requires hacked Git. Microsoft also cares about other platforms: the message is “We’re hiring - especially if you know file systems on Mac and Linux”. Microsoft is also working on core Git integration: see the discussion in thread started by Ben Peart [RFC] Add support for downloading blobs on demand.
“What’s Wrong With Git?”
Santiago Perez De Rosso, Software Design Group, MIT
According to Santiago, Git is hard to learn and the documentation is scary. He presented one after another slides from an on-line version of the Git documentation, and from the fake Git-manpage generator. There was also a jokingly provoking slide on how commits can easily be represented as a manifold in a multi dimensional space.
In his PhD work, Santiago has been surveying user response to the usability of Git, and experimenting with fundamental improvements to the Git experience. In his talk, he covered a new theory of top-down design, focusing on the purposes and concepts underlying software; the material expanding on Purposes, Concepts, Misfits, and a Redesign of Git paper - covered in Git Rev News: Edition 20. Santiago showed the complexity of understanding concepts like stash, detached head, and untracked files, and how they relate (or not) to concepts and purposes of a VCS.
In his experiment of improving Git usage, he presented Gitless, an experimental version control system built on top of Git (also covered in edition 20). In this DVCS, a branch includes it’s working dir, so dirty files never prevent a branch switch. Other similar changes were made to the other identified confusing topics. Gitless was then used to run parallel experiments with non-expert and expert Git users to compare how learning Gitless compared to Git.
Gitless was just an experiment, but Santiago suggested that the world might be ready for new VCSs, or at least a new porcelain or GUI on top of Git, based on this research.
“Git: The Tool Loved and (sometimes) Feared”
Caren Garcia, BazaarVoice
Caren was sharing her experiences teaching Git. According to Caren, Git conflicts induces panic states in students. The command order confuses them, but they love the utility of having everything in Git.
Caren recommends the web site OhShitGit the get help to get out of panic situations. There is always a possibility of screwing up, and this site would help you to figure how to fix your mistakes. (This site was covered in Git Rev News: Edition 19)). Her students has had great success using Git CLI for learning Git.
She also wants everyone to use Git - writers, governments and school. Git is more than a software; a concept, a way of thinking, and because of that it can be used outside the IT field.
“Scaling Mercurial at Facebook: Insights from the Other Side”
Durham Goode, Facebook
Durham talked about how Mercurial (Hg) has been scaled at Facebook, and about the way software version control is organized there. (Reasons for choosing Mercurial can be found in Scaling Mercurial at Facebook blog post from 2014 by Durham Goode and Siddharth P. Agarwal; an update on how they are using it internally was covered in Git Rev News: Edition 21.)
The Facebook development environment is composed of monorepos, no feature branches, rebases and no merges, single commits per push. They assume that all developers work online, that “everyone commits on master” (in order to overcome their tremendous size), and that “every commit is pushed”. The size of their version control support team is very small compared to the large number of developers they employ - therefore they need a simple workflow, and the amount of time for teaching version control is limited.
To solve the issue of push conflicts, they have implemented
PushRebase, which basically allows the server to perform your
rebase for you in some conditions, eliminating the problem of push
being rejected because the local repository is not up to date
(someone pushed first).
They tend to assume their developers are online; thus they
implemented InifinityPush, which assures that every commit ever
is pushed (helped with new scalable way of storing data). This
solves many problems of error recovery.
The implementation (fork) of Mercurial that Facebook uses allows to check out only part of the code that is actually needed. This is especially needed for the monorepos. The feature is similar to Git’s sparse checkout; the important difference is a far better UX. Their implementation allows for example easy switching between predefined (via in-repository file with known format) sets of files, selected for well-defined tasks. This is something worth porting to Git, to improve its sparse checkout feature.
The question of User Experience (UX) is very important for
Facebook. Durham asks: “Why isn’t the default behavior of the
git log useful? - Why do we all have to go through hoops to
customize the log enough to make it useful?”. They have made
SmartLog, which allows to see only useful commits for a given
developers. It also allows to easily recover for instance commits
that are not reachable from any branches, without need for extra
knowledge and to reach for any advanced features. This is
something worth borrowing; git-log-compact
is a project that implements something similar (covered in detail
by Git Rev News: Edition 20).
Durham has emphasized the need to focus on the UX, the need to
enable new users to do power user moves. He uses hg unamend and
hg uncommit as good examples for that.
At the end, the critical crowd asked “Why isn’t this Open Source” to which the one acceptable answer came… “It is!”. Facebook runs the latest stable Mercurial build and hereby catches a lot of Mercurial bugs before they hit others. Not everything is contributed back to hg-core, mostly due to the fact that not all contributions they make are backward compatible.
“Git LFS at Light Speed”
Lars Schneider, Autodesk and Taylor Blau, GitHub
This was a two part presentation, about a way to dramatically improve performance in a popular Git extension - LFS (Large File Storage) - that required changes in both Git Core, and the extension itself.
In first part Lars walked through how to contribute to Git. You can find description of (part of) his experience, namely developing and reviewing the “Git filter protocol” feature, in Git Rev News: Edition 18. “Developer Spotlight: Lars Schneider” can be also found in this edition.
It’s not just about implementing the feature; it needs to be documented, and tested as well. The commit message should be self-contained, meaning among others that you need no external dependencies to figure out what the commit does. There are many steps that one has to go through, and for such far reaching feature (with the need for backward compatibility) also usually many iterations. As an example of the friction in this approach, Lars gave us the example: this patch series gave a very hefty performance improvement… and it took him 6 months and 380 emails to get it approved.
Git is used by millions all over the world, you don’t want to be the one breaking it.
In second part Taylor took over to talk a bit about the server side of Git LFS. Go was used as a language of choice for implementing it. Here using the Scanner pattern in Go turned out to be a perfect match for the way Git plumbing passes information to the Git-LFS process on the server. He shared a description of the refactoring performed to speed up the operation.
All this of course needed to be synchronized across different projects, different programming languages, and different developers.
At the end, Taylor shared the ideas for next steps for Git-LFS server, namely: Promise capability, file-path exchange, and work on figuring out how to make Git-LFS even faster.
“Git Aliases of the Gods!”
Tim Pettersen, Atlassian
Aliases are not just about saving time and keystrokes, though as
Tim said the most basic and common example of using aliases is to
create shortcuts, for example git co for git commit, or git
st for git status. It is also about reducing cognitive burden.
Whenever you find yourself googling the same thing over and over
(or browsing manpages, or searching StackOverflow) - you should
consider making an alias.
As an example of the latter, Tim took us through the tour of four
different ways that you can create a stash, and how that interacts
with the index and the working directory. The option names are not
easy to remember; because of the way they were developed there is
no commonality of names between them. Therefore he had made 3
aliases, so that the more as you have in your command the more
you stash: stsh, stash, staash and staaash.
He created a funny alias called standup and lazy standup:
[alias]
standup = !git log --all \
--author=$USER \
--since='9am yesterday' \
--format=%s
lazy-standup = !git standup | say
Tim also described how to create more involved aliases; how to
join more than one command together, and how to pass parameters to
the inside of such a pipeline. He showed both the sh -c '...' -
trick and the immediately invoked shell function trick, while
reminding us that if an alias gets too complicated, it is better to
just create a new git command (by putting a git-sth executable
shell script, for example, in your PATH), rather that worrying
about appropriate escaping and quoting.
Tim also presented an awesome, and very silly way, to spoof Git SHA-1’s with the help of emojis and raw processing power. As an example with git-sham you can make it so that subsequent commits have SHA-1 identifiers beginning with subsequent numbers.
Atlassian’s Bitbucket has joined the Continuous Development (CD) world for real, providing a lot services like those GitLab and Travis are doing, called there “pipelines”. They have enabled pipelines in Bitbucket - to allow you to build any branch.
Tim expertly finished by combining Bitbucket Pipeline with an
alias, so he can do with it an equivalent of git bisect by just
running all the bisection steps in parallel - that is
brute-forcing tests. All this without the need to involve the
developer, at the cost of CPU time (though possibly not wallclock
time, assuming sufficient parallelism and small number of commits
to test). The CPU time is worth less than the developer’s time.
You can find aliases used in this presentation in Tim’s git-aliases repository. (MediaWiki has also a wiki page with the list of useful aliases.)
“Lightning Talk / Lessons Learned: Transforming from ClearCase to Git”
Tamir Gefen, ALMtoolbox
This lightning talk presented a case study on moving to Git from IBM Rational ClearCase. Tamir described challenges they faced (among others time to switch and the amount of support, and the impedance mismatch between ClearCase and Git) and how they resolved them, plus some technical tips and insights. The solution chosen was to adjust ClearCase views one at a time, and then dump content on new branches in Git.
“Lightning Talk / Git: The Original Blockchain”
Meredith L. Patterson, Mautinoa Technologies
Meredith showed how Git was chosen as the underlying platform for implementing a money-less transaction exchange ledge system. This implemented an actual monetary system in Sierra Leone, where phone minutes is actually considered a viable FX currency, since otherwise the national bank would go bankrupt.
Bitcoin and other blockchain-based distributed ledger systems are “gossip protocols”, and require always-on Internet access, not available in much of Africa. What is needed is a way to perform transactions off-line, with later reconciliation step. This means that the system needs to store timestamps in its blockchain… Meredith noticed that this is what Git does! The presented solution uses a ledger-cli / hledger plain text accounting format as a format for storing transactions, Git commits for blockchain, remotes as wallets / accounts, and GPG keys with short expiration dates for signing.
This shows how technologies, such as Git, that do one thing well can change the world by doing the thing they do well in unexpected places.
“Lightning Talk / go-git: A Pure Go Implementation of Git”
Santiago M. Mola, source(d)
source{d} wants to clone all open-source projects from major Git hosting sites (17M repositories planned, 6M repositories archived), and then analyze all code history using AI techniques.
For this they needed a special-purposes Git implementation. Santiago introduced the go-git project, a Git library written entirely in Go, designed to be developer-friendly and highly extensible. He shared some of source{d} use cases, and also problems storing (archiving) such a large number of repositories, many of which are forks.
“Git for Pair Programming”
Cornelius Schumacher, SUSE Linux
Cornelius started the presentation by describing in detail the pair programming workflow; why it is used, and how it is done. The important issue is that in this workflow commit has more than one author - developers often change even during the writing of a commit message. Pairs are not forever; the pairing change quite often.
He described the solution used by the git-duet project, which utilizes committer and author to show the identity of both contributors in the pair, optionally rotating them. This tool has its advantages and disadvantages; among others it is less useful for mob programming.
Cornelius then went into details of the multiple authors problem
using anything from emails, commit messages and headers. The
sketch of a proposed solution and discussion how Git could get
native support for pair programming can be found on git mailing
list as
[RFC] Proof of concept: Support multiple authors.
The thread didn’t end in an accepted solution, though when one
would be created it would most probably follow
Junio’s advice
there of utilizing “Co-Authored-by: “ trailers in the commit
message, and extending git shortlog and other commands as
needed.
“Trust But Verify”
Thordur Bjornsson, Yubico
The last talk covered the details on how to cryptographically sign your work. Thordur started with PGP fundamentals and best practices (among others the need for setting an expiration date of PGP keys, to one year at most). Then he went through what can get signed in Git: commits (including merge commits), tags and pushes (the last requiring help from the server) - though the concept of mergetags was missing from the talk. Then Thordur described how to verify those signatures, explaining possible impacts (and the amount of work required), and benefits to one’s workflow.
As one way of verifying signatures, Thordur took a look at GitHub’s interface changes from earlier this year that added visual cues to highlight the verification status of commits and tags.
The slides from this talk (and links to other related resources are available at thorduri/git-merge-2017 repository.
I am a mathematical physicist - I do research on mathematical problems in quantum physics, and I teach mathematics as a lecturer. Sharing and free exchange of knowledge are fundamental for that. Consequently, being involved in open source software projects feels like just another side of the same medal.
For a larger project with multiple moving parts (habilitation thesis) I had used Subversion (that thesis started before git). It made two things clear: I could not have done this without a version control system; and I needed something else (a VCS with actual merges, to say the least).
Git had some geek appeal, but I couldn’t get it to compile on my first
attempts (configure && make..., on a system with libs without headers,
no root). So I went with Mercurial since I was getting into Python
anyway. Only to be confused by Hg’s mantra “to clone is to branch and to
branch is to clone” when there were two commands clone and branch
which did something completely different and - in the case of the latter -
not very useful, it appeared to me. (Hg has the more useful
“bookmarks” these days.)
In the end, it was the branch concept and the tone on the respective
mailing lists at that time that drove me to Git. I had learned not to
use configure for Git by now, and have been compiling it happily ever
after.
There is no single big topic. Mostly, I try to make Git easier and less
surprising to use by doing stuff here and there. The rev-list options
--min-parent, --max-parent and --cherry-mark were fun to do. I
also consider “–textconv” a killer feature and was very successful in
getting Peff to do most things in that area that I wanted to have, and
did a few things “myself” - which is really the wrong term, given how
collaborative our development on git.git is.
Strangely, I was involved in several GPG-related things. I do not use signed tags nor signed commits myself, but I care about GPG and about git making the right calls when it comes to notions like “trust” etc.
What: almost nothing; why: work
During term breaks, I try to follow up an lingering topics and to participate more actively in the Git mailing list.
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?
refs namespace: have tags, notes, replace etc. under
remotes/<remote> with proper merging so that those features learn
to fly; requires a transition plan
rework the UI and make it less surprising: e.g. unify short option names, introduce pseudorefs for the index and worktree and the like; requires a transition plan
If you could remove something from Git without worrying about backwards compatibility, what would it be?
I would do the above without the need for a transition plan :)
Anything that makes textconv fly (unoconv, pdftotext); tig when
log --graph is ambiguous; I should use tig more ;)
Events
Git Merge 2017
Apparently, an increasing number of excellent bloggers attend the conference (this material was used in Git Merge 2017 general sessions writeup above):
Various
Light reading
Git tools and sites
This edition of Git Rev News was curated by Christian Couder <christian.couder@gmail.com>, Thomas Ferris Nicolaisen <tfnico@gmail.com>, Jakub Narębski <jnareb@gmail.com> and Markus Jansen <mja@jansen-preisler.de> with help from Michael J Gruber.