On 12/8/06, Josef Weidendorfer <Josef.Weidendorfer@xxxxxx> wrote:
On Friday 08 December 2006 02:56, Santi Béjar wrote: > > [remote "repo"] > > url = ... > > fetch = branch1 > > fetch = branch2 > > > > [branch "mybranch1"] > > remote = repo > > merge = branch1 > > > > actually looks fine, and is the only possible way. > > But still, this does not work. > > It works for me. > > > You have to specify > > > > merge = refs/heads/branch1 > > It does not. > > The merge line must match exactly the remote part of the refspec. Yes, you are right; I just looked it up in git-parse-remote. Sorry about any confusion. > > > > > That's confusing (perhaps I can come up with a patch > > to allow "branch1" alone). > > > > So probably the best way is to write some more detailed > > explanation into the docu ... > > Perhaps that the branch.<name>.remote and branch.<name>.merge have the > equivalent meaning as the parameters of git-pull? We want to fetch multiple refs from one remote in a row. So what are you proposing? That branch.<name>.merge has to exactly specify one remote? I do not think this is needed.
I'm not proposing anything. What I wanted to say is that we could document the ...remote and ...merge configs as the default parameters of git-pull (this is how it is implemented already).
Actually, I am really for a new branch.<name>.localmerge option, and keeping branch.<name>.merge (but not advertising it).
I do not see anything wrong with the current ...remote and ...merge (see above), but I'm not against the ...localmerge config. Santi - 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