On Mon, 30 Jun 2008 15:15:52 -0700 Junio C Hamano <gitster@xxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
