git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] Make git-{pull,rebase} message without tracking information friendlier

From
Carlos Martín Nieto <cmn@elego.de>
Date
Mar 4, 2012, 04:41 UTC
Message-ID
<1330836086.691.87.camel@centaur.lab.cmartin.tk>
In-Reply-To
<7vobshs8go.fsf@alter.siamese.dyndns.org>
On Wed, 2012-02-29 at 12:14 -0800, Junio C Hamano wrote:
Show 8 quoted lines
> Carlos Martín Nieto <cmn@elego.de> writes:
> [...]
> 
> This made me thinking again.  On the "detached HEAD" side of your patch,
> the concluding "Please specify which branch you mean" is the most useful
> information; ", so I cannot use any tracking information in your
> configuration file" may help _education_, but does not immediately help
> the user to do what the user wanted to do.
> Perhaps it may read it better if we remove that part; the result becomes
> even more concise and to the point.

Right. Less is more. I may have stared at it for too long, but I get the feeling that in the new message, "You are not on a branch" and "Please specify which branch" don't really seem to go together. After the first sentence, I'm left thinking "so what?". Maybe something like "On detached HEAD, you must specify a branch to $op_type $op_prep. [...]" would work better?

Show 7 quoted lines
> 
> Oh the "on a branch" side of your patch, the updated message is trying to
> help the user by doing two things:
> 
>  - tell him to explicitly name the branch (by the way, you seem to have
>    lost the $example---is it intended) in order to immediately perform
>    what he wanted to.

I did remove that on purpose because I couldn't figure out a good way to introduce both versions. I was stubbornly keeping the configuration part first and it wasn't clicking.

Show 6 quoted lines
> 
>  - educate him that he can configure upstream information and avoid
>    typing in a later invocation of the same command.
> 
> I think it is easier to read if we have clear separation between the two,
> as the hasty users would want to stop reading after the first help.

Yes. This is why I wanted to put the configuration information first, as a user who calls 'git pull' expects things to happen automatically, so I wanted to tell her how to get it.

Show 6 quoted lines
> 
> So after "See git-${cmd}(1) for details.", have a paragraph break, add
> an indented "$example" just like you have for the "detached HEAD" case,
> another paragraph break and then "To set the tracking information" as a
> new pargraph, perhaps?
>

This way around looks much better and makes a lot more sense. Thanks for the hint.

I couldn't come up with a better way to count remotes than $(git remote | wc -l) as git config only uses the regex for the values and $(git config --list | grep -c '^remote\..*\.url') seems even worse.

I'm kind of two minds about the remote thing. If the branch doesn't have an upstream already (either via checkout -t origin/branch or push -u), making pulling from a remote upstream branch easier might lead to more senseless merges, which is the opposite direction to other changes in pull which ask for a reason, so after we've given them most of the command to run so pull magically works on its own, we ask them to justify it... I don't know, maybe I'm overthinking this.

   cmn
--- 8< ---
Subject: [PATCH] Make git-{pull,rebase} message without tracking information
 friendlier

The current message is too long and at too low a level for anybody to understand it if they don't know about the configuration format already.

The text about setting up a remote is superfluous and doesn't help understand the error that has happened. Show the usage more prominently and explain how to set up the tracking information. If there is only one remote, that name is used instead of the generic <remote>.

Also simplify the message we print on detached HEAD to remove unnecessary information which is better left for the documentation.

Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
---
 git-parse-remote.sh |   42 +++++++++++++++++++-----------------------
 git-pull.sh         |    2 +-
 git-rebase.sh       |    2 +-
 3 files changed, 21 insertions(+), 25 deletions(-)
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index b24119d..4575309 100644
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -57,34 +57,30 @@ error_on_missing_default_upstream () {
 	op_prep="$3"
 	example="$4"
 	branch_name=$(git symbolic-ref -q HEAD)
+	# If there's only one remote, use that in the suggestion
+	remote="<remote>"
+	if test $(git remote | wc -l) -eq 1; then
+	    remote=$(git remote)
+	fi
+
 	if test -z "$branch_name"
 	then
-		echo "You are not currently on a branch, so I cannot use any
-'branch.<branchname>.merge' in your configuration file.
-Please specify which branch you want to $op_type $op_prep on the command
-line and try again (e.g. '$example').
-See git-${cmd}(1) for details."
+		echo "You are not currently on a branch. Please specify which
+branch you want to $op_type $op_prep. See git-${cmd}(1) for details.
+
+    $example
+"
 	else
-		echo "You asked me to $cmd without telling me which branch you
-want to $op_type $op_prep, and 'branch.${branch_name#refs/heads/}.merge' in
-your configuration file does not tell me, either. Please
-specify which branch you want to use on the command line and
-try again (e.g. '$example').
-See git-${cmd}(1) for details.
+		echo "There is no tracking information for the current branch.
+Please specify which branch you want to $op_type $op_prep.
+See git-${cmd}(1) for details
+
+    $example
 
-If you often $op_type $op_prep the same branch, you may want to
-use something like the following in your configuration file:
-    [branch \"${branch_name#refs/heads/}\"]
-    remote = <nickname>
-    merge = <remote-ref>"
-		test rebase = "$op_type" &&
-		echo "    rebase = true"
-		echo "
-    [remote \"<nickname>\"]
-    url = <url>
-    fetch = <refspec>
+If you whish to set tracking information for this branch you can do so with:
 
-See git-config(1) for details."
+    git branch --set-upstream ${branch_name#refs/heads/} $remote/<branch>
+"
 	fi
 	exit 1
 }
diff --git a/git-pull.sh b/git-pull.sh
index d8b64d7..309c7db 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -176,7 +176,7 @@ error_on_no_merge_candidates () {
 	elif [ -z "$curr_branch" -o -z "$upstream" ]; then
 		. git-parse-remote
 		error_on_missing_default_upstream "pull" $op_type $op_prep \
-			"git pull <repository> <refspec>"
+			"git pull <remote> <branch>"
 	else
 		echo "Your configuration specifies to $op_type $op_prep the ref '${upstream#refs/heads/}'"
 		echo "from the remote, but no such ref was fetched."
diff --git a/git-rebase.sh b/git-rebase.sh
index 00ca7b9..69c1374 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -380,7 +380,7 @@ then
 		then
 			. git-parse-remote
 			error_on_missing_default_upstream "rebase" "rebase" \
-				"against" "git rebase <upstream branch>"
+				"against" "git rebase <branch>"
 		fi
 		;;
 	*)	upstream_name="$1"

-- 
1.7.9.2.3.g4346f
Previous: Junio C HamanoNext: Junio C Hamano
Message 10 of 11 in “Make git-{pull,rebase} no-tracking message friendlier”
  1. Make git-{pull,rebase} no-tracking message friendlierCarlos Martín Nieto, Feb 23, 2012
  2. Junio C HamanoFeb 23, 2012
  3. Carlos Martín NietoFeb 27, 2012
  4. Matthieu MoyFeb 27, 2012
  5. Carlos Martín NietoFeb 29, 2012
  6. Matthieu MoyFeb 29, 2012
  7. Carlos Martín NietoFeb 29, 2012
  8. Make git-{pull,rebase} message without tracking information friendlierCarlos Martín Nieto, Feb 29, 2012
  9. Junio C HamanoFeb 29, 2012
  10. Carlos Martín NietoMar 4, 2012
  11. Junio C HamanoMar 5, 2012

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.