Jon Loeliger <jdl@xxxxxxxxxxxxx> writes:
> On Wed, 2007-08-22 at 00:11, Junio C Hamano wrote:
> ...
>> ;; new -- when on "master', and the user says to pull from "usb"
>> ;; without saying which branch to merge, use '[remote "usb"] url'
>> ;; and '[remote "usb"] fetch' to decide where to fetch from,
>> ;; and merge their refs/heads/xprm to our branch.
>> [branch "master:usb"]
>> merge = refs/heads/xprm
>>
>> The trick in the new syntax is that you cannot have a colon in
>> refname, so there is no way for existing [branch $name] section
>> to crash with the new style definition.
>
> Wasn't there was a brief alternate notion to add a "for <remote>"
> clause and allowing something like this?:
>
> [branch "master"]
> merge = refs/heads/xprm for usb
> merge = refs/heads/stuff for otherremote
Yeah, I remember that one (I do not think nobody implemented it,
though). Thanks for reminding.
So...
[branch "master"]
remote = origin
merge = refs/heads/xprm for usb
merge = refs/heads/stuff for otherremote
merge = refs/heads/master
and when you are on your "master",
$ git fetch
$ git pull
goes to "origin" (because you did not even say the remote name).
$ git fetch usb
$ git pull usb
goes to "usb". And "git pull" from such a nicknamed remote
looks up merge lines with "for nickname" to find the branch(es)
to merge. If there is no merge line with "for nickname" for the
remote (e.g. "git pull origin" in the above example does not
have any), and if there is a merge line without "for nickname",
then that line can be used (e.g. "git pull" which is exactly the
same as "git pull origin" will use the 'master' branch from the
remote).
I think that is much easier to understand and maintain for the
end users than the [branch "master:usb"]. The latter is wrong
to begin with -- it is not about branch anymore.
-
To unsubscribe from this list: 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
