Re: [PATCH 3/3] fetch: optionally store the current remote information in the config

From: sean <seanlkml@sympatico.ca>
Date: Apr 30, 2006, 16:37 UTC
Message-ID: <BAYC1-PASMTP03034CC49FFA3042562BCBAEB00@CEZ.ICE>
In-Reply-To: <Pine.LNX.4.63.0604301743370.3641@wbgn013.biozentrum.uni-wuerzburg.de>

On Sun, 30 Apr 2006 17:49:06 +0200 (CEST) Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Show 5 quoted lines

> > the terminology and help make things clear.  We're not storing "Pull:"
> > information, we're storing config/remote.$NICK.fetch data.  It's really
> > used just by fetch, pull just happens to call fetch.
>
> I have no strong feelings either way.

Yeah, once you "get" it, it's not a problem; but it's not easy when you're just learning git to separate fetch and pull. It's made harder if git can't even keep them straight internally. :o/

[...]

> The latter should be done, because "git fetch" really is about fetching, 
> not playing games with the config.

Then we should also remove the --store option from pull and fetch. It can be set with git-repo-config.

> FETCH_HEAD can contain multiple refs.

Which head does git-pull then use to merge, all of them?

> And I don't get the part about fetching from multiple remotes: 
> my patch does not allow for that.

Actually it does :o) User just needs multiple remote.$nick.url entries in his config.

> But it does! Note the "uri_[current_uri++]" part of the patch.

[...]

Show 5 quoted lines

> No. It is only used when there were no refspecs specified on the command 
> line:
> 
>         if (refspec_nr == 0)
>                 set_refspecs((const char**)refspecs_, current_refspec);

Right you are, on both counts.

Sean