Re: [PATCH 00/11] Start retiring .git/remotes/ and .git/branches/ for good

From: Junio C Hamano <gitster@pobox.com>
Date: May 12, 2017, 12:00 UTC
Message-ID: <xmqqfuga5lp2.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <xmqqk25m98rd.fsf@gitster.mtv.corp.google.com>

Junio C Hamano <gitster@pobox.com> writes:

Show 11 quoted lines

> Johannes Schindelin <johannes.schindelin@gmx.de> writes:
>
>> Git uses the config for remote/upstream information in favor of the
>> previously-used .git/remotes/ and .git/branches/ for a decade now.
>
> The last time I thought about trying this several years ago, I found
> that people who need to grab things from many places still do use
> .git/branches/ and their use case is hard to migrate to .git/config,
> primarily because the former is "one per file" and it is easy to
> add/remove/tweak without affecting others.  Ask akpm@ if he still
> prefers to use .git/branches/ for example.

FWIW, I do not think there is any reason for people to be using .git/remotes/, but for .git/branches/, I do not think I can offer a more efficient and easier to use alternative based on .git/config to do these things:

 $ grep <substring> .git/branches/* ;# what did I call that remote?
 $ cat .git/branches/$name ;# where do I get that from?
 $ echo "$URL#$branch" >.git/branches/$name ;# I just learned a new src
 $ rm .git/branch/$name ;# I no longer need it

without having to learn things experienced CLI/UNIX person already knows. We simply cannot beat the above with anything like

    $ git config remote.$name.fetch refs/heads/$branch

even though the config based remote definition may be infinitely more powerful.

> Is it really hurting us having to support these old information
> sources we treat as read-only?

And this one is also important. I do not think we had to touch any code that handles .git/remotes/ or .git/branches when we extended the .git/config based configuration for remotes, simply because the old data source are pretty much frozen read-only places these days.