2006/7/24, Junio C Hamano <junkio@xxxxxxx>:
Santi Béjar <sbejar@xxxxxxxxx> writes: > It extracts all the information for pull from the config file. > > If you have a config file as: > > [branch "master"] > remote=origin > merge=next #the remote name > octopus=octopus > twohead=recursive >
[...]
I am in general in agreement with this line of thought and had an impression that many on the list wanted to have per-branch configuration. I am a bit too tired now so I'd just let you know I am interested but would not apply it tonight. Opinions? Comments? Anything missing or objectionable on Santi's patch from the list?
Actually my patch is a RFC to agree on the config semantics, (although I do not mind if committed to "pu" :) : .- are remote/merge good names? .- the merge key is the name of the remote branch. .- are the octopus and twohead OK? .- for a local merge, is remote=. OK? .- "git pull ." to mean: do not fetch anything but merge the default branch? .- for the integrator case: * is the "merge= rembranch from remote" OK? * "git pull remotename" should read the branch properties if branch.$curr_branch.remote=remotename? * It could be usefull to have a git-merge-seq that performs a twohead merge sequentially instead of an octopus. The patch as is works for me and it currently depends on the remote config being in .git/config. It only touchs git-pull, just to have a working prototype of the semantics and to minimize the breakage, but it could be that it should be integrated in the git-parse-remote. Santi - : 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