On Sat, 5 May 2007, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@xxxxxxxxxxxx> 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.
Ah, okay. So FETCH_HEAD gets: (1) if something is specified on the
command line, that; (2) if there is a branch.*.merge, that; (3) the first
refspec (without a *?) listed in remote.*.fetch. Right?
> 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".
I think that might be confusing; I'd expect that the tracking for next
would be updated, but the tracking for other heads wouldn't. I'm not sure
I'd ever actually complain about origin/master being more up-to-date than
can be intuitively explained, but I don't think a "git pull origin next"
would make me expect origin/master to be up-to-date right after. So I'd
say, "only fetch 'next'; if you track 'next' normally, update that."
On the other hand, I've been doing a lot of "git diff origin all-my-work"
and removing hunks I don't want to send, and this makes the implicit
assumption that origin == merge_base(origin, all-my-work), which is true
only because I merge origin whenever I fetch it.
> 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/*
I think this is a good feature, but maybe the syntax should be:
merge = fast-import refs/heads/for-junio
since the remote name is user-chosen, arbitrary, and has to be typed on
the command line, and therefore people won't put in spaces, and "git fetch
fast-import refs/heads/for-junio" is what you'd type on the command line
that this abbreviates, so it's intuitive.
-Daniel
*This .sig left intentionally blank*
-
To unsubscribe from this list: 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