[PATCH RFC] show-branch: use pager

This is for consistency with other porcelain commands such as 'log'.

Signed-off-by: Øystein Walle <redacted>
---
The rationale for this patch I hope is consicely explained in the commit
message. I was rather surprised it didn't use a pager as I've gotten used to it
for most commands.

I marked this as an RFC because of Jeff King's comments in
daa0c3d97 where I got the impression this this might not be a good idea.
However I haven't found any bugs and all the tests pass. It is more a huble
suggestion than anything but I thought I might as well send it as a patch.

setup_pager() is already pulled in via cache.h so there was no need to add any
#include directive. I suppose this is as close to a one-liner as it gets :)

Best regards,
Øsse

 builtin/show-branch.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/builtin/show-branch.c b/builtin/show-branch.c
index 90fc6b1..bd3e10c 100644
--- a/builtin/show-branch.c
+++ b/builtin/show-branch.c

@@ -683,6 +683,7 @@ int cmd_show_branch(int ac, const char **av, const char *prefix)
 	};
 
 	git_config(git_show_branch_config, NULL);
+	setup_pager();
 
 	/* If nothing is specified, try the default first */
 	if (ac == 1 && default_num) {

-- 
1.8.2.2

On Thu, Jun 13, 2013 at 08:43:31AM +0200, Øystein Walle wrote:

This is for consistency with other porcelain commands such as 'log'.

I do not use show-branch myself, but being consistent with the other
porcelain commands makes sense to me.

I marked this as an RFC because of Jeff King's comments in
daa0c3d97 where I got the impression this this might not be a good idea.
However I haven't found any bugs and all the tests pass. It is more a huble
suggestion than anything but I thought I might as well send it as a patch.

I don't think the problems described in daa0c3d97 should be an issue for
us, as the purpose of that commit was to delay the color decision until
the last minute. That helps commands which load color config before
having decided on whether to use a pager. In other words, it covers the
exact situation you introduce here:

So I think your patch is fine with respect to those problems.

However, I do not see any need for show_branch to delay its pager setup
at all. Commands like "git diff" and "git log" must do so, because they
do not know whether they want a pager or not until after parsing
command-line arguments. But in this case we are always starting the
pager.

Would it make more sense to just set the USE_PAGER flag in the
"show-branch" entry in git.c (see the "shortlog" entry for an example)?

-Peff

This is for consistency with other porcelain commands such as 'log'.

Signed-off-by: Øystein Walle <redacted>
---
Hi, Jeff

Thanks for the (fast!) feedback and good to hear it won't cause any trouble.

I hadn't actually noticed this mechanism of setting up the pager before now but
I fully agree. Here's an updated version. 

Øsse

 git.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/git.c b/git.c
index 4359086..6d1f6ca 100644
--- a/git.c
+++ b/git.c

@@ -406,7 +406,7 @@ static void handle_internal_command(int argc, const char **argv)
 		{ "send-pack", cmd_send_pack, RUN_SETUP },
 		{ "shortlog", cmd_shortlog, RUN_SETUP_GENTLY | USE_PAGER },
 		{ "show", cmd_show, RUN_SETUP },
-		{ "show-branch", cmd_show_branch, RUN_SETUP },
+		{ "show-branch", cmd_show_branch, RUN_SETUP | USE_PAGER },
 		{ "show-ref", cmd_show_ref, RUN_SETUP },
 		{ "stage", cmd_add, RUN_SETUP | NEED_WORK_TREE },
 		{ "status", cmd_status, RUN_SETUP | NEED_WORK_TREE },

-- 
1.8.2.2