On Sunday 02 April 2006 23:40, you wrote: > > Let me try to understand this: the general idea is that > > > > pull.origin = [<refspec> of] <remote> for <branch> > > > > specifies the default action of git-pull if we are on <branch>, ie. > > a "git pull" then runs "git pull <remote> [<refspec>]". > > Not quite. > > It will be (if this were a serious proposal -- I am not > absolutely convinced this is a good idea) more like "git fetch > <remote>" followed by "git-merge HEAD the-refspec-named-there". So it is not really a <refspec>, but a <localbranch> which has to appear in the .git/remotes file on the right side of a refspec on a Pull line. Then, I think it is redundant to specify the <remote>, as this can be detected by looking at the .git/remotes files and searching for <localbranch>. > > So the example above, if .git/remotes/linus would contain two > > refspecs, and you are on the branch of the 2nd refspec, it would > > do the wrong thing: merge the 1st refspec with current branch. > > Sorry I fail to visualize this part. All I wanted to remark is, that, with URL: <remote-URL> Pull: refs/head/master:refs/head/remote1 Pull: refs/head/other:refs/head/remote2 the config pull.origin = <remote> for refs/head/my-devel-for-remote2 which does not use the [<refspec> of] part, always is bogus: We get remote1 merged into my-devel-for-remote2 on a git-pull, which is not what we want. > > It is also useful to specify this relation if the upstream is purely a > > local branch, e.g. when branching off a local branch, and you want to > > pull in changes from the local upstream. > > Interesting. > > You would need sanity checker for $GIT_DIR/remotes/* files if > you do this to make sure no local tracking branch is by mistake > configured to track two remote branches, Why should this always be a mistake? If you have two developers doing topic branches for you, you could use this type of config to make "git-pull" fetching both remotes, and creating an octopus merge. And for your "next", you could use this to make "git-pull" merge both from the stable branch and all topics. > which is a good change, The sanity checker probably should be put into a branch attribute editor which allows to add the config discussed here. And it should only print a warning when you are trying to add multiple upstreams. > but then: > > git-pull, without parameter, would: > > (1) check if this branch has any local branch it usually > merges from; if not, do whatever we traditionally > did (or barf). Yes. This is simply looking up the config. We could automatically add such a config when branching off to specify the upstream of a branch. And git-clone should set this, too, and: We get rid of the current "origin" hardcoded special handling. Optionally, branching <new> off from <old> could add <new> as topic branch of <old>: Thus, if you are on <old> and do git-pull, you get <new> merged in. > (2) if there is a local branch it merges from, check if > it is a tracking branch for a remote, by looking at > remotes/* files. It would be nice if we could > detect tracking branches fed from external svn/cvs > repositories via svn/cvs-import this way at this > time. Good idea. I suppose this needs an entry in .git/remotes like URL: ... Type: SVN > If not, skip the next step and go directly to > (4). > > (3) run git-fetch (or svn/cvs-import) to update the > tracking branch; If (1) found multiple branches, do (2)/(3) for every branch. > (4) merge from that other local branch. Or for multiple, do an octopus. > A bigger thing is that I am trying to avoid _requiring_ tracking > branches. I don't think you force anything when you add functionality to git-pull for the config discussed here. Nobody *has* to use this config - it's a porcelain thingie. Cogito could use this, too. AFAIK, it has the same origin/master hardcoded tracking behavior. > If you are not micromanaging your subsystem > maintainers, you should not have to care where they were the > last time you pulled from them. You should be able to just > pull, examine what the merge brings in, and decide it is worth > merging. If it isn't, do a "reset", tell them "not good, please > rework and let me know when you are ready," and forget about it. > > If we are going require tracking branches, I do not understand. Why should we require this? > we could do a bit > more with them, like remembering where the tip was when we > fetched the last time (or the time before that...) and diff with > that, but the tracking branch heads are not set up to do things > like that right now -- they are single pointers. > > >> Perhaps you are missing a remotes editor command? > > Perhaps. Also perhaps a remotes/ sanity checker. > Something like this: > ... Doing this as part of git-branch sounds good. Josef - : 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