From: Santi <sbejar@gmail.com>
Date: Mon, 24 Jul 2006 12:58:52 GMT
Subject: Re: [RFC/PATCH] Per branch properties for pull
Message-ID: <8aa486160607240558n2b22c918v40cfcb26ed046472@mail.gmail.com>
In-Reply-To: <7vmzaze9xj.fsf@assigned-by-dhcp.cox.net>

2006/7/24, Junio C Hamano <junkio@cox.net>:
> Santi Béjar <sbejar@gmail.com> 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