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"
>
> Why is this line needed? In this example, what is the relationship
> of local "master" with the remote? I think it is enough to specify
> the local upstream branch:
>
> [branch "master"]
> origin = "ko-master"
I confused you by not describing the flow.
There are four repositories involved:
a. siamese:/git (my local development repo)
b. x86-64.kernel.org:~/git (my kernel.org build repo)
c. i386.kernel.org:~/git (ditto but for i386)
d. kernel.org:/pub/scm/git/git.git (public distribution point)
The workflow is:
1. maint/master/next/pu are prepared on a.
2. maint/master/next/pu are pushed to b. and c. as
maint/origin/next/pu. b. and c. always have their "master"
checked out.
3. I go to b. and c., and "pull . origin" to start my build
there on all four branches.
4. When things go well, I come back to a.
5. Then maint/master/next/pu are pushed to d. without renaming.
6. To keep track of what have been pushed, maint/master/next/pu
from d. are fetched to a., with ko- prefixed. There is no
"when on this branch" involved in this step. Regardless of
which branch I currently on, the fetch goes fine. I never
check out ko-* branches on a, nor merge from ko-* branches.
7. Go back to step 1 and start the next cycle. ko-maint, ko-master
and ko-next reminds me not to rewind maint/master/next while I
shuffle the changes to discard botched commits beyond them.
> So we need
>
> [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: "This tracks that one so never touch it any way other
than fetching into it" (we may not even allow checking out
"ko-master" -- I dunno).
One issue you might want to think about is it is far more
efficient to fetch multiple branches from the same git://... URL
is than fetching them one by one. The push has exactly the same
property.
Another thing is the above talks only about constraints, and the
user has to go all over the config file to find "xxx to
ko-private" in order to figure out what happens when he says
"pull ko-private".
>> ...
>> [remote "ko"]
>> url = "kernel.org:/pub/scm/git/git.git"
>> push = master:master
>> ...
>> fetch = master:ko-master
>
> These specifications more or less are independent from the above,
> as it specifies the defaults when fetching/pushing to the specified remote.
Not really; and what you introduced can conflict with [remote]
specification. If you have [branch "ko-master"] that says it
tracks remote "master" from "ko" repository, your [remote "ko"]
should have not say "fetch = foobla:ko-master", so in that sense
it is redundant and inviting later inconsistency. The only
information you added with "tracksremote" is the branch is used
to track what is on remote (implying we'd better not touch it
ourselves), so I'd say this would make sense
[branch "ko-master"]
tracksremote ; bool!
[remote "ko"]
url = git://git.kernel.org/pub/scm/git/git.git
fetch = master:ko-master
or alternatively this would:
[branch "ko-master"]
tracksremote = "master of ko"
[remote "ko"]
url = git://git.kernel.org/pub/scm/git/git.git
-
: 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