# [PATCH] git checkout: don't warn about unborn branch if -f is already passed 3 messages from 2008-11-24 to 2008-12-01. Participants: Matt McCutchen, Junio C Hamano. Thread: https://gitlist.dev/t/16437 ## Matt McCutchen, 2008-11-24 06:55 Subject: [PATCH] git checkout: don't warn about unborn branch if -f is already passed Message-ID: <1227509722.32583.0.camel@mattlaptop2.local> URL: https://gitlist.dev/e/1227509722.32583.0.camel%40mattlaptop2.local ``` I think it's unnecessary to warn that the checkout has been forced due to an unborn current branch if -f has been explicitly passed. For one project, I am using git-new-workdir to create workdirs from a bare repository whose HEAD is set to an unborn branch, and this warning started to irritate me. Signed-off-by: Matt McCutchen --- builtin-checkout.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/builtin-checkout.c b/builtin-checkout.c index 464fd25..7f3bd7b 100644 --- a/builtin-checkout.c +++ b/builtin-checkout.c @@ -553,7 +553,7 @@ static int switch_branches(struct checkout_opts *opts, struct branch_info *new) if (!opts->quiet && !old.path && old.commit && new->commit != old.commit) describe_detached_head("Previous HEAD position was", old.commit); - if (!old.commit) { + if (!old.commit && !opts->force) { if (!opts->quiet) { fprintf(stderr, "warning: You appear to be on a branch yet to be born.\n"); fprintf(stderr, "warning: Forcing checkout of %s.\n", new->name); -- 1.6.0.2.593.g91df ``` ## Junio C Hamano, 2008-11-26 19:46 Subject: Re: [PATCH] git checkout: don't warn about unborn branch if -f is already passed Message-ID: <7vr64yfexp.fsf@gitster.siamese.dyndns.org> URL: https://gitlist.dev/e/7vr64yfexp.fsf%40gitster.siamese.dyndns.org In-Reply-To: <1227509722.32583.0.camel@mattlaptop2.local> ``` Matt McCutchen writes: > I think it's unnecessary to warn that the checkout has been forced due to an > unborn current branch if -f has been explicitly passed. For one project, I am > using git-new-workdir to create workdirs from a bare repository whose HEAD is > set to an unborn branch, and this warning started to irritate me. I doubt anybody minds this particular change per-se, but I wonder what the justification of keeping a dangling HEAD in a bare repository is. After all, the primary intended purpose of a bare repository is to serve as a distribution point (i.e. something you can clone from), and I think a dangling HEAD interferes with the usual operation of clone (although I've never tested this). Care to explain why? ``` ## Matt McCutchen, 2008-12-01 16:47 Subject: Re: [PATCH] git checkout: don't warn about unborn branch if -f is already passed Message-ID: <1228150047.2643.5.camel@mattlaptop2.local> URL: https://gitlist.dev/e/1228150047.2643.5.camel%40mattlaptop2.local In-Reply-To: <7vr64yfexp.fsf@gitster.siamese.dyndns.org> ``` On Wed, 2008-11-26 at 11:46 -0800, Junio C Hamano wrote: > Matt McCutchen writes: > > > I think it's unnecessary to warn that the checkout has been forced due to an > > unborn current branch if -f has been explicitly passed. For one project, I am > > using git-new-workdir to create workdirs from a bare repository whose HEAD is > > set to an unborn branch, and this warning started to irritate me. > > I doubt anybody minds this particular change per-se, but I wonder what the > justification of keeping a dangling HEAD in a bare repository is. > > After all, the primary intended purpose of a bare repository is to serve > as a distribution point (i.e. something you can clone from), and I think a > dangling HEAD interferes with the usual operation of clone (although I've > never tested this). > > Care to explain why? I am taking a course with six programming projects. I want a separate working tree for each project, but I want all the working trees connected to the same repository because I often copy changes from one project to another and that makes it more convenient to inspect the history of one project while I am working on another. I didn't want to put the repository inside an arbitrary one of the working trees, so I left it bare, and I didn't want to point its HEAD to an arbitrary one of the projects, so I left it unborn. The upshot is that I am using a bare repository as a distribution point for *working trees* (via git-new-workdir), not for push/pull. Matt ```