[PATCH] config.txt: update branch.<name>.merge documentation

[PATCH] config.txt: update branch.<name>.merge documentation

[Santi Béjar]

Signed-off-by: Santi Béjar <sbejar@gmail.com>
---
 Documentation/config.txt |    7 ++++---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index e5e019f..f129de9 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -233,11 +233,12 @@ branch.<name>.remote::
 branch.<name>.merge::
 	When in branch <name>, it tells `git fetch` the default refspec to
 	be marked for merging in FETCH_HEAD. The value has exactly to match
-	a remote part of one of the refspecs which are fetched from the remote
-	given by "branch.<name>.remote".
+	the remote or local part of one of the refspecs which are fetched
+	from the remote given by "branch.<name>.remote".
 	The merge information is used by `git pull` (which at first calls
 	`git fetch`) to lookup the default branch for merging. Without
-	this option, `git pull` defaults to merge the first refspec fetched.
+	this option and when fetching a non default remote, `git pull`
+	defaults to merge the first refspec fetched.
 	Specify multiple values to get an octopus merge.
 
 color.branch::
-- 
1.5.0.rc2.579.g7df8

Re: [PATCH] config.txt: update branch.<name>.merge documentation

[Yann Dirson]

On Sat, Feb 03, 2007 at 04:29:40PM +0100, Santi Béjar wrote:
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index e5e019f..f129de9 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -233,11 +233,12 @@ branch.<name>.remote::
>  branch.<name>.merge::
>  	When in branch <name>, it tells `git fetch` the default refspec to
>  	be marked for merging in FETCH_HEAD. The value has exactly to match
> -	a remote part of one of the refspecs which are fetched from the remote
> -	given by "branch.<name>.remote".
> +	the remote or local part of one of the refspecs which are fetched
> +	from the remote given by "branch.<name>.remote".

Since both local and remote refs are allowed, it would be useful to
know how git-fetch decides how to handle them.  Looks like the 1st
fetch refspec with that ref on either side is selected.

git-parser-remote also looks branch.*.merge with --get-all, so it is
interesting to know what happens for multiple values (if git-fetch
just marks them all, how does git-pull react ?).  That's also useful
to know for porcelain writers wanting to parse FETCH_HEAD.

Best regards,
-- 
Yann.

Re: [PATCH] config.txt: update branch.<name>.merge documentation

[Santi Béjar]

On 2/3/07, Yann Dirson <ydirson@altern.org> wrote:
> On Sat, Feb 03, 2007 at 04:29:40PM +0100, Santi Béjar wrote:
> > diff --git a/Documentation/config.txt b/Documentation/config.txt
> > index e5e019f..f129de9 100644
> > --- a/Documentation/config.txt
> > +++ b/Documentation/config.txt
> > @@ -233,11 +233,12 @@ branch.<name>.remote::
> >  branch.<name>.merge::
> >       When in branch <name>, it tells `git fetch` the default refspec to
> >       be marked for merging in FETCH_HEAD. The value has exactly to match
> > -     a remote part of one of the refspecs which are fetched from the remote
> > -     given by "branch.<name>.remote".
> > +     the remote or local part of one of the refspecs which are fetched
> > +     from the remote given by "branch.<name>.remote".
>
> Since both local and remote refs are allowed, it would be useful to
> know how git-fetch decides how to handle them.  Looks like the 1st
> fetch refspec with that ref on either side is selected.

Yes, the first is selected.

>
> git-parser-remote also looks branch.*.merge with --get-all, so it is
> interesting to know what happens for multiple values (if git-fetch
> just marks them all, how does git-pull react ?).

The last sentence in the branch.<name>.merge says that it would
produce an octopus, is this enough?

Santi

Re: [PATCH] config.txt: update branch.<name>.merge documentation

[Yann Dirson]

On Sat, Feb 03, 2007 at 05:19:53PM +0100, Santi Béjar wrote:
> >git-parser-remote also looks branch.*.merge with --get-all, so it is
> >interesting to know what happens for multiple values (if git-fetch
> >just marks them all, how does git-pull react ?).
> 
> The last sentence in the branch.<name>.merge says that it would
> produce an octopus, is this enough?

D'oh, right.

Re: [PATCH] config.txt: update branch.<name>.merge documentation

[Santi Béjar]

On 2/3/07, Santi Béjar <sbejar@gmail.com> wrote:
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -233,11 +233,12 @@ branch.<name>.remote::
>  branch.<name>.merge::
>         When in branch <name>, it tells `git fetch` the default refspec to
>         be marked for merging in FETCH_HEAD. The value has exactly to match
> -       a remote part of one of the refspecs which are fetched from the remote
> -       given by "branch.<name>.remote".
> +       the remote or local part of one of the refspecs which are fetched
> +       from the remote given by "branch.<name>.remote".

It is OK, but

>         The merge information is used by `git pull` (which at first calls
>         `git fetch`) to lookup the default branch for merging. Without
> -       this option, `git pull` defaults to merge the first refspec fetched.
> +       this option and when fetching a non default remote, `git pull`
> +       defaults to merge the first refspec fetched.
>         Specify multiple values to get an octopus merge.

... but this is not. I interpreted it wrongly, sorry.

Santi

Re: [PATCH] config.txt: update branch.<name>.merge documentation

[Junio C Hamano]

"Santi Béjar" <sbejar@gmail.com> writes:

> On 2/3/07, Santi Béjar <sbejar@gmail.com> wrote:
>> --- a/Documentation/config.txt
>> +++ b/Documentation/config.txt
>> @@ -233,11 +233,12 @@ branch.<name>.remote::
>>  branch.<name>.merge::
>>         When in branch <name>, it tells `git fetch` the default refspec to
>>         be marked for merging in FETCH_HEAD. The value has exactly to match
>> -       a remote part of one of the refspecs which are fetched from the remote
>> -       given by "branch.<name>.remote".
>> +       the remote or local part of one of the refspecs which are fetched
>> +       from the remote given by "branch.<name>.remote".
>
> It is OK, but ...

Yeah, but I am starting to think that it was a mistake to allow
an additional way to express the same thing.

Reverting 80c797764 would make the implementation to match the
specification described in the original.