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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Junio,

On Fri, 12 May 2017, Junio C Hamano wrote:

> Junio C Hamano <gitster@xxxxxxxxx> writes:
> 
> > Johannes Schindelin <johannes.schindelin@xxxxxx> 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.

I do not understand what you want to tell me with that example. It is
confusing me utterly.

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

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

Okay. But by the same reasoning, I want to hear nothing from you anymore
about the sort of maintenance burden you talked about in the ssh_variant
patches. That burden was ridiculously small compared to what you tell me
you want to keep (and for a single user that may have moved on). Not one
word.

Ciao,
Dscho



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]