Re: Default remote branch for local branch

[Josef Weidendorfer <Josef.Weidendorfer@gmx.de>]

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