On Sun, 30 Apr 2006 15:24:22 +0200 (CEST) Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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@xxxxxx> > > --- > > 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. Along that same line of reasoning, it seems more appropriate to use git fetch --store ... rather than git pull --store ... to set this information. 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? 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. 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? 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. Sean - : 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