My itsy-bitsy contribution to Git

This is from 2005, when I was at an all-linux, all-python shop called Progeny Linux Systems. A lovely time, really. Great people, interesting technology, challenges and opportunities every day. Not everything we did was stellar, but we were moving together in a good direction.

We started using git when it really was a "git" (a stupid person or thing) and the tools were very confusing because they mixed noun names and verbs, and people were just kind of used to it being confusing.

You used to have to go by hand into the innards of the .git directory structor to create tags and branches. 

A "porcelain" was a wrapper around git to make it more useful and tolerable, and ours was specific to building custom Linux distributions. It was a cool project. 

My contribution was very meager: I complained about the inconsistent naming of git tools at the time. 

I started with a question here:

So when this gets all settled, will we see a lot of tool renaming? 

While it would cause me and my team some personal effort (we have a special-purpose porcelain), it would be welcome to have a lexicon that is sane and consistent, and in tune with all the documentation. 

Others may feel differently, I understand. 

Started getting serious here:

Junio C Hamano wrote:
> Tim Ottinger writes:
> > git-update-cache for instance?
> > I am not sure which 'cache' commands need to be 'index' now.

> Logically you are right, but I suspect that may not fly well in
> practice. Too many of us have already got our fingers wired to
> type cache, and the glossary is there to describe both cache and
> index.

I'd vote for cleaning it up /now/. Sure, it will hurt, but if you let time
go by and do it later, it will hurt much more.

Pre-1.0 is the last chance, AFAICS.

Daniel turns it into a plan:

OK. As Horst also says, we should do this before 1.0.

0.99.6::
This hopefully will be done on Sep 7th. Tool renames
will not happen in this release, but the set of cleaned
up names will be discussed on the list during this
timeperiod. I'll draw up a strawman tonight unless
somebody else does it first.

0.99.7::
We install symbolic links for the old names. For the
documentation, we do not bother --- just install under
new names. Also remove support for ancient environment
variable names from gitenv(). Aim for Sep 17th.

0.99.8::
Aim for Oct 1st; we do not install symbolic links
anymore and supply "clean-old-install" target in the
Makefile that removes symlinks installed by 0.99.7 from
DESTDIR. This target is not run automatically from other
usual make targets; it is just there for your convenience.

Junio gets down to cases:

I said:
> I'll draw up a strawman tonight unless somebody else
> does it first.

1. Say 'index' when you are tempted to say 'cache'.

git-checkout-cache git-checkout-index
git-convert-cache git-convert-index
git-diff-cache git-diff-index
git-fsck-cache git-fsck-index
git-merge-cache git-merge-index
git-update-cache git-update-index


2. The act of combining two or more heads is called 'merging';
fetching immediately followed by merging is called 'pulling'.

git-resolve-script git-merge-script

The commit walkers are called *-pull, but this is probably
confusing. They are not pulling.

git-http-pull git-http-walk
git-local-pull git-local-walk
git-ssh-pull git-ssh-walk

3. Non-binaries are called '*-scripts'.

In earlier discussions some people seem to like the
distinction between *-script and others; I did not
particularly like it, but I am throwing this in for
discussion.

git-applymbox git-applymbox-script
git-applypatch git-applypatch-script
git-cherry git-cherry-script
git-shortlog git-shortlog-script
git-whatchanged git-whatchanged-script


4. To be removed shortly.

git-clone-dumb-http should be folded into git-clone-script

... the rest, as they say, is version control history.

To this day the git toolset is consistent. 

I think it's remarkable now, because the dev team listened to me and answered even though I was not really a part of the group. I didn't have to earn voice, it was okay. 

Even though I did nothing more than ask a question, it has always made git feel like "my" version control system. 

I guess any little interaction that leads to action will create a sense of engagement and participation.

Thanks Git team from 2005. You were great.