Re: git bug? + question

On 2006-11-02 18:40:30 -0800, Junio C Hamano wrote:

which is efficient (guaranteed to do only one fetch from remote) and
convenient.

Hmm, this is interesting. 99% of the time, I use "git fetch", followed
by "git pull . remotes/origin/foo" (often having run gitk in between
the two in order to see what's coming). I like to know what I'm
pulling (yes, I know how to undo a bad pull, but still ...).

And I also would need to have per-branch configuration to merge from
". remotes/origin/$b" without re-fetching while on a non-master
branch $b, for the above to work.

This is a good point. The "remotes/$repo/$branch" names are quite a
mouthful to type, so default pull sources would be a definite
improvement. (It would also be an improvement for the case when the
user is susceptible to the human factor.) Simply defaulting to pull
from the branch that this branch was cloned from should do the trick
(but the pull source should of course be editable).

I still need to remember to process "master" first, so all things
considered, this is a regression in usability for my workflow.

Where does this constraint come from?

But that is probably a minor inconvenience to a minority.  Most
of the world follow others' repositories that have a single
primary head, and defaulting to use separate-remote would help
them a lot.

I can attest that separate remotes is a usability win also when using
several branches from more than one remote source. It's actually
possible to infer from the branch name (remotes/$repo/$branch) which
branch from which repository is being tracked.

As an aside, in case of several remote repositories, "git fetch --all"
would be handy.

-- 
Karl Hasselström, kha@treskal.com