All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jeff@garzik.org>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [ANNOUNCE] GIT 1.6.4.rc1
Date: Wed, 15 Jul 2009 23:59:20 -0400	[thread overview]
Message-ID: <4A5EA598.5050801@garzik.org> (raw)
In-Reply-To: <7vmy75bg2f.fsf@alter.siamese.dyndns.org>

Junio C Hamano wrote:
> GIT v1.6.4 Release Notes (draft)
> ================================
> 
> With the next major release, "git push" into a branch that is
> currently checked out will be refused by default.  You can choose
> what should happen upon such a push by setting the configuration
> variable receive.denyCurrentBranch in the receiving repository.
> 
> To ease the transition plan, the receiving repository of such a
> push running this release will issue a big warning when the
> configuration variable is missing.  Please refer to:
> 
>   http://git.or.cz/gitwiki/GitFaq#non-bare
>   http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007
> 
> for more details on the reason why this change is needed and the
> transition plan.
> 
> For a similar reason, "git push $there :$killed" to delete the branch
> $killed in a remote repository $there, if $killed branch is the current
> branch pointed at by its HEAD, gets a large warning.  You can choose what
> should happen upon such a push by setting the configuration variable
> receive.denyDeleteCurrent in the receiving repository.
> 
> When the user does not tell "git push" what to push, it has always
> pushed matching refs.  For some people it is unexpected, and a new
> configuration variable push.default has been introduced to allow
> changing a different default behaviour.  To advertise the new feature,
> a big warning is issued if this is not configured and a git push without
> arguments is attempted.
> 
> 	Side note: we might want to tone this down, as it does not seem
> 	likely for us to change the default behaviour when this option is
> 	not set.


Is there some sort of guide to the new best practices for handling trees 
such as git.kernel.org, where one pushes into "foo.git" directly, and 
there is no checked-out source code at all?

I've been getting the multi-line "warning: Updating the currently 
checked out branch may cause confusion" message, but ignoring it for 
now, because it does not appear to apply to my situation (no checked-out 
work tree).

Advice appreciated...

	Jeff




  parent reply	other threads:[~2009-07-16  4:01 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-16  0:57 [ANNOUNCE] GIT 1.6.4.rc1 Junio C Hamano
2009-07-16  3:51 ` Tommy Nordgren
2009-07-16  7:37   ` Mike Ralphson
2009-07-17 15:16     ` Tommy Nordgren
2009-07-16  3:59 ` Jeff Garzik [this message]
2009-07-16  6:31   ` Junio C Hamano
2009-07-16  6:43     ` Jeff Garzik
2009-07-16  6:45       ` Jeff Garzik
2009-07-16  6:48       ` Felipe Balbi
2009-07-16  7:17         ` Jeff Garzik
2009-07-16  7:21           ` Felipe Balbi
2009-07-16  6:55       ` Junio C Hamano
2009-07-16  7:15         ` Jeff Garzik
2009-07-16  7:27           ` Junio C Hamano
2009-07-16 20:19             ` Jeff Garzik
2009-07-16  6:55 ` [ANNOUNCE] " Nicolas Sebrecht
2009-07-18 23:05 ` [ANNOUNCE] " Nanako Shiraishi
2009-07-19  0:19   ` Junio C Hamano
2009-07-19 14:45     ` Nanako Shiraishi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A5EA598.5050801@garzik.org \
    --to=jeff@garzik.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.