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 1, 2006, 03:05 UTC
Message-ID
<7vodzmngfp.fsf@assigned-by-dhcp.cox.net>
In-Reply-To
<1143856098.3555.48.camel@dv>
Pavel Roskin <proski@gnu.org> writes:
Show 6 quoted lines
> This is not a ready-to-use proposal, but I think my message can prompt
> useful changes in GIT or in the "porcelain".
>...
> I think it would be convenient to have git remember the remote branch
> for the given local branch.  git should know that if HEAD points to
> "local-B", "git-fetch" should fetch from "remote-B", not from "origin".

I am in favor of the general direction this is going. Something like this was mentioned on the list in the past twice (I think Johannes was involved in the discussion but I do not remember the details offhand).

My understanding is that Cogito uses $GIT_DIR/branches/$name file as a configuration file per branch - currently it only records which remote repository's what remote branch the local branch $name interfaces with.

The $GIT_DIR/remotes/$name file is to describe each remote repository, and it _wants_ to be able to describe all the branches we are interested in, primarily because uploading and downloading multiple, related heads at once is more efficient. How remote branches are kept track of with the local tracking branch, and how remote branches are updated from the local branch heads, are described by Push/Pull lines there.

As you pointed out, we do not have a convenient way to tell git where you typically merge things from per local branch. There are different patterns I've seen:

 - Promiscous.  For example, "master" branch of Linus repository
   pulls from many subsystem maintainers.  Linus could have one
   "remotes" file per subsystem maintainer he often pulls from
   (and "for-linus" branch name in each remote repository tends
   to stay the same), and unlike the rest of us he does not seem
   to pull into many local branches.  The current "remotes"
   setup is really optimized for this mode of usage (you can use
   "remotes" without having local tracking branches).
 - Merging topic branches into "master" (or "release") branch
   and "next" (or "testing") branch -- inside local repository.
 - CVS-like remote tracking.  A single "primary" remote branch
   is tracked using local "origin", merged into local "master"
   and pushed back to the remote.  Both Cogito-like branches/
   setup and having a single $GIT_DIR/remotes/origin file with
   single Push/Pull line would work equally well.
 - Multiple subsystem maintainer trees tracked in the same local
   repository.  Most generally, two local branches per each
   remote head can be used (one tracking branch to fetch into,
   another to build your changes based on it).  Alternatively,
   you can use one local branch per each remote head without
   using any tracking branch.

Your proposal to give default branch to pull from per the local branch would help only the last case. The first one you do not switch between local branches at all and pull from many different places; the second is to merge from different topic branches from time to time and does not benefit from fixed configuration; the third does not even need configuration.

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
In $GIT_DIR/remotes/linus:
	URL: git://git.kernel.org/.../torvalds/linux-2.6.git
	Pull: refs/heads/master:refs/heads/linus
In $GIT_DIR/remotes/libata
	URL: git://git.kernel.org/.../jgarzik/libata-dev.git
	Pull: refs/heads/irq-pio:refs/remotes/libata/irq-pio
	Pull: refs/heads/pata-drivers:refs/remotes/libata/pata-drivers

This is to maintain three local branches: master, ata-irq-pio and ata-pata.

You are obviously interested in the mainline Linus kernel, so while you are on your "master" branch, we will look for "pull.origin .* for master" and find out you would want remotes/linus file to be used. His "master" is copied to your local "linus" branch, and merged into your "master" branch.

	$ git pull
becomes equivalent to:
        $ git pull linus

You are also interested in the libata work by Jeff, and while you are on your ata-pata branch

	$ git pull
becomes roughly equivalent to:
	$ git pull libata pata-drivers

While we are on the topic, it _might_ be worthwhile to think about revamping the syntax of $GIT_DIR/remotes file, maybe even breaking backward compatibility. The Pull: lines can be independently specified which gives flexibility, but I suspect local tracking branches from the same remote tend to live in the same place; IOW, you would probably not do something like:

	URL: git://git.kernel.org/.../jgarzik/libata-dev.git
	Pull: refs/heads/irq-pio:refs/remotes/libata/irq-pio
	Pull: refs/heads/pata-drivers:refs/heads/pata-drivers
in practice.
Previous: Pavel RoskinNext: Pavel Roskin
Message 2 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.