Re: What's cooking in git.git (topics)

Kristian Høgsberg [off-list ref] writes:

On Mon, 2008-06-30 at 02:08 -0700, Junio C Hamano wrote:
...

quoted

It already is beginning to become clear what 1.6.0 will look like.  What's
already in 'next' all are well intentioned (I do not guarantee they are
already bug-free --- that is what cooking them in 'next' is for) and are
good set of feature enhancements.  Bigger changes will be:

...
A small detail I've suggested scheduling for 1.6 before is removing (or
rather, stop creating) the empty .git/branches directory.  How does that
sound?

What's the benefit of the removal that outweighs the downside?  I can
imagine two contradicting voices from new end users.

 (1) With current git, I ran "git init" and I have an empty
     .git/branches/, but my remote information created with "git clone"
     and "git remote add" all go to .git/config these days.  Why do I have
     to have this empty directory that I do not use?

 (2) It is documented that "git fetch" can use files in .git/branches/ as
     the source specification, but when I ran "git init", it does not
     create the directory with Kristian's git. I need to do an extra
     "mkdir .git/branches/" myself.  Why?

You are obviously coming from the former camp, but do you have a good
answer to people from the other camp?

I do not recall if Cogito required to have .git/branches created by us or
it can create it on demand if we don't.  If the latter, that would be
great, otherwise remaining users would be in the latter camp as well, and
we may have to make sure Cogito is really dead already (or wait for it to
die), or Cogito gets updated for its remaining users to tolerate the
initial lack of the directory (and wait for that version percolates down
to the users).

Some people rely on (or at least "like") the convenience of being able to
create a single-liner file in .git/branches/ to easily add, and remove
such a file to easily remove where they integrate from.  This is
especially so when they have dozens of source repositories to fetch from.
I do not think we want to remove support for .git/branches as a way to
specify fetch sources (this is why I am CC'ing Andrew who I know uses
branches, and Stephen who is also a heavy integrator even though I do not
know if he is in branches camp or uses more modern style), but they now
have to do an extra "mkdir .git/branches" after "git init" to continue
their workflow if we adopt the change you are proposing here.  It is not a
big deal, but it still is a backward incompatible change.