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

From: Andrew Morton <akpm@linux-foundation.org>
Date: Jun 30, 2008, 22:51 UTC
Message-ID: <20080630155147.009a24b7.akpm@linux-foundation.org>
In-Reply-To: <7vabh2vaav.fsf@gitster.siamese.dyndns.org>

On Mon, 30 Jun 2008 15:15:52 -0700 Junio C Hamano <gitster@pobox.com> wrote:

Show 11 quoted lines

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