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

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Apr 30, 2006, 15:49 UTC
Message-ID: <Pine.LNX.4.63.0604301743370.3641@wbgn013.biozentrum.uni-wuerzburg.de>
In-Reply-To: <BAYC1-PASMTP08069B2CE6005391A1AFF9AEB00@CEZ.ICE>

Hi,

On Sun, 30 Apr 2006, sean wrote:

Show 29 quoted lines

> On Sun, 30 Apr 2006 15:24:22 +0200 (CEST)
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> 
> > Instead of editing files, you can now say
> > 
> > 	git pull --store junio \
> > 		git://git.kernel.org/pub/scm/git/git.git next:next
> > 
> > and next time, just
> > 
> > 	git pull junio
> > 
> > Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> > 
> > ---
> > 
> > 	This is what the patch series is all about.
> > 
> > 	If there is no interest in a feature like this, let's just forget
> > 	about the whole "remote info in config" thing.
> > 
> > 	If there is interest, I could add the same functionality to
> > 	builtin-push.
> 
> Well I agree with you that doing something like this is important.  We
> should take this moment of moving things to the config file to correct
> 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.

> Along that same line of reasoning, it seems more appropriate to use 
> git fetch --store ...  rather than git pull --store ... to set this
> information.

Both works.

> And there needs to be a way to change and delete the nick information, 
> perhaps git fetch store junio ""  would delete the entry. Or maybe 
> people should just be instructed to use git-repo-config for setting, 
> changing and deleting?

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

Show 6 quoted lines

> Pull needs additional logic that allows it to merge from the proper
> local branch after it calls fetch.  Right now it just uses whatever 
> fetch sets as FETCH_HEAD.  It's not clear to me what is set as 
> FETCH_HEAD when multiple refs are fetched from the remote.  It'll 
> be even more confusing once it's possible to fetch from multiple 
> remotes at once.

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

> As for these specific patches, it doesn't appear that your change to
> builtin-push allows the push variable to hold more than one remote 
> repo URI or even more than one refspec, or did I misread that?

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

> Also it seems that the refspec is used from the config file even if
> the user tries to override it by specifying an alternative on the
> command line.

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);

Ciao, Dscho