On 11/16/06, Carl Worth <cworth@xxxxxxxxxx> wrote:
First, the pull may just fast-forward in which case there's no message at all. And we've been through that topic enough recently that we all know that no important information is lost by not doing any separate recording in that case. So you can't turn around and argue that the remote URL information is suddenly important when it just so happens that it's not a fast forward.
When it's a fast forward, the puller hasn't had to make any judgment calls, so there's no editorial history to record. When it's not, but the puller chooses to retain the result on a persistent branch, that _is_ an editorial decision (even if the result of the auto-merge is clean); I like having that in the history.
> And in a truly distributed situation, "pull" is strictly more powerful > than a separate "fetch" + separate "merge". I don't buy it. In my usage, I have several different remote repositories I'm interested in tracking, each with any number of branches. What I really want is an easy command that fetches all of those branches, (even new ones that I've never heard about---but never any of their "tracking branches" that wouldn't be of interest to me). And I want to do that once, to get the online-access-required part over with and get all the data into my local repository where I can start working with it.
What do you want all of those branches for? They haven't been published to you (that's a human interaction that doesn't go through git), so for all you know they're just upstream experiments, and doing things with them is probably shooting yourself in the foot. I do agree that a robust form of "for b in .git/remotes/*; do git fetch `basename $b`; done" would be a nice bit of porcelain. The entries in .git/remotes would probably need to grow a "Fetch-options:" field so that you could choose whether or not to follow tags, etc. Patch to follow. Cheers, - Michael - 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