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@xxxxxxxxxxx
www.treskal.com/kalle
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html