[ANNOUNCE] GIT 1.6.4.rc1

[ANNOUNCE] GIT 1.6.4.rc1

[Junio C Hamano]

A release candidate GIT 1.6.4.rc1 is available at the usual places
for testing:

  http://www.kernel.org/pub/software/scm/git/

  git-1.6.4.rc1.tar.{gz,bz2}			(source tarball)
  git-htmldocs-1.6.4.rc1.tar.{gz,bz2}		(preformatted docs)
  git-manpages-1.6.4.rc1.tar.{gz,bz2}		(preformatted docs)

The RPM binary packages for a few architectures are found in:

  testing/git-*-1.6.4.rc1-1.fc9.$arch.rpm	(RPM)

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.


Updates since v1.6.3
--------------------

(subsystems)

 * gitweb Perl style clean-up.

 * git-svn updates, including a new --authors-prog option to map author
   names by invoking an external program.

(portability)

 * We feed iconv with "UTF-8" instead of "utf8"; the former is
   understood more widely.

(performance)

(usability, bells and whistles)

 * "git add --edit" lets users edit the whole patch text to fine-tune what
   is added to the index.

 * "git log --graph" draws graphs more compactly by using horizonal lines
   when able.

 * "git log --decorate" shows shorter refnames by stripping well-known
   refs/* prefix.

 * "git send-email" understands quoted aliases in .mailrc files (might
   have to be backported to 1.6.3.X).

 * "git send-email" can fetch the sender address from the configuration
   variable "sendmail.from" (and "sendmail.<identity>.from").

 * "git show-branch" can color its output.

 * "add" and "update" subcommands to "git submodule" learned --reference
   option to use local clone with references.

(developers)

 * A major part of the "git bisect" wrapper has moved to C.

Fixes since v1.6.3
------------------

All of the fixes in v1.6.3.X maintenance series are included in this
release, unless otherwise noted.

Here are fixes that this release has, but have not been backported to
v1.6.3.X series.

 * The way Git.pm sets up a Repository object was not friendly to callers
   that chdir around.  It now internally records the repository location
   as an absolute path when autodetected.

Re: [ANNOUNCE] GIT 1.6.4.rc1

[Jeff Garzik]

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

Re: [ANNOUNCE] GIT 1.6.4.rc1

[Junio C Hamano]

Jeff Garzik <jeff@garzik.org> writes:

> 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 think old repositories will be helped if you add

	[core]
        	bare

to their foo.git/config files.

Re: [ANNOUNCE] GIT 1.6.4.rc1

[Jeff Garzik]

Junio C Hamano wrote:
> Jeff Garzik <jeff@garzik.org> writes:
> 
>> 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 think old repositories will be helped if you add
> 
> 	[core]
>         	bare
> 
> to their foo.git/config files.

Thanks.  What about cloning new repositories?  Real world example:

Local workstation has /spare/repo/cld/.git repository, with checked-out 
working tree.

I want to publish this tree to the world via a *.kernel.org-like system, 
so my task is to

	scp -r /spare/repo/cld/.git remote.example.com:/pub/scm/cld.git

but if I do this with scp, then future pushes to 
remote.example.com:/pub/scm/cld.git emit the warning about updating the 
currently checked-out branch -- even though there are no checked-out 
files.  The checked-out files were not copied in the scp.

Regards,

	Jeff

Re: [ANNOUNCE] GIT 1.6.4.rc1

[Jeff Garzik]

Jeff Garzik wrote:
> I want to publish this tree to the world via a *.kernel.org-like system, 
> so my task is to
> 
>     scp -r /spare/repo/cld/.git remote.example.com:/pub/scm/cld.git
> 
> but if I do this with scp, then future pushes to 
> remote.example.com:/pub/scm/cld.git emit the warning about updating the 
> currently checked-out branch -- even though there are no checked-out 
> files.  The checked-out files were not copied in the scp.

IOW -- do I just edit the config for this case too, or is there some 
'git clone --bare' magic that can work across ssh, as shown above?

It is easy to clone -from- a remote, but not so easy to clone -to- a 
new, bare remote.

	Jeff

Re: [ANNOUNCE] GIT 1.6.4.rc1

[Felipe Balbi]

On Thu, Jul 16, 2009 at 08:43:21AM +0200, ext Jeff Garzik wrote:
> Junio C Hamano wrote:
> > Jeff Garzik <jeff@garzik.org> writes:
> > 
> >> 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 think old repositories will be helped if you add
> > 
> > 	[core]
> >         	bare
> > 
> > to their foo.git/config files.
> 
> Thanks.  What about cloning new repositories?  Real world example:
> 
> Local workstation has /spare/repo/cld/.git repository, with checked-out 
> working tree.
> 
> I want to publish this tree to the world via a *.kernel.org-like system, 
> so my task is to
> 
> 	scp -r /spare/repo/cld/.git remote.example.com:/pub/scm/cld.git
> 
> but if I do this with scp, then future pushes to 
> remote.example.com:/pub/scm/cld.git emit the warning about updating the 
> currently checked-out branch -- even though there are no checked-out 
> files.  The checked-out files were not copied in the scp.

how about you create the bare repository on the kernel.org-like server
and then push cld to it ?

-- 
balbi

Re: [ANNOUNCE] GIT 1.6.4.rc1

[Junio C Hamano]

Jeff Garzik <jeff@garzik.org> writes:

> I want to publish this tree to the world via a *.kernel.org-like
> system, so my task is to
>
> 	scp -r /spare/repo/cld/.git remote.example.com:/pub/scm/cld.git
>
> but if I do this with scp, then future pushes to
> remote.example.com:/pub/scm/cld.git emit the warning about updating
> the currently checked-out branch

I think "scp -r" is a wrong way to "clone", as it will copy .git/config
that is specific to your local work tree that does not apply to the
situation at remote.example.com anyway.  You do not want to push into your
local repository with a work tree you are "scp -r"ing out of, but you do
want to push into the one at remote.example.com.

Interestingly enough, we had a two separate thread about making a bare
repository out of a repository with a work tree today ;-)

	remote.example.com$ cd /pub/scm/
        remote.example.com$ git clone --bare over.there:/spare/repo/cld/.git cld.git

Re: [ANNOUNCE] GIT 1.6.4.rc1

[Jeff Garzik]

Junio C Hamano wrote:
> Jeff Garzik <jeff@garzik.org> writes:
> 
>> I want to publish this tree to the world via a *.kernel.org-like
>> system, so my task is to
>>
>> 	scp -r /spare/repo/cld/.git remote.example.com:/pub/scm/cld.git
>>
>> but if I do this with scp, then future pushes to
>> remote.example.com:/pub/scm/cld.git emit the warning about updating
>> the currently checked-out branch
> 
> I think "scp -r" is a wrong way to "clone", as it will copy .git/config
> that is specific to your local work tree that does not apply to the
> situation at remote.example.com anyway.  You do not want to push into your
> local repository with a work tree you are "scp -r"ing out of, but you do
> want to push into the one at remote.example.com.
> 
> Interestingly enough, we had a two separate thread about making a bare
> repository out of a repository with a work tree today ;-)
> 
> 	remote.example.com$ cd /pub/scm/
>         remote.example.com$ git clone --bare over.there:/spare/repo/cld/.git cld.git

That direction doesn't work due to firewalls, hence the scp out /to/ 
remote.example.com.

So, will this make git happy?  :)

[starting on local machine, where I do development]
1) scp -r /spare/repo/cld remote.example.com:/tmp

2) ssh remote.example.com

3) cd /pub/scm

4) git clone --bare /tmp/cld/.git cld.git

Regards,

	Jeff

Re: [ANNOUNCE] GIT 1.6.4.rc1

[Jeff Garzik]

Felipe Balbi wrote:
> On Thu, Jul 16, 2009 at 08:43:21AM +0200, ext Jeff Garzik wrote:
>> Junio C Hamano wrote:
>>> Jeff Garzik <jeff@garzik.org> writes:
>>>
>>>> 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 think old repositories will be helped if you add
>>>
>>> 	[core]
>>>         	bare
>>>
>>> to their foo.git/config files.
>> Thanks.  What about cloning new repositories?  Real world example:
>>
>> Local workstation has /spare/repo/cld/.git repository, with checked-out 
>> working tree.
>>
>> I want to publish this tree to the world via a *.kernel.org-like system, 
>> so my task is to
>>
>> 	scp -r /spare/repo/cld/.git remote.example.com:/pub/scm/cld.git
>>
>> but if I do this with scp, then future pushes to 
>> remote.example.com:/pub/scm/cld.git emit the warning about updating the 
>> currently checked-out branch -- even though there are no checked-out 
>> files.  The checked-out files were not copied in the scp.
> 
> how about you create the bare repository on the kernel.org-like server
> and then push cld to it ?

You mean use 'git init-db', like this?

1) remote: cd /pub/scm ; mkdir cld.git ; GIT_DIR=cld.git git init-db

2) local: cd /spare/repo/cld ; git push --force --all \
	remote.ex.com/pub/scm/cld.git

I suppose that would work...

	Jeff

Re: [ANNOUNCE] GIT 1.6.4.rc1

[Felipe Balbi]

On Thu, Jul 16, 2009 at 09:17:51AM +0200, ext Jeff Garzik wrote:
> Felipe Balbi wrote:
> > On Thu, Jul 16, 2009 at 08:43:21AM +0200, ext Jeff Garzik wrote:
> >> Junio C Hamano wrote:
> >>> Jeff Garzik <jeff@garzik.org> writes:
> >>>
> >>>> 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 think old repositories will be helped if you add
> >>>
> >>> 	[core]
> >>>         	bare
> >>>
> >>> to their foo.git/config files.
> >> Thanks.  What about cloning new repositories?  Real world example:
> >>
> >> Local workstation has /spare/repo/cld/.git repository, with checked-out 
> >> working tree.
> >>
> >> I want to publish this tree to the world via a *.kernel.org-like system, 
> >> so my task is to
> >>
> >> 	scp -r /spare/repo/cld/.git remote.example.com:/pub/scm/cld.git
> >>
> >> but if I do this with scp, then future pushes to 
> >> remote.example.com:/pub/scm/cld.git emit the warning about updating the 
> >> currently checked-out branch -- even though there are no checked-out 
> >> files.  The checked-out files were not copied in the scp.
> > 
> > how about you create the bare repository on the kernel.org-like server
> > and then push cld to it ?
> 
> You mean use 'git init-db', like this?
> 
> 1) remote: cd /pub/scm ; mkdir cld.git ; GIT_DIR=cld.git git init-db
> 
> 2) local: cd /spare/repo/cld ; git push --force --all \
> 	remote.ex.com/pub/scm/cld.git
> 
> I suppose that would work...

yes, exactly :-)

-- 
balbi

Re: [ANNOUNCE] GIT 1.6.4.rc1

[Junio C Hamano]

Jeff Garzik <jeff@garzik.org> writes:

> That direction doesn't work due to firewalls, hence the scp out /to/
> remote.example.com.

Ah, then the "git init --bare" at remote followed by pushing -all into it,
suggested in your other subthread, would be an appropriate way.

Re: [ANNOUNCE] GIT 1.6.4.rc1

[Jeff Garzik]

Junio C Hamano wrote:
> Jeff Garzik <jeff@garzik.org> writes:
> 
>> That direction doesn't work due to firewalls, hence the scp out /to/
>> remote.example.com.
> 
> Ah, then the "git init --bare" at remote followed by pushing -all into it,
> suggested in your other subthread, would be an appropriate way.

Thanks!

	Jeff