{"thread":{"id":"6842","subject":"[PATCH/RFC 0/3] Split fetch and merge logic","startedAt":"2007-02-16T08:06:00Z","lastAt":"2007-02-20T11:21:56Z","messageCount":14,"participants":["Santi Béjar","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":3},"messages":[{"id":"34781","messageId":"874ppmplw7.fsf@gmail.com","threadId":"6842","inReplyTo":null,"subject":"[PATCH/RFC 0/3] Split fetch and merge logic","fromName":"Santi Béjar","fromEmail":"sbejar@gmail.com","sentAt":"2007-02-16T08:06:00Z","receivedAt":"2007-02-16T08:06:00Z","isPatch":true,"sender":{"key":"santi@agolina.net","avatar":null},"body":"\nThis series implements the split of the fetch and merge logic.\n\nThe first patch adds tests for the merge logic. It is very extensive and\nexpensive (in time), so I just post this to show that (almost) nothing\nchanges (although some part of if could be included). And the third\npatch shows what changes.\n\nSanti Béjar (3):\n      t/t5515-fetch-merge-logic.sh: Added tests for the merge login in git-fetch\n      git-fetch: Split fetch and merge logic\n      t/t5515: fixes for the separate fetch and merge logic\n"},{"id":"34783","messageId":"87vei2o75x.fsf@gmail.com","threadId":"6842","inReplyTo":"874ppmplw7.fsf@gmail.com","subject":"[PATCH/RFC 2/3] git-fetch: Split fetch and merge logic","fromName":"Santi Béjar","fromEmail":"sbejar@gmail.com","sentAt":"2007-02-16T08:09:30Z","receivedAt":"2007-02-16T08:09:30Z","isPatch":true,"sender":{"key":"santi@agolina.net","avatar":null},"body":"\ngit-fetch fetches the branches from the remote and saves this\ninformation in .git/FETCH_FETCHED, and at the end it generates\nthe file .git/FETCH_HEAD.\n\nThere are two cases where the behaviour is changed:\n\n1) branch.*.merge no longer must exactly match the remote part\n   of the branch fetched. Both are expanded in full (as refs/heads/...)\n   and matched afterwards.\n2) When the remote is specified with $GIT_DIR/branches/... and there is\n   a branch.*.merge, the remote branch name must match to get them merged.\n   Before the branch in $GIT_DIR/branches/... was always merged.\n   In the documentation the $GIT_DIR/branches/ is documented as a\n   short-hand for a corresponding file in $GIT_DIR/remotes/, so I think\n   this makes the new behaviour consistent.\n\nSigned-off-by: Santi Béjar <sbejar@gmail.com>\n---\n Documentation/config.txt |    2 +-\n git-fetch.sh             |   74 ++++++++++++++++++++++++++-------------------\n git-parse-remote.sh      |   60 +++++++++----------------------------\n t/t5510-fetch.sh         |   16 ++++++++++\n 4 files changed, 75 insertions(+), 77 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 9620126..e695de5 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -238,7 +238,7 @@ branch.<name>.remote::\n \n branch.<name>.merge::\n \tWhen in branch <name>, it tells `git fetch` the default refspec to\n-\tbe marked for merging in FETCH_HEAD. The value has exactly to match\n+\tbe marked for merging in FETCH_HEAD. The value has to match\n \ta remote part of one of the refspecs which are fetched from the remote\n \tgiven by \"branch.<name>.remote\".\n \tThe merge information is used by `git pull` (which at first calls\ndiff --git a/git-fetch.sh b/git-fetch.sh\nindex ca984e7..727538d 100755\n--- a/git-fetch.sh\n+++ b/git-fetch.sh\n@@ -77,9 +77,9 @@ do\n \tshift\n done\n \n+origin=$(get_default_remote)\n case \"$#\" in\n 0)\n-\torigin=$(get_default_remote)\n \ttest -n \"$(get_remote_url ${origin})\" ||\n \t\tdie \"Where do you want to fetch from today?\"\n \tset x $origin ; shift ;;\n@@ -101,6 +101,7 @@ if test \"\" = \"$append\"\n then\n \t: >\"$GIT_DIR/FETCH_HEAD\"\n fi\n+: >\"$GIT_DIR/FETCH_FETCHED\"\n \n # Global that is reused later\n ls_remote_result=$(git ls-remote $exec \"$remote\") ||\n@@ -112,10 +113,6 @@ append_fetch_head () {\n     remote_name_=\"$3\"\n     remote_nick_=\"$4\"\n     local_name_=\"$5\"\n-    case \"$6\" in\n-    t) not_for_merge_='not-for-merge' ;;\n-    '') not_for_merge_= ;;\n-    esac\n \n     # remote-nick is the URL given on the command line (or a shorthand)\n     # remote-name is the $GIT_DIR relative refs/ path we computed\n@@ -146,9 +143,7 @@ append_fetch_head () {\n     if git-cat-file commit \"$head_\" >/dev/null 2>&1\n     then\n \theadc_=$(git-rev-parse --verify \"$head_^0\") || exit\n-\techo \"$headc_\t$not_for_merge_\t$note_\" >>\"$GIT_DIR/FETCH_HEAD\"\n-    else\n-\techo \"$head_\tnot-for-merge\t$note_\" >>\"$GIT_DIR/FETCH_HEAD\"\n+\techo \"$headc_\t$remote_name_:$local_name_\t$note_\" >>\"$GIT_DIR/FETCH_FETCHED\"\n     fi\n \n     update_local_ref \"$local_name_\" \"$head_\" \"$note_\"\n@@ -256,7 +251,7 @@ then\n \t\t  git-show-ref --exclude-existing=refs/tags/ |\n \t          while read sha1 name\n \t\t  do\n-\t\t\techo \".${name}:${name}\"\n+\t\t\techo \"${name}:${name}\"\n \t\t  done` || exit\n \tif test \"$#\" -gt 1\n \tthen\n@@ -279,13 +274,6 @@ fetch_main () {\n \n       # These are relative path from $GIT_DIR, typically starting at refs/\n       # but may be HEAD\n-      if expr \"z$ref\" : 'z\\.' >/dev/null\n-      then\n-\t  not_for_merge=t\n-\t  ref=$(expr \"z$ref\" : 'z\\.\\(.*\\)')\n-      else\n-\t  not_for_merge=\n-      fi\n       if expr \"z$ref\" : 'z+' >/dev/null\n       then\n \t  single_force=t\n@@ -366,7 +354,7 @@ fetch_main () {\n       esac\n \n       append_fetch_head \"$head\" \"$remote\" \\\n-\t  \"$remote_name\" \"$remote_nick\" \"$local_name\" \"$not_for_merge\" || exit\n+\t  \"$remote_name\" \"$remote_nick\" \"$local_name\" || exit\n \n   done\n \n@@ -409,28 +397,16 @@ fetch_main () {\n \t      case \"$ref\" in\n \t      +$remote_name:*)\n \t\t  single_force=t\n-\t\t  not_for_merge=\n-\t\t  found=\"$ref\"\n-\t\t  break ;;\n-\t      .+$remote_name:*)\n-\t\t  single_force=t\n-\t\t  not_for_merge=t\n-\t\t  found=\"$ref\"\n-\t\t  break ;;\n-\t      .$remote_name:*)\n-\t\t  not_for_merge=t\n \t\t  found=\"$ref\"\n \t\t  break ;;\n \t      $remote_name:*)\n-\t\t  not_for_merge=\n \t\t  found=\"$ref\"\n \t\t  break ;;\n \t      esac\n \t  done\n \t  local_name=$(expr \"z$found\" : 'z[^:]*:\\(.*\\)')\n \t  append_fetch_head \"$sha1\" \"$remote\" \\\n-\t\t  \"$remote_name\" \"$remote_nick\" \"$local_name\" \\\n-\t\t  \"$not_for_merge\" || exit\n+\t\t  \"$remote_name\" \"$remote_nick\" \"$local_name\" || exit\n         done\n       )\n     ) || exit ;;\n@@ -454,7 +430,7 @@ case \"$no_tags$tags\" in\n \t\tdo\n \t\t\tgit-cat-file -t \"$sha1\" >/dev/null 2>&1 || continue\n \t\t\techo >&2 \"Auto-following $name\"\n-\t\t\techo \".${name}:${name}\"\n+\t\t\techo \"${name}:${name}\"\n \t\tdone)\n \tesac\n \tcase \"$taglist\" in\n@@ -482,3 +458,39 @@ case \"$orig_head\" in\n \tfi\n \t;;\n esac\n+\n+# Generate $GIT_DIR/FETCH_HEAD\n+case \",$#,$remote_nick,\" in\n+,1,$origin,)\n+\tcurr_branch=$(git-symbolic-ref -q HEAD | sed -e 's|^refs/heads/||')\n+\tmerge_branches=$(git-repo-config \\\n+\t\t--get-all \"branch.${curr_branch}.merge\")\n+\t[ -z \"$merge_branches\" ] && merge_first=yes;;\n+,1,$remote,) merge_branches=HEAD;;\n+,1,*)merge_first=yes ;;\n+*)\n+\tshift\n+\tmerge_branches=$(for ref; do\n+\t\texpr \"z$ref\" : 'z.*:' >/dev/null || ref=\"${ref}:\"\n+\t\techo \"$(expr \"z$ref\" : 'z\\([^:]*\\):')\"; done);;\n+esac\n+\n+test \"$merge_first\" == \"yes\" &&\n+test \"$(get_remote_default_refs_for_fetch -t $remote_nick)\" != \"explicit\" &&\n+merge_branches= && merge_first=\n+\n+merge_branches=$(canon_refs_list_for_fetch $merge_branches | sed 's/:.*$//g')\n+\n+cat \"$GIT_DIR\"/FETCH_FETCHED | while IFS='\t' read sha1 ref note ; do\n+\tremote_branch=$(expr \"z$ref\" : 'z\\([^:]*\\):')\n+\tfor merge_branch in $merge_branches ; do\n+\t\t[ \"$merge_branch\" == \"$remote_branch\" ] &&\n+\t\t\techo \"$sha1\t\t$note\" && continue 2\n+\tdone\n+\tif ! test \"$merge_first\" || test \"$merge_first\" == \"done\" ; then\n+\t\techo \"$sha1\tnot-for-merge\t$note\"\n+\telse\n+\t\techo \"$sha1\t\t$note\"\n+\t\tmerge_first=done\n+\tfi\n+done >> \"$GIT_DIR/FETCH_HEAD\"\ndiff --git a/git-parse-remote.sh b/git-parse-remote.sh\nindex 5208ee6..212b3bc 100755\n--- a/git-parse-remote.sh\n+++ b/git-parse-remote.sh\n@@ -70,8 +70,7 @@ get_remote_default_refs_for_push () {\n \tesac\n }\n \n-# Called from canon_refs_list_for_fetch -d \"$remote\", which\n-# is called from get_remote_default_refs_for_fetch to grok\n+# Called from get_remote_default_refs_for_fetch to grok\n # refspecs that are retrieved from the configuration, but not\n # from get_remote_refs_for_fetch when it deals with refspecs\n # supplied on the command line.  $ls_remote_result has the list\n@@ -130,30 +129,6 @@ expand_refs_wildcard () {\n \n # Subroutine to canonicalize remote:local notation.\n canon_refs_list_for_fetch () {\n-\t# If called from get_remote_default_refs_for_fetch\n-\t# leave the branches in branch.${curr_branch}.merge alone,\n-\t# or the first one otherwise; add prefix . to the rest\n-\t# to prevent the secondary branches to be merged by default.\n-\tmerge_branches=\n-\tcurr_branch=\n-\tif test \"$1\" = \"-d\"\n-\tthen\n-\t\tshift ; remote=\"$1\" ; shift\n-\t\tset $(expand_refs_wildcard \"$remote\" \"$@\")\n-\t\tis_explicit=\"$1\"\n-\t\tshift\n-\t\tif test \"$remote\" = \"$(get_default_remote)\"\n-\t\tthen\n-\t\t\tcurr_branch=$(git-symbolic-ref -q HEAD | \\\n-\t\t\t    sed -e 's|^refs/heads/||')\n-\t\t\tmerge_branches=$(git-config \\\n-\t\t\t    --get-all \"branch.${curr_branch}.merge\")\n-\t\tfi\n-\t\tif test -z \"$merge_branches\" && test $is_explicit != explicit\n-\t\tthen\n-\t\t\tmerge_branches=..this.will.never.match.any.ref..\n-\t\tfi\n-\tfi\n \tfor ref\n \tdo\n \t\tforce=\n@@ -166,18 +141,6 @@ canon_refs_list_for_fetch () {\n \t\texpr \"z$ref\" : 'z.*:' >/dev/null || ref=\"${ref}:\"\n \t\tremote=$(expr \"z$ref\" : 'z\\([^:]*\\):')\n \t\tlocal=$(expr \"z$ref\" : 'z[^:]*:\\(.*\\)')\n-\t\tdot_prefix=.\n-\t\tif test -z \"$merge_branches\"\n-\t\tthen\n-\t\t\tmerge_branches=$remote\n-\t\t\tdot_prefix=\n-\t\telse\n-\t\t\tfor merge_branch in $merge_branches\n-\t\t\tdo\n-\t\t\t    [ \"$remote\" = \"$merge_branch\" ] &&\n-\t\t\t    dot_prefix= && break\n-\t\t\tdone\n-\t\tfi\n \t\tcase \"$remote\" in\n \t\t'' | HEAD ) remote=HEAD ;;\n \t\trefs/heads/* | refs/tags/* | refs/remotes/*) ;;\n@@ -196,32 +159,39 @@ canon_refs_list_for_fetch () {\n \t\t   git-check-ref-format \"$local_ref_name\" ||\n \t\t   die \"* refusing to create funny ref '$local_ref_name' locally\"\n \t\tfi\n-\t\techo \"${dot_prefix}${force}${remote}:${local}\"\n+\t\techo \"${force}${remote}:${local}\"\n \tdone\n }\n \n # Returns list of src: (no store), or src:dst (store)\n get_remote_default_refs_for_fetch () {\n+\ttest \"$1\" == -t && type=yes && shift\n \tdata_source=$(get_data_source \"$1\")\n \tcase \"$data_source\" in\n \t'')\n-\t\techo \"HEAD:\" ;;\n+\t\tset explicit \"HEAD:\" ;;\n \tconfig)\n-\t\tcanon_refs_list_for_fetch -d \"$1\" \\\n-\t\t\t$(git-config --get-all \"remote.$1.fetch\") ;;\n+\t\tset $(expand_refs_wildcard \"$1\" \\\n+\t\t\t$(git-repo-config --get-all \"remote.$1.fetch\")) ;;\n \tbranches)\n \t\tremote_branch=$(sed -ne '/#/s/.*#//p' \"$GIT_DIR/branches/$1\")\n \t\tcase \"$remote_branch\" in '') remote_branch=master ;; esac\n-\t\techo \"refs/heads/${remote_branch}:refs/heads/$1\"\n+\t\tset explicit \"refs/heads/${remote_branch}:refs/heads/$1\"\n \t\t;;\n \tremotes)\n-\t\tcanon_refs_list_for_fetch -d \"$1\" $(sed -ne '/^Pull: */{\n+\t\tset $(expand_refs_wildcard \"$1\" $(sed -ne '/^Pull: */{\n \t\t\t\t\t\ts///p\n-\t\t\t\t\t}' \"$GIT_DIR/remotes/$1\")\n+\t\t\t\t\t}' \"$GIT_DIR/remotes/$1\"))\n \t\t;;\n \t*)\n \t\tdie \"internal error: get-remote-default-ref-for-push $1\" ;;\n \tesac\n+\tif [ \"$type\" ] ; then\n+\t\techo $1\n+\telse\n+\t\tshift\n+\t\tcanon_refs_list_for_fetch \"$@\"\n+\tfi\n }\n \n get_remote_refs_for_push () {\ndiff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh\nindex 50c6485..0a19a7d 100755\n--- a/t/t5510-fetch.sh\n+++ b/t/t5510-fetch.sh\n@@ -50,6 +50,22 @@ test_expect_success \"fetch test\" '\n \ttest \"z$mine\" = \"z$his\"\n '\n \n+test_expect_success \"fetch test fetched\" '\n+\tcd \"$D\" &&\n+\tcd three &&\n+\tgit fetch &&\n+\ttest -f .git/refs/heads/two &&\n+\ttest -f .git/refs/heads/one &&\n+\tmaster_in_two=`cd ../two && git rev-parse master` &&\n+\tone_in_two=`cd ../two && git rev-parse one` &&\n+\t{\n+\t\techo \"$master_in_two\trefs/heads/master:refs/heads/two\"\n+\t\techo \"$one_in_two\trefs/heads/one:refs/heads/one\"\n+\t} >expected &&\n+\tcut -f -2 .git/FETCH_FETCHED >actual &&\n+\tdiff expected actual'\n+\n+\n test_expect_success \"fetch test for-merge\" '\n \tcd \"$D\" &&\n \tcd three &&\n-- \n1.5.0.35.gaaba\n"},{"id":"34784","messageId":"87r6sqo73y.fsf@gmail.com","threadId":"6842","inReplyTo":"874ppmplw7.fsf@gmail.com","subject":"[PATCH/RFC 3/3] t/t5515: fixes for the separate fetch and merge logic","fromName":"Santi Béjar","fromEmail":"sbejar@gmail.com","sentAt":"2007-02-16T08:10:41Z","receivedAt":"2007-02-16T08:10:41Z","isPatch":true,"sender":{"key":"santi@agolina.net","avatar":null},"body":"\n1) branch.*.merge no longer must exactly match the remote part\n   of the branch fetched. Both are expanded in full (as refs/heads/...)\n   and matched afterwards.\n2) When the remote is specified with $GIT_DIR/branches/... and there is\n   a branch.*.merge, the remote branch name must match to get them merged.\n   Before the branch in $GIT_DIR/branches/... was always merged.\n   In the documentation the $GIT_DIR/branches/ is documented as a\n   short-hand for a corresponding file in $GIT_DIR/remotes/, so I think\n   this makes the new behaviour consistent.\n\n\nSigned-off-by: Santi Béjar <sbejar@gmail.com>\n---\n t/t5515/fetch.br-branches-default-merge            |    2 +-\n ...etch.br-branches-default-merge_branches-default |    2 +-\n t/t5515/fetch.br-branches-default-octopus          |    2 +-\n ...ch.br-branches-default-octopus_branches-default |    2 +-\n t/t5515/fetch.br-branches-one-merge                |    2 +-\n t/t5515/fetch.br-branches-one-merge_branches-one   |    2 +-\n t/t5515/fetch.br-config-glob-octopus               |    2 +-\n t/t5515/fetch.br-config-glob-octopus_config-glob   |    2 +-\n t/t5515/fetch.br-remote-glob-octopus               |    2 +-\n t/t5515/fetch.br-remote-glob-octopus_remote-glob   |    2 +-\n 10 files changed, 10 insertions(+), 10 deletions(-)\n\ndiff --git a/t/t5515/fetch.br-branches-default-merge b/t/t5515/fetch.br-branches-default-merge\nindex ca85356..28b85e1 100644\n--- a/t/t5515/fetch.br-branches-default-merge\n+++ b/t/t5515/fetch.br-branches-default-merge\n@@ -1,2 +1,2 @@\n # br-branches-default-merge\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f\t\n+754b754407bf032e9a2f9d5a9ad05ca79a6b228f\tnot-for-merge\ndiff --git a/t/t5515/fetch.br-branches-default-merge_branches-default b/t/t5515/fetch.br-branches-default-merge_branches-default\nindex cb5acac..1d86ad1 100644\n--- a/t/t5515/fetch.br-branches-default-merge_branches-default\n+++ b/t/t5515/fetch.br-branches-default-merge_branches-default\n@@ -1,2 +1,2 @@\n # br-branches-default-merge branches-default\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f\t\n+754b754407bf032e9a2f9d5a9ad05ca79a6b228f\tnot-for-merge\ndiff --git a/t/t5515/fetch.br-branches-default-octopus b/t/t5515/fetch.br-branches-default-octopus\nindex 002b82e..22bed59 100644\n--- a/t/t5515/fetch.br-branches-default-octopus\n+++ b/t/t5515/fetch.br-branches-default-octopus\n@@ -1,2 +1,2 @@\n # br-branches-default-octopus\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f\t\n+754b754407bf032e9a2f9d5a9ad05ca79a6b228f\tnot-for-merge\ndiff --git a/t/t5515/fetch.br-branches-default-octopus_branches-default b/t/t5515/fetch.br-branches-default-octopus_branches-default\nindex 7443cf7..c584f16 100644\n--- a/t/t5515/fetch.br-branches-default-octopus_branches-default\n+++ b/t/t5515/fetch.br-branches-default-octopus_branches-default\n@@ -1,2 +1,2 @@\n # br-branches-default-octopus branches-default\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f\t\n+754b754407bf032e9a2f9d5a9ad05ca79a6b228f\tnot-for-merge\ndiff --git a/t/t5515/fetch.br-branches-one-merge b/t/t5515/fetch.br-branches-one-merge\nindex e594bec..c7f5013 100644\n--- a/t/t5515/fetch.br-branches-one-merge\n+++ b/t/t5515/fetch.br-branches-one-merge\n@@ -1,2 +1,2 @@\n # br-branches-one-merge\n-8e32a6d901327a23ef831511badce7bf3bf46689\t\n+8e32a6d901327a23ef831511badce7bf3bf46689\tnot-for-merge\ndiff --git a/t/t5515/fetch.br-branches-one-merge_branches-one b/t/t5515/fetch.br-branches-one-merge_branches-one\nindex 168031c..1473f5c 100644\n--- a/t/t5515/fetch.br-branches-one-merge_branches-one\n+++ b/t/t5515/fetch.br-branches-one-merge_branches-one\n@@ -1,2 +1,2 @@\n # br-branches-one-merge branches-one\n-8e32a6d901327a23ef831511badce7bf3bf46689\t\n+8e32a6d901327a23ef831511badce7bf3bf46689\tnot-for-merge\ndiff --git a/t/t5515/fetch.br-config-glob-octopus b/t/t5515/fetch.br-config-glob-octopus\nindex da95823..0f324e0 100644\n--- a/t/t5515/fetch.br-config-glob-octopus\n+++ b/t/t5515/fetch.br-config-glob-octopus\n@@ -2,4 +2,4 @@\n 754b754407bf032e9a2f9d5a9ad05ca79a6b228f\tnot-for-merge\n 8e32a6d901327a23ef831511badce7bf3bf46689\t\n 0567da4d5edd2ff4bb292a465ba9e64dcad9536b\tnot-for-merge\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8\tnot-for-merge\n+6134ee8f857693b96ff1cc98d3e2fd62b199e5a8\t\ndiff --git a/t/t5515/fetch.br-config-glob-octopus_config-glob b/t/t5515/fetch.br-config-glob-octopus_config-glob\nindex 0e7c769..8151e4c 100644\n--- a/t/t5515/fetch.br-config-glob-octopus_config-glob\n+++ b/t/t5515/fetch.br-config-glob-octopus_config-glob\n@@ -2,4 +2,4 @@\n 754b754407bf032e9a2f9d5a9ad05ca79a6b228f\tnot-for-merge\n 8e32a6d901327a23ef831511badce7bf3bf46689\t\n 0567da4d5edd2ff4bb292a465ba9e64dcad9536b\tnot-for-merge\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8\tnot-for-merge\n+6134ee8f857693b96ff1cc98d3e2fd62b199e5a8\t\ndiff --git a/t/t5515/fetch.br-remote-glob-octopus b/t/t5515/fetch.br-remote-glob-octopus\nindex 92ef25c..4a14384 100644\n--- a/t/t5515/fetch.br-remote-glob-octopus\n+++ b/t/t5515/fetch.br-remote-glob-octopus\n@@ -2,4 +2,4 @@\n 754b754407bf032e9a2f9d5a9ad05ca79a6b228f\tnot-for-merge\n 8e32a6d901327a23ef831511badce7bf3bf46689\t\n 0567da4d5edd2ff4bb292a465ba9e64dcad9536b\tnot-for-merge\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8\tnot-for-merge\n+6134ee8f857693b96ff1cc98d3e2fd62b199e5a8\t\ndiff --git a/t/t5515/fetch.br-remote-glob-octopus_remote-glob b/t/t5515/fetch.br-remote-glob-octopus_remote-glob\nindex 6ad3726..7f6f928 100644\n--- a/t/t5515/fetch.br-remote-glob-octopus_remote-glob\n+++ b/t/t5515/fetch.br-remote-glob-octopus_remote-glob\n@@ -2,4 +2,4 @@\n 754b754407bf032e9a2f9d5a9ad05ca79a6b228f\tnot-for-merge\n 8e32a6d901327a23ef831511badce7bf3bf46689\t\n 0567da4d5edd2ff4bb292a465ba9e64dcad9536b\tnot-for-merge\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8\tnot-for-merge\n+6134ee8f857693b96ff1cc98d3e2fd62b199e5a8\t\n-- \n1.5.0.35.gaaba\n"},{"id":"34785","messageId":"7vwt2i7bq7.fsf@assigned-by-dhcp.cox.net","threadId":"6842","inReplyTo":"874ppmplw7.fsf@gmail.com","subject":"Re: [PATCH/RFC 0/3] Split fetch and merge logic","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-16T08:22:56Z","receivedAt":"2007-02-16T08:22:56Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Santi Béjar <sbejar@gmail.com> writes:\n\n> This series implements the split of the fetch and merge logic.\n\nThat's a description of what it does, but could you describe\nwhat problem it solves, please?\n\nThe approach of presentation to introduce the test and showing\nthe behavior change in a later patch is very good, though.\n"},{"id":"34786","messageId":"87mz3eo6jd.fsf@gmail.com","threadId":"6842","inReplyTo":"87zm7eo78x.fsf@gmail.com","subject":"Re: [PATCH/RFC 1/3] t/t5515-fetch-merge-logic.sh: Added tests for the merge login in git-fetch","fromName":"Santi Béjar","fromEmail":"sbejar@gmail.com","sentAt":"2007-02-16T08:23:02Z","receivedAt":"2007-02-16T08:23:02Z","isPatch":true,"sender":{"key":"santi@agolina.net","avatar":null},"body":"Hi *,\n\n   I think it didn't get to the list due to the size limit. So I send it\n   as a gziped attatchment, with the test inline.\n\nRegards,\n\nSanti\n\n---\n t/t5515-fetch-merge-logic.sh                       |  124 ++++++++++++++++++++\n\ndiff --git a/t/t5515-fetch-merge-logic.sh b/t/t5515-fetch-merge-logic.sh\nnew file mode 100755\nindex 0000000..8d8a71f\n--- /dev/null\n+++ b/t/t5515-fetch-merge-logic.sh\n@@ -0,0 +1,124 @@\n+#!/bin/sh\n+#\n+# Copyright (c) 2007 Santi Béjar, based on t4013 by Junio C Hamano\n+#\n+#\n+\n+test_description='Merge logic in fetch'\n+\n+. ./test-lib.sh\n+\n+LF='\n+'\n+\n+test_expect_success setup '\n+\tGIT_AUTHOR_DATE=\"2006-06-26 00:00:00 +0000\" &&\n+\tGIT_COMMITTER_DATE=\"2006-06-26 00:00:00 +0000\" &&\n+\texport GIT_AUTHOR_DATE GIT_COMMITTER_DATE &&\n+\n+\techo >file original &&\n+\tgit add file &&\n+\tgit commit -a -m One &&\n+\tgit branch one &&\n+\n+\techo two >> file &&\n+\tgit commit -a -m Two &&\n+\tgit branch two &&\n+\n+\techo three >> file &&\n+\tgit commit -a -m Three &&\n+\tgit branch three &&\n+\n+\techo master >> file &&\n+\tgit commit -a -m Master\n+\n+\tgit checkout three\n+\n+\tgit clone . cloned &&\n+\tcd cloned &&\n+\n+\tgit config remote.config-explicit.url ../.git/ &&\n+\tgit config remote.config-explicit.fetch refs/heads/master:remotes/rem/master &&\n+\tgit config --add remote.config-explicit.fetch refs/heads/one:remotes/rem/one &&\n+\tgit config --add remote.config-explicit.fetch two:remotes/rem/two &&\n+\tgit config --add remote.config-explicit.fetch refs/heads/three:remotes/rem/three &&\n+\n+\tgit config remote.config-glob.url ../.git/ &&\n+\tgit config remote.config-glob.fetch refs/heads/*:refs/remotes/rem/* &&\n+\n+\tmkdir -p .git/remotes &&\n+\t{\n+\t\techo \"URL: ../.git/\"\n+\t\techo \"Pull: refs/heads/master:remotes/rem/master\"\n+\t\techo \"Pull: refs/heads/one:remotes/rem/one\"\n+\t\techo \"Pull: two:remotes/rem/two\"\n+\t\techo \"Pull: refs/heads/three:remotes/rem/three\"\n+\t} >.git/remotes/remote-explicit &&\n+\n+\t{\n+\t\techo \"URL: ../.git/\"\n+\t\techo \"Pull: refs/heads/*:refs/remotes/rem/*\"\n+\t} >.git/remotes/remote-glob &&\n+\n+\tmkdir -p .git/branches &&\n+\techo \"../.git\" > .git/branches/branches-default &&\n+\techo \"../.git#one\" > .git/branches/branches-one &&\n+\n+\tfor remote in config-explicit config-glob remote-explicit remote-glob \\\n+\t\tbranches-default branches-one ; do\n+\t\tgit config branch.br-$remote.remote $remote &&\n+\t\tgit config branch.br-$remote-merge.remote $remote &&\n+\t\tgit config branch.br-$remote-merge.merge refs/heads/three &&\n+\t\tgit config branch.br-$remote-octopus.remote $remote &&\n+\t\tgit config branch.br-$remote-octopus.merge refs/heads/one &&\n+\t\tgit config --add branch.br-$remote-octopus.merge two &&\n+\t\tgit config --add branch.br-$remote-octopus.merge remotes/rem/three &&\n+\t\tbranches=\"$branches br-$remote br-$remote-merge br-$remote-octopus\"\n+\tdone\n+'\n+\n+for branch in br-unconfig $branches ; do\n+    echo $branch\n+    for remote in config-explicit config-glob remote-explicit remote-glob \\\n+\tbranches-default branches-one ../.git\n+    do\n+cat <<EOF\n+$branch $remote\n+$branch $remote one\n+$branch $remote one two\n+EOF\n+    done\n+done > tests\n+\n+while read cmd\n+do\n+\tcase \"$cmd\" in\n+\t'' | '#'*) continue ;;\n+\tesac\n+\ttest=`echo \"$cmd\" | sed -e 's|[/ ][/ ]*|_|g'`\n+\tcnt=`expr $test_count + 1`\n+\tpfx=`printf \"%04d\" $cnt`\n+\texpect=\"../../t5515/fetch.$test\"\n+\tactual=\"$pfx-fetch.$test\"\n+\n+\ttest_expect_success \"$cmd\" '\n+\t\t{\n+\t\t\techo \"# $cmd\"\n+\t\t\tset x $cmd; shift\n+\t\t\tgit symbolic-ref HEAD refs/heads/$1 ; shift\n+\t\t\tgit fetch \"$@\" >/dev/null\n+\t\t\tcut -f -2 .git/FETCH_HEAD\n+\t\t} >\"$actual\" &&\n+\t\tif test -f \"$expect\"\n+\t\tthen\n+\t\t\tdiff -u \"$expect\" \"$actual\" &&\n+\t\t\trm -f \"$actual\"\n+\t\telse\n+\t\t\t# this is to help developing new tests.\n+\t\t\tcp \"$actual\" \"$expect\"\n+\t\t\tfalse\n+\t\tfi\n+\t'\n+done < tests\n+\n+test_done\n\n"},{"id":"34788","messageId":"8aa486160702160040t3f42b5a0xbd12f333805ad4d7@mail.gmail.com","threadId":"6842","inReplyTo":"7vwt2i7bq7.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH/RFC 0/3] Split fetch and merge logic","fromName":"Santi Béjar","fromEmail":"sbejar@gmail.com","sentAt":"2007-02-16T08:40:51Z","receivedAt":"2007-02-16T08:40:51Z","isPatch":true,"sender":{"key":"santi@agolina.net","avatar":null},"body":"On 2/16/07, Junio C Hamano <junkio@cox.net> wrote:\n> Santi Béjar <sbejar@gmail.com> writes:\n>\n> > This series implements the split of the fetch and merge logic.\n>\n> That's a description of what it does, but could you describe\n> what problem it solves, please?\n\nSure.\n\nIn the past we've had problems when we have changed the merge logic\n(as shows 4363dfbe3). This patch makes the two process completely\nindependent, and concentrate the merge logic in one place (leaving\ngit-parse-remote.sh independent of the merge logic).\n\n>\n> The approach of presentation to introduce the test and showing\n> the behavior change in a later patch is very good, though.\n\nThanks.\n\nSanti\n"},{"id":"34827","messageId":"7vd54950ed.fsf@assigned-by-dhcp.cox.net","threadId":"6842","inReplyTo":"8aa486160702160040t3f42b5a0xbd12f333805ad4d7@mail.gmail.com","subject":"Re: [PATCH/RFC 0/3] Split fetch and merge logic","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-16T20:10:34Z","receivedAt":"2007-02-16T20:10:34Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Santi Béjar\" <sbejar@gmail.com> writes:\n\n> In the past we've had problems when we have changed the merge logic\n> (as shows 4363dfbe3). This patch makes the two process completely\n> independent, and concentrate the merge logic in one place (leaving\n> git-parse-remote.sh independent of the merge logic).\n\nBut that is a solved problem, isn't it?  What else does it\nsolve?  The justification for moving around the logic could be\nsomething like \"these three patches do not do that themselves,\nbut it opens a door for further work such as ...\", but without\nsomething concrete in \"...\" part, your response makes the patch\nlook mostly needless code churn.\n\nI was hoping to hear something like \"now git-fetch has to do\nmuch less than before, eventual C-rewrite of the command, which\ncan borrow some code already written for 'pu' branch, will\nbecome much easier\" ;-).\n"},{"id":"34829","messageId":"8aa486160702161230r6f5825a2v861315c1aa52520e@mail.gmail.com","threadId":"6842","inReplyTo":"7vd54950ed.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH/RFC 0/3] Split fetch and merge logic","fromName":"Santi Béjar","fromEmail":"sbejar@gmail.com","sentAt":"2007-02-16T20:30:25Z","receivedAt":"2007-02-16T20:30:25Z","isPatch":true,"sender":{"key":"santi@agolina.net","avatar":null},"body":"On 2/16/07, Junio C Hamano <junkio@cox.net> wrote:\n> \"Santi Béjar\" <sbejar@gmail.com> writes:\n>\n> > In the past we've had problems when we have changed the merge logic\n> > (as shows 4363dfbe3). This patch makes the two process completely\n> > independent, and concentrate the merge logic in one place (leaving\n> > git-parse-remote.sh independent of the merge logic).\n>\n> But that is a solved problem, isn't it?  What else does it\n> solve?  The justification for moving around the logic could be\n> something like \"these three patches do not do that themselves,\n> but it opens a door for further work such as ...\", but without\n> something concrete in \"...\" part, your response makes the patch\n> look mostly needless code churn.\n>\n> I was hoping to hear something like \"now git-fetch has to do\n> much less than before, eventual C-rewrite of the command, which\n> can borrow some code already written for 'pu' branch, will\n> become much easier\" ;-).\n\nThis sounds like a good justification, also :-)\n\nSanti\n"},{"id":"34831","messageId":"7v4ppl4xfe.fsf@assigned-by-dhcp.cox.net","threadId":"6842","inReplyTo":"8aa486160702161230r6f5825a2v861315c1aa52520e@mail.gmail.com","subject":"Re: [PATCH/RFC 0/3] Split fetch and merge logic","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-16T21:14:45Z","receivedAt":"2007-02-16T21:14:45Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Santi Béjar\" <sbejar@gmail.com> writes:\n\n> This sounds like a good justification, also :-)\n\nWhat I said was an example.  I do not think your code churning\nactually would make it easier.\n"},{"id":"34990","messageId":"8aa486160702190147ta95ed31ld0e72d214c16db4b@mail.gmail.com","threadId":"6842","inReplyTo":"7v4ppl4xfe.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH/RFC 0/3] Split fetch and merge logic","fromName":"Santi Béjar","fromEmail":"sbejar@gmail.com","sentAt":"2007-02-19T09:47:15Z","receivedAt":"2007-02-19T09:47:15Z","isPatch":true,"sender":{"key":"santi@agolina.net","avatar":null},"body":"On 2/16/07, Junio C Hamano <junkio@cox.net> wrote:\n> \"Santi Béjar\" <sbejar@gmail.com> writes:\n>\n> > In the past we've had problems when we have changed the merge logic\n> > (as shows 4363dfbe3). This patch makes the two process completely\n> > independent, and concentrate the merge logic in one place (leaving\n> > git-parse-remote.sh independent of the merge logic).\n>\n> But that is a solved problem, isn't it?  What else does it\n> solve?  The justification for moving around the logic could be\n> something like \"these three patches do not do that themselves,\n> but it opens a door for further work such as ...\", but without\n> something concrete in \"...\" part, your response makes the patch\n> look mostly needless code churn.\n>\n> I was hoping to hear something like \"now git-fetch has to do\n> much less than before, eventual C-rewrite of the command, which\n> can borrow some code already written for 'pu' branch, will\n> become much easier\" ;-).\n\nOn 2/16/07, Junio C Hamano <junkio@cox.net> wrote:\n> \"Santi Béjar\" <sbejar@gmail.com> writes:\n>\n> > This sounds like a good justification, also :-)\n>\n> What I said was an example.  I do not think your code churning\n> actually would make it easier.\n>\n>\n\nWhat I said was an example of why having the two logic intermixed can\nbe problematic. Anyway, basically:\n\n* It is a cleanup\n* It makes the code cleaner\n* It makes the code easier to maintain\n* It makes the future changes easier\n* It makes git-parse-remote and almost all git-fetch independent of\nthe merge logic\n* The merge logic is in a few lines\n* Do one thing and do it well\n\nRegards,\n\nSanti\n"},{"id":"35029","messageId":"7v649x7u90.fsf@assigned-by-dhcp.cox.net","threadId":"6842","inReplyTo":"87vei2o75x.fsf@gmail.com","subject":"Re: [PATCH/RFC 2/3] git-fetch: Split fetch and merge logic","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-19T20:44:11Z","receivedAt":"2007-02-19T20:44:11Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Santi Béjar <sbejar@gmail.com> writes:\n\n> git-fetch fetches the branches from the remote and saves this\n> information in .git/FETCH_FETCHED, and at the end it generates\n> the file .git/FETCH_HEAD.\n>\n> There are two cases where the behaviour is changed:\n>\n> 1) branch.*.merge no longer must exactly match the remote part\n>    of the branch fetched. Both are expanded in full (as refs/heads/...)\n>    and matched afterwards.\n\nHow hard would it be to fix this?  I see this as a regression.\nIf you are setting configuration, wouldn't you rather see the\nbehaviour consistent even when remote adds new refs?\n\n> 2) When the remote is specified with $GIT_DIR/branches/... and there is\n>    a branch.*.merge, the remote branch name must match to get them merged.\n>    Before the branch in $GIT_DIR/branches/... was always merged.\n\nI do not think the current $GIT_DIR/branches/ support with\nrespect to choosing which remote branch to choose was done with\nany deep thinking, other than to stay backward compatible, so I\nwould not put too much trust in what is in the documentation.\nAt the same time, I personally can be pursuaded to go either\nway, exactly because I do not think the current behaviour has\nstrict reasoning behind it.\n\nHowever, I wonder how this change would affect existing setups\npeople may have.\n\nMerging this at this moment would be a pain even if there were\nno downsides, as there are a few topics that want to touch\nparse-remote and fetch (two already in 'pu', and git-bundle\nseries also wants to hook into git-fetch); these topics would\nneed to get adjusted if this clean-up goes in first.\n"},{"id":"35035","messageId":"8aa486160702191413p10c8ca0ek949580ffe953ea79@mail.gmail.com","threadId":"6842","inReplyTo":"7v649x7u90.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH/RFC 2/3] git-fetch: Split fetch and merge logic","fromName":"Santi Béjar","fromEmail":"sbejar@gmail.com","sentAt":"2007-02-19T22:13:35Z","receivedAt":"2007-02-19T22:13:35Z","isPatch":true,"sender":{"key":"santi@agolina.net","avatar":null},"body":"On 2/19/07, Junio C Hamano <junkio@cox.net> wrote:\n> Santi Béjar <sbejar@gmail.com> writes:\n>\n> > git-fetch fetches the branches from the remote and saves this\n> > information in .git/FETCH_FETCHED, and at the end it generates\n> > the file .git/FETCH_HEAD.\n> >\n> > There are two cases where the behaviour is changed:\n> >\n> > 1) branch.*.merge no longer must exactly match the remote part\n> >    of the branch fetched. Both are expanded in full (as refs/heads/...)\n> >    and matched afterwards.\n>\n> How hard would it be to fix this?\n\nAt least it is not a 2 lines \"fix\".\n\n>  I see this as a regression.\n> If you are setting configuration, wouldn't you rather see the\n> behaviour consistent even when remote adds new refs?\n\nI don't see it a regression. All current setups continue to work\nproperly and, sorry but I don't see how adding a new ref changes this.\n\n>\n> > 2) When the remote is specified with $GIT_DIR/branches/... and there is\n> >    a branch.*.merge, the remote branch name must match to get them merged.\n> >    Before the branch in $GIT_DIR/branches/... was always merged.\n>\n> I do not think the current $GIT_DIR/branches/ support with\n> respect to choosing which remote branch to choose was done with\n> any deep thinking, other than to stay backward compatible, so I\n> would not put too much trust in what is in the documentation.\n> At the same time, I personally can be pursuaded to go either\n> way, exactly because I do not think the current behaviour has\n> strict reasoning behind it.\n\nI prefer my way, but I don't mind much either and it can be \"fixed\".\n\n>\n> However, I wonder how this change would affect existing setups\n> people may have.\n>\n> Merging this at this moment would be a pain even if there were\n> no downsides, as there are a few topics that want to touch\n> parse-remote and fetch (two already in 'pu', and git-bundle\n> series also wants to hook into git-fetch); these topics would\n> need to get adjusted if this clean-up goes in first.\n\nA problematic decision :)\n\nSanti\n"},{"id":"35041","messageId":"7vfy91684y.fsf@assigned-by-dhcp.cox.net","threadId":"6842","inReplyTo":"8aa486160702191413p10c8ca0ek949580ffe953ea79@mail.gmail.com","subject":"Re: [PATCH/RFC 2/3] git-fetch: Split fetch and merge logic","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-19T23:27:09Z","receivedAt":"2007-02-19T23:27:09Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Santi Béjar\" <sbejar@gmail.com> writes:\n\n>> > There are two cases where the behaviour is changed:\n>> >\n>> > 1) branch.*.merge no longer must exactly match the remote part\n>> >    of the branch fetched. Both are expanded in full (as refs/heads/...)\n>> >    and matched afterwards.\n> ...\n>>  I see this as a regression.\n>> If you are setting configuration, wouldn't you rather see the\n>> behaviour consistent even when remote adds new refs?\n\nMaybe I misread your description, but I took it to mean that you\nare allowing:\n\n\tbranch.master.merge = a\n\nto mean what we traditionally spelled\n\n\tbranch.master.merge = refs/heads/a\n\nand guessed (I haven't looked for where it happens in the code)\nthe way you do that conversion is by tail-matching the ref; if\nthe other end creates \"refs/heads/b/a\", suddenly remote branch\nb/a starts matching that pattern wouldn't it?\n\nEarlier we fixed the ambiguous use of branch.*.merge in\n756373da; I think the same reasoning should apply here.\n\nConfiguration is something you set once because you want to\nforget about it afterwards (iow, not having to type every time),\nand I think making sure it names things unambiguously outweighs\none-time convenience of being able to write the configuration in\na looser fashion.  \n\nIf somebody does \"git checkout -B origin/next\" which does:\n\n\tgit checkout -b next origin/next &&\n        git repo-config branch.next.merge $merge\n\nI would expect that the enhanced \"checkout\" script would not\nhave any trouble arranging $merge to fully spell out\nrefs/heads/next.\n\n>> Merging this at this moment would be a pain even if there were\n>> no downsides, as there are a few topics that want to touch\n>> parse-remote and fetch (two already in 'pu', and git-bundle\n>> series also wants to hook into git-fetch); these topics would\n>> need to get adjusted if this clean-up goes in first.\n>\n> A problematic decision :)\n\nNot at all.\n"},{"id":"35111","messageId":"8aa486160702200321l35e309eeqe5799dc56be5dac6@mail.gmail.com","threadId":"6842","inReplyTo":"7vfy91684y.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH/RFC 2/3] git-fetch: Split fetch and merge logic","fromName":"Santi Béjar","fromEmail":"sbejar@gmail.com","sentAt":"2007-02-20T11:21:56Z","receivedAt":"2007-02-20T11:21:56Z","isPatch":true,"sender":{"key":"santi@agolina.net","avatar":null},"body":"On 2/20/07, Junio C Hamano <junkio@cox.net> wrote:\n> \"Santi Béjar\" <sbejar@gmail.com> writes:\n>\n> >> > There are two cases where the behaviour is changed:\n> >> >\n> >> > 1) branch.*.merge no longer must exactly match the remote part\n> >> >    of the branch fetched. Both are expanded in full (as refs/heads/...)\n> >> >    and matched afterwards.\n> > ...\n> >>  I see this as a regression.\n> >> If you are setting configuration, wouldn't you rather see the\n> >> behaviour consistent even when remote adds new refs?\n>\n> Maybe I misread your description, but I took it to mean that you\n> are allowing:\n>\n>         branch.master.merge = a\n>\n> to mean what we traditionally spelled\n>\n>         branch.master.merge = refs/heads/a\n>\n> and guessed (I haven't looked for where it happens in the code)\n> the way you do that conversion is by tail-matching the ref; if\n> the other end creates \"refs/heads/b/a\", suddenly remote branch\n> b/a starts matching that pattern wouldn't it?\n\nNo. branch.master.merge = a is equivalent to refs/heads/a and only\nmatches with the remote branch refs/heads/a. It continues to exactly\nmatch the two branches, but with the full patch (refs/...). So now it\nis possible to have:\n\n[remote \"origin\"]\nurl = ...\nfetch = refs/heads/*:refs/heads/origin/*\n\n[branch \"master\"]\nremote = origin\nmerge = master\n\nor the other way:\n\n[remote \"origin\"]\nurl = ...\nfetch = master:refs/heads/origin\n\n[branch \"master\"]\nremote = origin\nmerge = refs/heads/master\n\n>\n> Earlier we fixed the ambiguous use of branch.*.merge in\n> 756373da; I think the same reasoning should apply here.\n>\n> Configuration is something you set once because you want to\n> forget about it afterwards (iow, not having to type every time),\n> and I think making sure it names things unambiguously outweighs\n> one-time convenience of being able to write the configuration in\n> a looser fashion.\n\nIt is unambiguous.\n\nBut if it is problematic I'll try to keep the current behaviour.\n\nSanti\n"}]}