Suspected bug on `git -C <rp> rev-list --all` where <rp> has 0 commits

Suspected bug on `git -C <rp> rev-list --all` where <rp> has 0 commits

[yac]

Hello

basics:

% rpm -q git git-core
git-2.6.2-2.1.x86_64
git-core-2.6.2-2.1.x86_64

~ % grep PRETTY_NAME /etc/os-release
PRETTY_NAME="openSUSE Tumbleweed (20151030) (x86_64)"

current behavior:

~ % git init no-commits
Initialized empty Git repository in /home/tester/no-commits/.git/
~ % git -C no-commits rev-list --all
usage: git rev-list [OPTION] <commit-id>... [ -- paths... ]
  limiting output:
    --max-count=<n>
    --max-age=<epoch>
    --min-age=<epoch>
    --sparse
    --no-merges
    --min-parents=<n>
    --no-min-parents
    --max-parents=<n>
    --no-max-parents
    --remove-empty
    --all
    --branches
    --tags
    --remotes
    --stdin
    --quiet
  ordering output:
    --topo-order
    --date-order
    --reverse
  formatting output:
    --parents
    --children
    --objects | --objects-edge
    --unpacked
    --header | --pretty
    --abbrev=<n> | --no-abbrev
    --abbrev-commit
    --left-right
    --count
  special purpose:
    --bisect
    --bisect-vars
    --bisect-all
~ % echo $?
129

expected behavior:

~ % git -C no-commits rev-list --all
~ % echo $?
0

Re: Suspected bug on `git -C <rp> rev-list --all` where <rp> has 0 commits

[Atousa Duprat]

I agree with Yac that this error is unwarranted, though it's been like
that since forever.
If a repo is empty, git rev-list should probably just return without
erroring out.
The fix is trivial, if the list agrees that this is in fact legit.

Atousa

On Wed, Nov 11, 2015 at 10:26 AM, yac <yac@blesmrt.net> wrote:
> Hello
>
> basics:
>
> % rpm -q git git-core
> git-2.6.2-2.1.x86_64
> git-core-2.6.2-2.1.x86_64
>
> ~ % grep PRETTY_NAME /etc/os-release
> PRETTY_NAME="openSUSE Tumbleweed (20151030) (x86_64)"
>
> current behavior:
>
> ~ % git init no-commits
> Initialized empty Git repository in /home/tester/no-commits/.git/
> ~ % git -C no-commits rev-list --all
> usage: git rev-list [OPTION] <commit-id>... [ -- paths... ]
>   limiting output:
>     --max-count=<n>
>     --max-age=<epoch>
>     --min-age=<epoch>
>     --sparse
>     --no-merges
>     --min-parents=<n>
>     --no-min-parents
>     --max-parents=<n>
>     --no-max-parents
>     --remove-empty
>     --all
>     --branches
>     --tags
>     --remotes
>     --stdin
>     --quiet
>   ordering output:
>     --topo-order
>     --date-order
>     --reverse
>   formatting output:
>     --parents
>     --children
>     --objects | --objects-edge
>     --unpacked
>     --header | --pretty
>     --abbrev=<n> | --no-abbrev
>     --abbrev-commit
>     --left-right
>     --count
>   special purpose:
>     --bisect
>     --bisect-vars
>     --bisect-all
> ~ % echo $?
> 129
>
> expected behavior:
>
> ~ % git -C no-commits rev-list --all
> ~ % echo $?
> 0
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v1] git rev-list doesn't complain when repo is empty

[atousa.p]

From: Atousa Pahlevan Duprat <apahlevan@ieee.org>

Signed-off-by: Atousa Pahlevan Duprat <apahlevan@ieee.org>
---
 builtin/rev-list.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/builtin/rev-list.c b/builtin/rev-list.c
index d80d1ed..f71b87f 100644
--- a/builtin/rev-list.c
+++ b/builtin/rev-list.c
@@ -348,7 +348,7 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
 	     (!(revs.tag_objects || revs.tree_objects || revs.blob_objects) &&
 	      !revs.pending.nr)) ||
 	    revs.diff)
-		usage(rev_list_usage);
+               return 0; // empty repo
 
 	if (revs.show_notes)
 		die(_("rev-list does not support display of notes"));
-- 
2.4.9 (Apple Git-60)

Re: Suspected bug on `git -C <rp> rev-list --all` where <rp> has 0 commits

[Jeff King]

On Tue, Nov 24, 2015 at 10:56:50PM -0800, Atousa Duprat wrote:

> I agree with Yac that this error is unwarranted, though it's been like
> that since forever.
> If a repo is empty, git rev-list should probably just return without
> erroring out.
> The fix is trivial, if the list agrees that this is in fact legit.

I think we had a similar discussion for "git log" with an empty HEAD,
and decided that it was better to keep the behavior the same for
compatibility reasons. I think that would apply doubly for rev-list,
which is used by scripts.

In the "log" case, we did improve the error message:

  $ git init
  $ git.v2.5.0 log
  fatal: bad default revision 'HEAD'
  $ git.v2.6.3 log
  fatal: your current branch 'master' does not have any commits yet

Maybe a good first step would be improving the error message?

-Peff

Re: [PATCH v1] git rev-list doesn't complain when repo is empty

[Jeff King]

On Tue, Nov 24, 2015 at 11:00:53PM -0800, atousa.p@gmail.com wrote:

> From: Atousa Pahlevan Duprat <apahlevan@ieee.org>
> 
> Signed-off-by: Atousa Pahlevan Duprat <apahlevan@ieee.org>
> ---
>  builtin/rev-list.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/builtin/rev-list.c b/builtin/rev-list.c
> index d80d1ed..f71b87f 100644
> --- a/builtin/rev-list.c
> +++ b/builtin/rev-list.c
> @@ -348,7 +348,7 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
>  	     (!(revs.tag_objects || revs.tree_objects || revs.blob_objects) &&
>  	      !revs.pending.nr)) ||
>  	    revs.diff)
> -		usage(rev_list_usage);
> +               return 0; // empty repo

Even if we were to agree that rev-list should exit with code 0 for "git
rev-list --all" in an empty repo, I do not think this patch is the right
way to do it. It also catches:

  git rev-list

with no arguments in a non-empty repository, which should produce a
usage() message.

-Peff