Johannes Schindelin <[email protected]> writes:
> On Fri, 12 May 2017, Junio C Hamano wrote:
>> ...
>> 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.
>
> I do not understand what you want to tell me with that example. It is
> confusing me utterly.
They show how it helps a user, whose primary use of Git is to fetch
from many places, to keep the the old "branches" machinery. It is
not "hard" to migrate in the sense that there is a way to (1) find
the short-name you gave to a remote from a part of URL etc., (2)
find the exact attributes of the repository a short-name refers to,
(3) update an existing or add a new short-name and (4) remove an
existing one. The remotes.*.{url,fetch} configuration are expressive
enough to represent these operations. It however is more work and I
couldn't think of alternatives.
>
>> 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.
>
> Then maybe we need to teach, say, `git remote` to be that powerful?
Ah, after all, you weren't confused utterly.
Not necessarily "that powerful", but yes, if we had something that
is quick and easy to use as a replacement, I do agree we can plan
.git/{branches,remotes}'s removal. The point of "branches" thing to
existing users, I think, is not its expressive power (it is much
much simpler and can do only one thing) but its simplicity.
Thanks.
