Josef Weidendorfer <Josef.Weidendorfer@xxxxxx> writes: > On Sunday 14 May 2006 19:36, Junio C Hamano wrote: >> Josef Weidendorfer <Josef.Weidendorfer@xxxxxx> writes: >> >> > On Saturday 13 May 2006 23:22, you wrote: >> >> * remotes/ information from .git/config (js/fetchconfig) >> >> ... >> >> [branch "master"] >> >> remote = "ko-private" > > I still do not understand the semantic of this line. > Is this supposed to do "git pull ko-private" as default pull > action and "git push ko-private" as default push? > > So using > >> ; my private build areas on the kernel.org machines >> [remote "ko-private"] >> url = "x86-64-build.kernel.org:git" >> url = "i386-build.kernel.org:git" >> push = master:origin >> ... > > specifies that "git push" should push to both URLs? Exactly. I would _want_ to push to both with single action when I say "git push ko-private". Actually I have _never_ felt need to, but Linus wanted it first and I think it makes sense. > This is really confusing: Is the remote "ko-private" now at > "x86-64-build.kernel.org:git" or at "i386-build.kernel.org:git" ? Neither. Perhaps reading my comment on #git log from yesterday or so, where I talk about ".git/branches is about configuration per-local branches, and .git/remotes is about giving a short-hand to remote repositories that are used often", might be helpful. > Neverless, I missed the info "Which branch should be merged in a default > pull after fetching the given branches from remote". I understand that > this is not needed in your workflow, as you have no upstream. Not with git but in other projects I do. That is what "branch.foo.remote = this-remote" is about. When working on foo branch, use what is described in remote."this-remote" section for "git pull". remote."this-remote" would have url and one or more fetch lines, and as usual the first fetch line would say "merge this thing". This gives the continuity in semantics while migrating from .git/remotes/foo to [remote "foo"] section of the config file. >> > [branch "ko-master"] >> > tracksremote = "master of ko-private" >> > >> > This also would specify that we are not allowed to commit on "ko-master". >> >> For my workflow, it is "master of ko"; your notation expresses >> the same constraints more explicitly by being more special >> purpose > > Why is this more special purpose? It is more special purpose than just saying "do not touch this myself". You are saying "do not touch this myself because it tracks a remote". I do not think it is necessary to state the reason. > Perhaps an option "when pulling into this branch from a remote, also fetch > all branches tracked from this remote", or another one "when fetching/pulling > into this branch, update all other branches, too". You already have "when fetching from this remote, fetch all these branches and store them in the tracking branches", and that is what .git/remotes/ is about. The [remote] section in the configuration file has the same semantics. What problem are you trying to fix by doing things differently? - : 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