{"thread":{"id":"43521","subject":"Re: [PATCH] Only warn about missing branch.<n>.merge in pull.","startedAt":"2006-12-18T09:12:06Z","lastAt":"2006-12-19T10:37:00Z","messageCount":8,"participants":["Josef Weidendorfer","Santi Béjar","Shawn O. Pearce","Junio C Hamano","Shawn Pearce","Johannes Schindelin"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"296946","messageId":"20061218091206.GA11284@spearce.org","threadId":"43521","inReplyTo":null,"subject":"[PATCH] Only warn about missing branch.<n>.merge in pull.","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-18T09:12:06Z","receivedAt":"2006-12-18T09:12:06Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Commit 62b339a5 added a warning for git-pull to notify the user when\nthey have not configured the setting 'branch.<n>.merge' (where <n>\nis the current branch) and no arguments were given to git-pull to\nspecify the branches to merge.\n\nUnfortunately this warning also appears in git-fetch when no\narguments were supplied, as the warning is being output at the\nsame time that the contents of FETCH_HEAD is being determined.\nThis causes users who fetch into local tracking branches prior\nto merging to receive unexpected/unnecessary warnings:\n\n  $ git fetch\n  Warning: No merge candidate found because value of config option\n           \"branch.sp/topic.merge\" does not match any remote branch fetched.\n\nThis warning may also cause problems for other Porcelain that use\ngit-fetch as \"plumbing\", as the other Porcelain may not actually\nuse (or honor) the branch.<n>.merge configuration option.\n\nInstead we should delay the warning about no matching branches until\nwe are actually in git-pull and are trying to setup the call to\ngit-merge to actually carry out the merge.  This way direct users\nof git-fetch do not receive these warnings.\n\nSigned-off-by: Shawn O. Pearce <spearce@spearce.org>\n---\n git-parse-remote.sh |   10 ----------\n git-pull.sh         |   16 +++++++++++++++-\n 2 files changed, 15 insertions(+), 11 deletions(-)\n\ndiff --git a/git-parse-remote.sh b/git-parse-remote.sh\nindex f27c3c2..7a1cf5c 100755\n--- a/git-parse-remote.sh\n+++ b/git-parse-remote.sh\n@@ -134,7 +134,6 @@ canon_refs_list_for_fetch () {\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-\tfound_mergeref=\n \tcurr_branch=\n \tif test \"$1\" = \"-d\"\n \tthen\n@@ -174,10 +173,6 @@ canon_refs_list_for_fetch () {\n \t\t\t    dot_prefix= && break\n \t\t\tdone\n \t\tfi\n-\t\tif test -z $dot_prefix\n-\t\tthen\n-\t\t\tfound_mergeref=true\n-\t\tfi\n \t\tcase \"$remote\" in\n \t\t'') remote=HEAD ;;\n \t\trefs/heads/* | refs/tags/* | refs/remotes/*) ;;\n@@ -198,11 +193,6 @@ canon_refs_list_for_fetch () {\n \t\tfi\n \t\techo \"${dot_prefix}${force}${remote}:${local}\"\n \tdone\n-\tif test -z \"$found_mergeref\" -a \"$curr_branch\"\n-\tthen\n-\t\techo >&2 \"Warning: No merge candidate found because value of config option\n-         \\\"branch.${curr_branch}.merge\\\" does not match any remote branch fetched.\"\n-\tfi\n }\n \n # Returns list of src: (no store), or src:dst (store)\ndiff --git a/git-pull.sh b/git-pull.sh\nindex e23beb6..d43a565 100755\n--- a/git-pull.sh\n+++ b/git-pull.sh\n@@ -76,7 +76,21 @@ merge_head=$(sed -e '/\tnot-for-merge\t/d' \\\n \n case \"$merge_head\" in\n '')\n-\techo >&2 \"No changes.\"\n+\techo >&2 \"warning: No branches were selected for merge.\"\n+\tif test $# = 0\n+\tthen\n+\t\tbranch=$(git-symbolic-ref HEAD | sed -e 's|^refs/heads/||')\n+\t\tremote=$(git-repo-config --get-all \"branch.$branch.remote\")\n+\t\tif test -z \"$remote\"\n+\t\tthen\n+\t\t\techo >&2 \"warning: (Config option 'branch.$branch.remote' not set.)\"\n+\t\tfi\n+\t\tmerge=$(git-repo-config --get-all \"branch.$branch.merge\")\n+\t\tif test -z \"$merge\"\n+\t\tthen\n+\t\t\techo >&2 \"warning: (Config option 'branch.$branch.merge' not set.)\"\n+\t\tfi\n+\tfi\n \texit 0\n \t;;\n ?*' '?*)\n-- \n"},{"id":"296314","messageId":"8aa486160612180306s38c83b17qc3fddf087ccd0460@mail.gmail.com","threadId":"43521","inReplyTo":"20061218091206.GA11284@spearce.org","subject":"Re: [PATCH] Only warn about missing branch.<n>.merge in pull.","fromName":"Santi Béjar","fromEmail":"sbejar@gmail.com","sentAt":"2006-12-18T11:06:01Z","receivedAt":"2006-12-18T11:06:01Z","isPatch":true,"sender":{"key":"santi@agolina.net","avatar":null},"body":"On 12/18/06, Shawn O. Pearce <spearce@spearce.org> wrote:\n> Commit 62b339a5 added a warning for git-pull to notify the user when\n> they have not configured the setting 'branch.<n>.merge' (where <n>\n> is the current branch) and no arguments were given to git-pull to\n> specify the branches to merge.\n>\n> Unfortunately this warning also appears in git-fetch when no\n> arguments were supplied, as the warning is being output at the\n> same time that the contents of FETCH_HEAD is being determined.\n> This causes users who fetch into local tracking branches prior\n> to merging to receive unexpected/unnecessary warnings:\n>\n>   $ git fetch\n>   Warning: No merge candidate found because value of config option\n>            \"branch.sp/topic.merge\" does not match any remote branch fetched.\n>\n> This warning may also cause problems for other Porcelain that use\n> git-fetch as \"plumbing\", as the other Porcelain may not actually\n> use (or honor) the branch.<n>.merge configuration option.\n>\n> Instead we should delay the warning about no matching branches until\n> we are actually in git-pull and are trying to setup the call to\n> git-merge to actually carry out the merge.  This way direct users\n> of git-fetch do not receive these warnings.\n>\n\nI think it is a sensible thing to do, but:\n\n[...]\n\n> diff --git a/git-pull.sh b/git-pull.sh\n> index e23beb6..d43a565 100755\n> --- a/git-pull.sh\n> +++ b/git-pull.sh\n> @@ -76,7 +76,21 @@ merge_head=$(sed -e '/       not-for-merge   /d' \\\n>\n>  case \"$merge_head\" in\n>  '')\n> -       echo >&2 \"No changes.\"\n> +       echo >&2 \"warning: No branches were selected for merge.\"\n> +       if test $# = 0\n> +       then\n> +               branch=$(git-symbolic-ref HEAD | sed -e 's|^refs/heads/||')\n> +               remote=$(git-repo-config --get-all \"branch.$branch.remote\")\n\nThere is only support for one branch.<n>.remote.\n\n> +               if test -z \"$remote\"\n> +               then\n> +                       echo >&2 \"warning: (Config option 'branch.$branch.remote' not set.)\"\n\nIt is OK not to have a branch.<n>.remote, it defaults to origin.\n\n> +               fi\n> +               merge=$(git-repo-config --get-all \"branch.$branch.merge\")\n> +               if test -z \"$merge\"\n> +               then\n> +                       echo >&2 \"warning: (Config option 'branch.$branch.merge' not set.)\"\n> +               fi\n> +       fi\n\nI don't like the (), and it's missing the other possibility:\n\nelse\n   echo >&2 \"Warning: config option 'branch.$branch.merge' does not\nmatch any remote branch fetched.\"\n\nAlso we could check that the number of to be merge branches equals to\nthe number of branch.<n>.merge (I'll do it).\n\n"},{"id":"295256","messageId":"200612190159.58658.Josef.Weidendorfer@gmx.de","threadId":"43521","inReplyTo":"Pine.LNX.4.63.0612182135360.19693@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] Only warn about missing branch.<n>.merge in pull.","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2006-12-19T00:59:58Z","receivedAt":"2006-12-19T00:59:58Z","isPatch":true,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Monday 18 December 2006 21:43, Johannes Schindelin wrote:\n> Hi,\n> \n> On Mon, 18 Dec 2006, Junio C Hamano wrote:\n> \n> > \t$ git pull second\n> > ...\n> >  (3) branch.$current.merge was a mistake.  It should have been\n> >      branch.$current.merge.$remote.  In other words, the\n> >      configuration should have been about the current branch and\n> >      the remote repository pair.\n> > \n> >  (4) the current configuration mechanism is fine, but the code\n> >      is not.  We should forbid \"the first branch listed\" rule\n> >      from being applied for \"git pull second\", and require the\n> >      users to explicitly say which branch(es) to merge.\n\n> I fetch/merge criss-crossed over my machines, so this affects me. Until \n> the recent changes, I _always_ fetched/merged with explicit remote and \n> branch. This keeps me unconfused about what I actually do.\n> \n> With the options you list, I'd say (3) with (4) as a fallback is the way \n> to go.\n\nI agree.\nDespite of this, I just sent out the quick fix.\n\n> However, I would actually reuse our versatile (often hated?) config  \n> handling:\n> \n> [branch \"xyz\"]\n> \tremote = blabla # this is the default remote\n> \tmerge = master # this is the default branch for the default remote\n> \tmerge = pu for remote second # merge 'pu' if pulling from second\n\nLooks a little bit confusing, but is fine with me.\nI even would remove the need for the word \"remote\" in the second merge line.\nAnybody using this has to look it up in the documentation, anyway.\nBecause these options are not really self-describing.\n\nJosef\n"},{"id":"297760","messageId":"7v7iwovg99.fsf@assigned-by-dhcp.cox.net","threadId":"43521","inReplyTo":"200612190159.58658.Josef.Weidendorfer@gmx.de","subject":"Re: [PATCH] Only warn about missing branch.<n>.merge in pull.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-19T01:14:26Z","receivedAt":"2006-12-19T01:14:26Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:\n\n> On Monday 18 December 2006 21:43, Johannes Schindelin wrote:\n>> \n>> However, I would actually reuse our versatile (often hated?) config  \n>> handling:\n>> \n>> [branch \"xyz\"]\n>> \tremote = blabla # this is the default remote\n>> \tmerge = master # this is the default branch for the default remote\n>> \tmerge = pu for remote second # merge 'pu' if pulling from second\n>\n> Looks a little bit confusing, but is fine with me.\n> I even would remove the need for the word \"remote\" in the second merge line.\n> Anybody using this has to look it up in the documentation, anyway.\n> Because these options are not really self-describing.\n\nI actually am in favor of Johannes's one, except that it does\nlook like you are always making a pentapus merge of pu, for,\nremote and second branches into xyz ;-).\n\n"},{"id":"297365","messageId":"20061219065407.GB2511@spearce.org","threadId":"43521","inReplyTo":"20061218202803.GB28925@mellanox.co.il","subject":"Re: [PATCH] Only warn about missing branch.<n>.merge in pull.","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-19T06:54:07Z","receivedAt":"2006-12-19T06:54:07Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"\"Michael S. Tsirkin\" <mst@mellanox.co.il> wrote:\n> > Quoting r. Junio C Hamano <junkio@cox.net>:\n> > I can see a few possibilities:\n> > \n> >  (1) people do not interact with multiple remote repositories\n> >      regularly, so this is not a problem in practice.\n> > \n> >  (2) people do, but \"the first branch listed\" rule is good\n> >      enough in practice.  Because they would always say \"git\n> >      pull second which-branch\" instead if they want something\n> >      different, this is a non-issue.\n> > \n> >  (3) branch.$current.merge was a mistake.  It should have been\n> >      branch.$current.merge.$remote.  In other words, the\n> >      configuration should have been about the current branch and\n> >      the remote repository pair.\n> > \n> >  (4) the current configuration mechanism is fine, but the code\n> >      is not.  We should forbid \"the first branch listed\" rule\n> >      from being applied for \"git pull second\", and require the\n> >      users to explicitly say which branch(es) to merge.\n> > \n> > I am inclined to say that (1) is possible, (2) is implausible\n> > (otherwise we would not have done 62b339a5 for the same reason),\n> > (3) is confused, and probably (4) is what we need.\n> \n> As a person who tracks multiple remotes in one repository,\n> I would say (4) best matches what I do.\n> \n> So I currently always do git fetch <remote> to download changes,\n> and always use git pull . <branch> to merge a specific branch.\n\nAgreed; #4 best matches what I (and those I work with on that ugly\nrepository of mine) do.\n\nMy git.git repository currently just fetches all of Junio's branches\nright into my local refs/heads.  I fetch every day or so, but never\nmerge from next into any branch.  Though I create branches off next,\nmaster, or some select commit based on whatever topic I'm hacking.\n\nIn my other repositories I tend to fetch before merging, for a\nnumber of reasons:\n\n a) Its distributed backup; if I fetch the branch that's one more copy.\n\n b) I can easily view a branch's recent changes, but not affect my\n    own topics until I'm ready to take them in.  People often ask\n\tme to look at their changes, or wonder why something is suddenly\n\tacting odd - looking at the commits in gitk usually tells me\n\tquite quickly who did what.  :-)\n\n c) I can easily start a new topic off any recent change.\n\n d) I can easily merge topics once they are local and reviewed.\n\na,b,d are not quite as necessary in an email-patch based group such\nas git itself, as the mailing list offers most of the reasons I\nfetch first.  b and c are just convience there.\n\n-- \n"},{"id":"298601","messageId":"Pine.LNX.4.63.0612191127540.19693@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43521","inReplyTo":"7v7iwovg99.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Only warn about missing branch.<n>.merge in pull.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-12-19T10:28:45Z","receivedAt":"2006-12-19T10:28:45Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 18 Dec 2006, Junio C Hamano wrote:\n\n> Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:\n> \n> > On Monday 18 December 2006 21:43, Johannes Schindelin wrote:\n> >> \n> >> However, I would actually reuse our versatile (often hated?) config  \n> >> handling:\n> >> \n> >> [branch \"xyz\"]\n> >> \tremote = blabla # this is the default remote\n> >> \tmerge = master # this is the default branch for the default remote\n> >> \tmerge = pu for remote second # merge 'pu' if pulling from second\n> >\n> > Looks a little bit confusing, but is fine with me.\n> > I even would remove the need for the word \"remote\" in the second merge line.\n> > Anybody using this has to look it up in the documentation, anyway.\n> > Because these options are not really self-describing.\n> \n> I actually am in favor of Johannes's one, except that it does\n> look like you are always making a pentapus merge of pu, for,\n> remote and second branches into xyz ;-).\n\n\nWould\n\n\tmerge = pu, when pulling second\n\nbe better? ;-)\n\nCiao,\nDscho\n"},{"id":"297855","messageId":"Pine.LNX.4.63.0612191128500.19693@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43521","inReplyTo":"200612190159.58658.Josef.Weidendorfer@gmx.de","subject":"Re: [PATCH] Only warn about missing branch.<n>.merge in pull.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-12-19T10:30:32Z","receivedAt":"2006-12-19T10:30:32Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 19 Dec 2006, Josef Weidendorfer wrote:\n\n> On Monday 18 December 2006 21:43, Johannes Schindelin wrote:\n>\n> > However, I would actually reuse our versatile (often hated?) config  \n> > handling:\n> > \n> > [branch \"xyz\"]\n> > \tremote = blabla # this is the default remote\n> > \tmerge = master # this is the default branch for the default remote\n> > \tmerge = pu for remote second # merge 'pu' if pulling from second\n> \n> Looks a little bit confusing, but is fine with me.\n\nGranted. Suggestions?\n\n> I even would remove the need for the word \"remote\" in the second merge \n> line.\n\nNo. In Git, a line like\n\n\tblabla\n\nwould turn into a boolean named \"blabla\" being true.\n\nCiao,\nDscho\n"},{"id":"296973","messageId":"7vy7p4qiib.fsf@assigned-by-dhcp.cox.net","threadId":"43521","inReplyTo":"Pine.LNX.4.63.0612191127540.19693@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] Only warn about missing branch.<n>.merge in pull.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-19T10:37:00Z","receivedAt":"2006-12-19T10:37:00Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n>> >> \tmerge = pu for remote second # merge 'pu' if pulling from second\n>>\n>> I actually am in favor of Johannes's one, except that it does\n>> look like you are always making a pentapus merge of pu, for,\n>> remote and second branches into xyz ;-).\n>\n>\n> Would\n>\n> \tmerge = pu, when pulling second\n>\n> be better? ;-)\n\nThe users can work it around by writing:\n\n\tmerge pu remote second for\n\nJust document it clearly and say \"if you are going to make an\npentapus (or more) with remote branches that include ones named\n'for' and 'remote', do not place them as third and second\n(respectively) word from the end on the line\" ;-).\n\nYour \"noise word\" remote is actually useful.\n\n"}]}