Re: Cleaning up git user-interface warts
- From
- Michael K. Edwards <medwards.linux@gmail.com>
- Date
- Nov 16, 2006, 17:57 UTC
- Message-ID
- <f2b55d220611160957s2e68059dk99bbe902e7e1f416@mail.gmail.com>
- In-Reply-To
- <87fycjs5yg.wl%cworth@cworth.org>
On 11/16/06, Carl Worth <cworth@cworth.org> wrote:
Show 8 quoted lines
> 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.
Show 11 quoted lines
> > 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,