Re: Get rid of .git/branches/ and .git/remotes/?

Dear diary, on Sun, Nov 20, 2005 at 08:50:41PM CET, I got a letter
where Johannes Schindelin [off-list ref] said that...

quoted

And I'm not 100% convinced that putting these branches in the config file 
has any real advantages over keeping them as separate files. Having 
everything in one place is nice, of course, and being able to copy just 
one file around might be convenient, but it _does_ make the config file 
more complicated.

And it _does_ make finding the information for less savvy git users more 
easy.

Is that so?

I'm not 50% convinced, but if people are excited about it, I can live
with it; in that case I would like appropriately powerful
git-repo-config, though - so that I can say "list me all branch.*
section names". Surely I could play some ugly grep games, but ideally,
I would like to avoid peeking into the .git/config file directly
altogether in Cogito - call that proper layering. ;-)

I'm not 100% convinced, either, but it could be a better concept than 
different files in different places and different formats basically doing 
the same.

But my thinking went like this: if Pasky and Junio can not agree on one 
location and format, and therefore none of the two is deprecated, how 
about giving them a way out they both might be able to agree to?

Now, those are just different concepts. Cogito's "branch" concept maps
single local head to a single remote head, 1:1. GIT's "remote" concept
maps (possibly not well-defined) bunch of local heads to a remote
repository (where they have same or different name) or a piece of it; to
accomplish this, it introduces a whole new rather complicated concept,
which nevertheless in part shares the namespace with heads (branches).

Surely, remotes are more flexible, but from the end-user perspective
they really act just as kind of "macros" compared to branches, except
that it's faster when you fetch multiple branches at once than when you
do it in sequence. I might add support for multibranch fetches to
Cogito, and I still intend to implement "readonly" remotes support for
the sake of compatibility with GIT, but I plan to stick to branches
otherwise. It's confusing enough to have remote and local heads, and
actually remotes make it even more confusing since you direct your
"direct touch" with the remote heads, now covered in some more abstract
entity.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.