Development

Git, Emacs, and version-control workflows

Emacs is used with a dizzying array of outside tools, particularly when it is part of a software-development workflow. Recently, though, the project's developers got into a rather involved debate about the boundary between Emacs's functionality and various version-control systems (VCSes). Richard Stallman advocated for a change that he said would fix an inconsistency between how Emacs interacts with Git and how it interacts with other VCSes. Git fans, however, contended that the change would break some of Git's most important functionality.

At issue was how Emacs's version-control module VC interfaces to Git. VC includes a command called vc-next-action, typically invoked by typing "Control-x v v". According to the manual, this command "performs the 'most appropriate' action on the current VC fileset: either registering it with a version control system, or committing it, or unlocking it, or merging changes into it." Setting aside all questions about whether such a context-dependent command is a good idea in the first place, it is probably clear that what the "most appropriate" action is can attract some differences of opinion.

On March 24, Stallman offered up his suggestion for how the command should work in Git:

As it turns out, many others on the Emacs development list did see such reasons, primarily because Git, like other distributed VCSes (DVCSes), treats committing a change and pushing it to the repository as entirely different operations. Dmitry Gutov was the one of the first to reply, noting that the change would leave Git users without a means to commit without pushing, and that "even if we add a user option, this would be an attempt to paper over the differences between the traditional VCS and the (modern) DVCS."

Stallman replied that he has used a "modern" VCS (specifically, Bazaar) quite recently, and that it does not separate committing and pushing. However, Stefan Monnier noted that this was because VC makes use of Bazaar's bound branches feature, which ensures that local and remote branches are kept in sync. VC uses bound branches by default specifically so that Bazaar behaves more like CVS.

In the rather lengthy discussion that followed, a few key points emerged. There would be some practical obstacles to implementing commit and push as the automatic behavior for vc-next-action. The push could fail, for instance, for a variety of reasons; pretending that the sequence is a single atomic command would thus introduce a lot of complexity.

More generally, though, a number of commenters replied that different users may have wildly different Git workflows, including those in which a push should not automatically follow every commit. Stallman replied that he had no objection to making VC's behavior configurable, but that he did object to making the default action "lead people to think they are finished, without installing the changes on Savannah." As many free-software users will know, Savannah is the GNU software-hosting service—in effect, the central repository.

That reaction led to a different sub-thread. Eric S. Raymond regarded it as evidence that Stallman is still thinking in terms of centralized VCSes, where "commit" and "repository sync" are one and the same command. DVCSes like Git not only separate commit and push into distinct commands, they make entirely new workflows possible.

In fact, the new workflows are often a significant motivating factor in the creation of a new DVCS. As Monnier put it:

Stallman eventually seemed to concede that his workflow—which revolves around committing changes that will immediately be checked into a central repository—is likely not what most Git-driven users of VC are expecting. But that still left open the tricky question of what VC should actually implement. VC, after all, is intended to be a general-purpose interface to a variety of VCSes; users expect it to adhere to the "do what I mean" (DWIM) principle, especially where vc-next-action is concerned.

But it is still hard to decide what the DWIM action at the moment of the commit is. As Jan D. put it, "it depends on who is the I in DWIM." Gutov, for example, proposed that VC could list the local, unpushed commits in the status buffer (which is the default behavior Magit provides). Stallman suggested having VC not push after each commit, but having it display a message suggesting that a push be performed.

Others noted that users can simply add a post-commit hook to do a push (or indeed any other action) after each commit. Thus, individuals' different workflows should be implemented at the Git level, and VC should not get involved. Eli Zaretskii argued that DVCSes offer so many more possible workflows that there is no simple answer to the "what do I do next?" question.

Eventually, the option that seemed to garner the most support (although that support could hardly be described as enthusiastic) was to to add a separate vc-push function to VC. That, said Monnier, would fix the underlying problem, which is that VC does not currently treat commit and push (or their equivalents) as separate actions. The addition of that function, though, would be only a first step. The lingering question of what default "next action" behavior VC should take when using Git will, no doubt, be revisited.

Likewise, the Emacs community may have stumbled into a challenge that it will be grappling with for quite some time: how can it support the significantly different workflows that users of today's popular DVCSes expect, while still supporting the existing workflows of other developers. Emacs has adapted to embrace a wide range of computing tasks in his long history; VC itself may not emerge from this discussion unchanged, but Emacs will certainly adjust.

Comments (45 posted)

Quotes of the week

Comments (1 posted)

Blender 2.74 available

Version 2.74 of the Blender 3D modeling and animation studio is now available. Included in this release are direct access to compositing features from within the viewport window, significant improvements to the hair dynamics system and its associated editing tools, and a number of improved modeling tools.

Comments (none posted)

Firefox 37.0

Comments (25 posted)

GNU APL 1.5 is available

Version 1.5 of GNU APL has been released. Included are updates to multi-core support, performance counters for all built-in functions, and a build-time option to compile GNU APL as a library.

Comments (none posted)

Erlang/OTP 17.5 available

Erlang/OTP version 17.5 has been released. Changes include new command-line arguments for the Erlang Run-Time System Application (ERTS) and new configurable attributes for messages in the Diameter protocol.

Comments (none posted)

Django 1.8 released

Version 1.8 of the Django application framework has been released. New in this version is native support for multiple templating engines, support for complex SQL queries, and some new PostgreSQL-specific functionality. Django 1.8 has also been designated a long-term support release.

Comments (none posted)

Development newsletters from the past week

• What's cooking in git.git (March 26)
• LLVM Weekly (March 30)
• OCaml Weekly News (March 31)
• OpenStack Community Weekly Newsletter (March 27)
• Perl Weekly (March 30)
• PostgreSQL Weekly News (March 29)
• Python Weekly (March 26)
• Ruby Weekly (March 26)
• Wikimedia Tech News (March 30)

Comments (none posted)

Stenberg: The state and rate of HTTP/2 adoption

At his blog, Mozilla's Daniel Stenberg has written up a detailed look at HTTP/2 adoption—on both the browser and server sides, plus forays into proxies, content-delivery networks, and non-browser software as well. "My prediction: We’ll see >10% usage by the end of the year, possibly as much as 20-30% a little depending on how fast some of the major and most popular platforms will switch (Facebook, Instagram, Tumblr, Yahoo and others). In 2016 we might see HTTP/2 serve a majority of all HTTP requests – done by browsers at least."

Comments (none posted)