git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Default remote branch for local branch

From
Junio C Hamano <junkio@cox.net>
Date
Apr 2, 2006, 21:40 UTC
Message-ID
<7v7j67k65b.fsf@assigned-by-dhcp.cox.net>
In-Reply-To
<200604021817.30222.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
Show 17 quoted lines
> On Saturday 01 April 2006 06:18, Pavel Roskin wrote:
>> On Fri, 2006-03-31 at 19:05 -0800, Junio C Hamano wrote:
>> > Maybe you would want something like this.
>> >
>> > In $GIT_DIR/config:
>> > 
>> > 	[pull]
>> > 	origin = linus for master
>> >         origin = irq-pio of libata for ata-irq-pio
>> >         origin = pata-drivers of libata for ata-pata
>
> 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". The implementation of the above would involve changes to git-fetch, because it needs to give ".not-for-merge" mark to different line in FETCH_HEAD depending on [<refspec> of] part.

> 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.
Show 12 quoted lines
>> Secondly, I think the relationship should be between a local development
>> branch and a local tracking branch.
>
> Agree.
> 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.
>
> This works automatically if git-pull only does upstream fetching if
> there is a remote branch associated. The default action of git-fetch
> similar could be "fetch the upstream branch, if that tracks a remote
> branch", using the same configuration.
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, which is a good change, 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).
        (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.  If not, skip the next step and go directly to
            (4).
        (3) run git-fetch (or svn/cvs-import) to update the
            tracking branch;
        (4) merge from that other local branch.
> Junio's proposal has the advantage that you do not have to search in all
> files in .git/remotes (and even .git/branches) for the remote branch that
> maps to a given local branch.
> But that is not the big issue.

A bigger thing is that I am trying to avoid _requiring_ tracking branches. 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, 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:

	$ git branch --describe ata-pata
        Typically merges from pata-drivers branch of
        	git://.../jgarzik/libata-dev.git
	which is tracked with local refs/remotes/libata/pata-drivers.
	$ git branch --decribe refs/remotes/libata/pata-drivers
	Tracking branch for pata-drivers branch of
               	git://.../jgarzik/libata-dev.git
	$ git checkout origin
        warning: you are checking out a tracking branch for "master" branch of
	warning:	git://.../torvalds/linux-2.6.git
	warning: commit/pull/merge commands are disabled.
	hint: you can still create a new branch from here.
Previous: Josef WeidendorferNext: Josef Weidendorfer
Message 5 of 15 in “Default remote branch for local branch”
  1. Pavel RoskinApr 1, 2006
  2. Junio C HamanoApr 1, 2006
  3. Pavel RoskinApr 1, 2006
  4. Josef WeidendorferApr 2, 2006
  5. Junio C HamanoApr 2, 2006
  6. Josef WeidendorferApr 2, 2006
  7. Andreas EricssonApr 3, 2006
  8. Josef WeidendorferApr 3, 2006
  9. Andreas EricssonApr 3, 2006
  10. Junio C HamanoApr 3, 2006
  11. Josef WeidendorferApr 3, 2006
  12. Petr BaudisApr 14, 2006
  13. Josef WeidendorferApr 14, 2006
  14. Jakub NarebskiApr 1, 2006
  15. Jakub NarebskiApr 1, 2006

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.