Re: [PATCH 4/5] Add --remote option to send-pack

[Junio C Hamano <junkio@cox.net>]

Daniel Barkalow <barkalow@iabervon.org> writes:

> Wouldn't it be better to to this as:
>
> [remote "origin"]
> 	url = git.kernel.org:/pub/scm/git/git.git/
> [branch "master"]
> 	remote = origin
> 	merge = refs/heads/master

As I am likely to pull from other people, and I happen to expect
the old fashioned "git pull gfi" without explicit refspec on the
command line to get the first Pull: line from remotes file to
tell which one to merge from, I am in favor of _not_ having that
[branch "master"] stuff in my repository.

remote.*.fetch is about what remote branches are fetched;
tracking may or may not happen as a side effect.  What I do with
the resulting .git/FETCH_HEAD is my business and branch.*.merge
should _not_ be the only way to access it.

> Merging without tracking is fine, in general; the "without tracking" was 
> intentionally parenthetical. 

Actually, fetching with or without tracking are both valid
options, and it does not make much sense to say which one is
norm and which one is exception.

> I just don't think always merging a 
> particular remote head into the current branch, regardless of what branch 
> is current, is a good idea.

Exactly.  That's why I do not think [branch "master"] for
toplevel maintainer usage is not very useful.

There are a few improvements we probably would want.

One is the interaction between the config "fetch =..." refspecs
and the command line ones.  Currently the rule is:

 - If you do not say refspecs on the command line, fetch config
   (or Pull: lines from remotes/* file) are used.

 - If you do have refspecs on the command line, fetch config are
   not used (they are ignored).

Which is fine when we talk about "git fetch", but if you _are_
using remote tracking, and if you are running "git fetch" as an
implementation detail of running "git pull" (IOW, you said "git
pull origin next"), it is less than optimum.  Instead of "only
fetch 'next' without tracking and then merge it", we would
certainly want "fetch to track everything as usual, and then
merge 'next' instead of what is usually merged".

Another thing is that which branch is merged into the current
branch should not be a function of the current branch, as the
current configuration mechanism suggests.  The current way maps
the current branch to "which repository's which branch".  In
addition to that, I think it should be a function of ("current
branch", "remote repository") pair.  IOW, allow you to say "If I
pull from this remote without saying which one to merge, merge
that branch.  If I pull from this other remote, merge that other
branch".  Something like:

        [branch "master"]
                ; Use this when "git pull" did not say which remote
                remote = origin

                ; Use this when "git pull origin" did not say which
                ; branch(es) to merge
                merge = refs/heads/master
                ; the above should be a synonym for
		; merge = refs/heads/master for origin

                ; "git pull fast-import" while on my "master"
                ; would merge 'for-junio' branch there.
                merge = refs/heads/for-junio for fast-import

                ; similarly, but use subtree strategy.
                merge = refs/heads/for-junio with subtree for git-gui

        [remote "origin"]
                url = git://git.kernel.org/pub/scm/git/git.git/
                fetch = refs/heads/*:remotes/origin/*
        [remote "fast-import"]
                url = git://repo.or.cz/git/fastimport.git/
                fetch = refs/heads/*:remotes/gfi/*
        [remote "git-gui"]
                url = git://repo.or.cz/git-gui.git/
                fetch = refs/heads/*:refs/remotes/git-gui/*