Removing features from a tool is never easy. Once there is enough of a
user base to complain about annoyances, there is also a vocal group that
uses and likes those same annoyances. The recent removal of the
style commands from Git is just such a case, but many of those
using those commands did not find out
about the removal until after the change was made, which only served to
increase their outrage.
Until version 1.6.0, Git has always had two ways to invoke the same
functionality: git foo and git-foo. This was done by
installing many—usually more than 100—different entries into
/usr/bin for all of the different git subcommands. Some were
concerned that Git was polluting that directory, but the bigger issue was
the effect on new users. Partially because of shell autocompletion, a new
user might be overwhelmed by the number of different Git commands
available; even regular users might find it difficult to find the command
they are looking for if they have to sort through 100 or more.
Many of the Git subcommands that exist are not necessarily regularly used.
There are quite a number of "plumbing" commands that rarely, if ever,
should be invoked by users. Those are best hidden from view, which can be
done by moving them out of /usr/bin. This has been done for the
1.6.0 release, but Junio Hamano opened up a can of worms when he posted a
request for discussion about taking the
next step to the Git mailing list.
In the 1.6.0 release, the only things exposed in /usr/bin are the
git binary itself along with a few other utilities; the rest have been
moved to /usr/libexec/git-core. The hard links for each of the
git-foo commands have been maintained in the new location, which
allows folks that
still want the old behavior to get it by adding:
(or some other startup file, depending on the shell).
This would allow users—especially scripts—to continue using the
dash versions of commands.
Unfortunately, for many users, the first they heard about this change was when
things stopped working after they installed 1.6.0. The Git team admittedly
did not get the word out very well; by trying to be nice, they missed an
opportunity to make users notice the change. As Hamano puts it:
But that niceness backfired. Many people seem to argue now that we should
have annoyed people by throwing loud deprecation notices to stderr when
they typed "git-foo", and we should have risked breaking their scripts iff
they relied on not seeing anything extra on the stderr.
Hamano got caught in the middle to some extent as he wasn't particularly in
favor of the original change, but at the time it was decided, there were
few advocates for keeping 100+ commands in /usr/bin. There were
several complaints about having that many commands, but chief amongst them
was confusion for new users. By removing them from /usr/bin and
providing an autocompletion script for bash that completes only a subset of
subcommands, users will have fewer options to scan through—and to be
The original plan called for moving the dash-style commands out, which has
been done, but also eventually removing the links for any of the
git-foo commands that are implemented in the core git
binary. Over time, much of the functionality that was handled by external
commands has migrated into the main git program.
It is the eventual removal of the links that Hamano is asking about in his
much of the response was flames about the step already taken; some
could not see any advantage to moving the git-foo commands out of
David Woodhouse is one of those who wants
things to remain the same:
Just don't do it. Leave the git-foo commands as they were. They
weren't actually hurting anyone, and you don't actually _gain_
anything by removing them. For those occasional nutters who
_really_ care about the size of /usr/bin, give them the _option_
of a 'make install' without installing the aliases.
Several others agreed, but that particular horse had already left the
barn. Throughout the thread, Linus Torvalds was increasingly strident about the
$PATH-based workaround, which effectively ends the discussion that
Hamano was trying to have. For that workaround to continue working, the links must be
installed in /usr/libexec/git-core. Though it strays from the
original intent, it is a reasonable compromise, one that will serve
git-traditionalists as well as new users and others who no longer want the
Two things have helped keep the controversy alive: some documentation,
test, and example scripts still refer to dash-style commands, but worse
than that, one must do man git-foo to get the man page for that
subcommand. It is a convention within the Git community to use the
dash style when referring to commands in text, which explains some of the
usage. Because man requires a single argument, the dash style is
used there as well, though git help foo is a reasonable
alternative. For users who started relatively early with Git, and are aware of
the dash style commands, these examples further muddy the water.
It is a difficult problem. Projects must have room to change, but once
users become used to a particular way of doing things, they will resist
changing—sometimes quite loudly. As Petr "Pasky" Baudis points out, though, Git
is still evolving:
You can't ask us to stop making any incompatible changes - Git is still
too young for that and it's UI got evolved, not designed. But we do
document the changes we do, even though we might do a better job
*spreading* the word.
The Git developers still see it as a young tool that may still undergo some
fairly substantial modifications, while the hardcore users see it is a
fixed tool that they use daily—or more frequently—to get work
done. The tension between those two views is what leads to flamewars like
we have seen here. Certainly the Git folks could have done a much better
job in getting the word out—Hamano was looking for suggestions on how to
do that better in his original post—but users are going to have to be
flexible as well.
to post comments)