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

Petr Baudis [off-list ref] writes:

quoted

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.