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

On Mon, 30 Jun 2008 15:15:52 -0700
Junio C Hamano [off-list ref] wrote:

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.

I do find the more compact format of .git/branches/git-foo to be
convenient.  For example, my scripts go looking in there for the URL
and add that to the patch changelog so that people can reconstruct -mm's
git-foo.patch from the relevant git tree.

That being said,

- It wouldn't bother me to have to type `mkdir .git/branches' after
  `git init'!

- It's bad to have the same info in two places, and to have to
  support two different ways of doing the same thing for ever.  So I
  could understand a wish to remove .git/branches/ support completely. 
  I'll cope :)

  For me the biggest part of migrating would be working out what on
  earth the format of the new files is.  Maybe it's documented
  somewhere undiscoverable, dunno.