Hi Junio,
On Sat, 13 May 2017, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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.
M'kay. Not quite sure how that differs from my use case, which works quite
well with the "config" way. My `git remote | wc -l` says 21.
Let me re-format what you said next.
> 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.
So if I understand correctly, you want to do
(1) `git remote -v | grep <part-of-the-url>`
(2) `git remote show <shortname>`
(3) if (1) did not find it:
`git remote add -f <short-name> <URL>`,
otherwise:
`git fetch <shortname>`
(4) `git remove rm <shortname>`
I have to admit that I used `git remote -v | grep ^<shortname>` for (2)
all the time, until I had a quick look at builtin/remote.c so I would not
make a complete fool out of myself in this reply, and I will use `git -p
remote show <shortname>` henceforth.
As to (1), I really do not use this myself, as my remotes pretty much
always have names that I remember very well. And if I don't, neither do I
remember the URL, so I have to sift through the output of `git -p remote
-v` manually anyway.
> >> 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.
No, I was, and I am still at least partially confused. I just read your
"We simply cannot beat ..." as a round-about way to say "I wish we had an
easy way to do XYZ" without stating the XYZ in a way that even dimwits
such as myself can understand.
> 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.
Okay, so my quest at removing maintenance burden is not entirely pointless
an exercise and a waste of my time.
Good. I will continue to work on that front, then, among other things.
Ciao,
Dscho