[PATCH] git checkout: don't warn about unborn branch if -f is already passed

[PATCH] git checkout: don't warn about unborn branch if -f is already passed

[Matt McCutchen]

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 <matt@mattmccutchen.net>
---
 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

Re: [PATCH] git checkout: don't warn about unborn branch if -f is already passed

[Junio C Hamano]

Matt McCutchen <matt@mattmccutchen.net> 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?

Re: [PATCH] git checkout: don't warn about unborn branch if -f is already passed

[Matt McCutchen]

On Wed, 2008-11-26 at 11:46 -0800, Junio C Hamano wrote:
> Matt McCutchen <matt@mattmccutchen.net> 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