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

From: Junio C Hamano <junkio@cox.net>
Date: Nov 27, 2005, 00:38 UTC
Message-ID: <7vpsomorg9.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20051126235011.GA22159@pasky.or.cz>

Petr Baudis <pasky@suse.cz> writes:

Show 8 quoted lines

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

I agree. They are simply different things and serve different audiences.

When you are asked to pull from somebody else (and when you are playing an integrator role, not an individual developer role, you will be asked to pull from different people) you may not want to immediately pull into your master branch. I usually either do "git checkout -b throwaway master" and pull into it, or run "git fetch remote master:throwaway" followed by "git diff master throwaway" to see what I'll be getting. When you set up one "remotes" file is when you realize that you are pulling this way from the same place number of times, to reduce future typing. So as Pasky says, it is exactly "macro" and not "per branch configuration". It is just "per remote shorthand".

Cogito "branch" matches very naturally to what an individual developer might want to do. You have one branch that you use to do your work tracking one upstream. You can of course have more than one upstream and branch, but the most typical usage would be traditional CVS style setup to get updates from the central location (described in branches/* file), fetch and merge from there and push your changes back. It is very well designed to support this pattern of usage.

It may not make much sense for an integrator-role person to have branches/master file to configure his "master" branch that points at the URL of only one of his subsystem maintainers. An integrator-role person does not need "per branch" configuration in that sense. On the other hand "remotes" may help if the integrator-role person regularly pulls from the same set of subsystem maintainers.

Of course, an individual developer can set up a single remotes file that describes the single upstream, fetching "master:origin" and merging into his "master"; what "remotes" file used that way does not give us, unlike "branch" of Cogito, is that it does not say on which local branch that fetching and merging happens.