Re: git bug? + question

From: Karl Hasselström <kha@treskal.com>
Date: Nov 3, 2006, 07:48 UTC
Message-ID: <20061103074857.GA15972@diana.vm.bytemark.co.uk>
In-Reply-To: <7v4pthmew1.fsf@assigned-by-dhcp.cox.net>

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