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

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: May 15, 2017, 08:42 UTC
Message-ID: <alpine.DEB.2.21.1.1705151022160.146734@virtualbox>
In-Reply-To: <xmqq7f1l6as6.fsf@gitster.mtv.corp.google.com>

Hi Junio,

On Sat, 13 May 2017, Junio C Hamano wrote:

Show 22 quoted lines

> Johannes Schindelin <Johannes.Schindelin@gmx.de> 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.

Show 13 quoted lines

> 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.

Show 10 quoted lines

> >> 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.

Show 5 quoted lines

> 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