Re: [PATCH 00/16] Cleanup {branches,remotes}-file cruft

Ramkumar Ramachandra [off-list ref] writes:

This is a cleanup operation to get rid of the historical
$GIT_DIR/{branches,remotes} cruft.  Mostly no-brainers that don't
deserve a second look.

Only reacting to "no-brainer".

The last time I hinted removal of .git/branches/, Andrew Morton
reminded me that there are those who use Git primarily to fetch from
many dozens of other people's branches, to maintain his own quilt
patch series on top of, and never push anything back.  To them,
being able to say

    $ echo the-repository-url#the-branch >.git/branches/the-subsys
    $ rm .git/branches/the-subsys

has been a much easier and simpler way than "git config".  The only
thing they do with them is essentially:

    $ git fetch the-subsys
    ... use FETCH_HEAD to integrate it to a larger whole
    ... against which his remaining quilt queue is rebuilt

I myself thought that replacing the established work process of
these people to the one that instead uses "git config" should be
simple enough even back then, and in the longer term, these old
mechanisms will become disused so that we can remove them, but
deciding _when_ is the good time is not a no-brainer at all.

Junio C Hamano wrote:

The last time I hinted removal of .git/branches/, Andrew Morton
reminded me that there are those who use Git primarily to fetch from
many dozens of other people's branches, to maintain his own quilt
patch series on top of, and never push anything back.  To them,
being able to say

    $ echo the-repository-url#the-branch >.git/branches/the-subsys
    $ rm .git/branches/the-subsys

has been a much easier and simpler way than "git config".  The only
thing they do with them is essentially:

    $ git fetch the-subsys
    ... use FETCH_HEAD to integrate it to a larger whole
    ... against which his remaining quilt queue is rebuilt

Interesting.  A cheap alias for a URL + branch that can be
added/removed very easily.  I suppose it's worth keeping around.

I myself thought that replacing the established work process of
these people to the one that instead uses "git config" should be
simple enough even back then, and in the longer term, these old
mechanisms will become disused so that we can remove them, but
deciding _when_ is the good time is not a no-brainer at all.

Oh, this series is not about removing the feature: it's about removing
dead code, testing the feature properly, and not mentioning it in
obscure places.  It is a prerequisite for removal, if we desire to do
that at some later point.  After your explanation, I think everything
but [16/16] is fine.  [16/16] adds a comment about deprecation; we
should tweak/drop it.