Re: git checkout creates strange '(null)'-branch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Erik Faye-Lund <kusmabite@xxxxxxxxx> writes:

> But if I apply the following patch, the test passes. I'm not saying
> it's the right thing to do, though.
>
> (Warning: white-space damaged because of copying diffs between terminals)
>
> diff --git a/builtin/checkout.c b/builtin/checkout.c
> index 23fc56d..d70e819 100644
> --- a/builtin/checkout.c
> +++ b/builtin/checkout.c
> @@ -1096,8 +1096,11 @@ int cmd_checkout(int argc, const char **argv,
> const char *prefix)
>                 int flag;
>
>                 if (!read_ref_full("HEAD", rev, 0, &flag) &&
> -                   (flag & REF_ISSYMREF) && is_null_sha1(rev))
> +                   (flag & REF_ISSYMREF) && is_null_sha1(rev)) {
> +                       if (!opts.new_branch)
> +                               return 0;
>                         return switch_unborn_to_new_branch(&opts);
> +               }
>         }
>         return switch_branches(&opts, &new);
>  }

This patch, if we ignore submodules for a while, actually makes sense to
me.  If you have a commit, you are on that commit and you haven't done
anything since you have checked out that commit, "git checkout" (no other
parameters) would be a no-op.  If you "git init" a repository, and you
haven't done anything since then, the above makes "git checkout" (no other
parameters) a no-op.

Am I missing some corner cases that we _should_ error out, perhaps for the
sake of safety?

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]