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

From: Petr Baudis <pasky@suse.cz>
Date: Nov 26, 2005, 23:50 UTC
Message-ID: <20051126235011.GA22159@pasky.or.cz>
In-Reply-To: <Pine.LNX.4.63.0511202039340.23586@wbgn013.biozentrum.uni-wuerzburg.de>

Dear diary, on Sun, Nov 20, 2005 at 08:50:41PM CET, I got a letter where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...

Show 8 quoted lines

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

Show 7 quoted lines

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