config.txt: update branch.<name>.merge documentation
PATCH 1/1 config.txt: update branch.<name>.merge documentation
--- Documentation/config.txt | 7 ++++--- 1 files changed, 4 insertions(+), 3 deletions(-)
Documentation/config.txt +4 -3
@@ -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::
Signature · 1 line
1.5.0.rc2.579.g7df8
Documentation/config.txt branch.<name>.remote:: · line 237
Quoted 12 lines · Santi Béjar
Documentation/config.txt +2
-2@@ -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,
Signature · 1 line
Yann.
Quoted 17 lines · Yann Dirson
Documentation/config.txt branch.<name>.remote:: · line 237
Quoted 12 lines · Santi Béjar
Documentation/config.txt +2
-2@@ -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.
Quoted 4 lines
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
Quoted 6 lines · Santi Béjar
Quoted 3 lines
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.
Documentation/config.txt branch.<name>.remote:: · line 237
Quoted 10 lines · Santi Béjar
Documentation/config.txt +2
-2@@ -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
Documentation/config.txt branch.<name>.remote:: · line 242
Quoted 6 lines
Documentation/config.txt +2
-1The 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
Quoted 13 lines · Santi Béjar
Documentation/config.txt branch.<name>.remote:: · line 237
Quoted 10 lines · Santi Béjar
Documentation/config.txt +2
-2@@ -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.