What will happen to git.git in the near future

What will happen to git.git in the near future

[Junio C Hamano]

Here are some random thoughts on the short-term plan.  We are
currently at 1.4.2 release (and "maint" is at 1.4.2.1).

I do not know when the changes are big enough to start the 1.5
series, so tentatively I'll call the next one 1.4.3, the one
that follows 1.4.4, and so on, in the following description.

 - git-resolve is deprecated on "master" and will continue to be
   so until 1.4.3.  We will remove it before 1.4.4 happens.

 - We will deprecate the original merge-recursive written in
   Python by renaming it to merge-recursive-old, and make
   merge-recur to take its place.  1.4.3 will ship that way.
   Sometime in not so distant future we will remove
   merge-recursive-old and merge-recur, perhaps in 1.4.5.

 - We should deprecate git-tar-tree.  However, it has been
   around and advertised for quite some time, so we need to make
   sure people would not get burned too badly.  It might be
   worthwhile to rewrite git-tar-tree as a thin wrapper to
   "git-archive --format=tar" and remove git-upload-tar now (in
   other words, "git-tar-tree --remote" will continue to work,
   but it will talk with "git-upload-archive", not with
   "git-upload-tar" on the other end), release 1.4.3 with it
   with a deprecation warning, and then remove it in 1.4.5.

 - virtual hosting by git-daemon should be ready.  I will push
   it out to "master" before 1.4.3 release.

 - packed-refs still has a few issues before it can hit
   "master". 

   - deleting branches does not really work yet, as there have
     been some discussions on the list.

   - dumb transports are unaware of it.  Trying to fetch a
     ref that is packed would not work.

   I feel this series to be a significant enough change that
   deserve a bit careful handling.  Perhaps in 1.4.4 release.

 - The per-branch configuration to control git-fetch is Ok in
   itself, and we might want to push it out to "master" and
   release 1.4.3 with it in its current form.  But the topic
   might want to learn other tricks to have more comprehensive
   per-branch configuration support.  We will see how it plays
   out.

 - Git.pm lost Git.xs which hopefully would make it a bit easier
   to work for wider audiences.  Hopefully we can push it out to
   "master" soon and see if anybody screams.  Depending on what
   happens, it may be in 1.4.3 release.

 - git-show-ref and git-for-each-ref serve similar purpose (when
   viewed in a bigger picture) but with different interface and
   different set of features.  We should consolidate them into
   one command before they hit in any released version.

 - git-log's support for --committer=, --author= and --grep= is
   Ok by itself, but I feel we should do a bit more to make it
   useful.  Currently we cannot say "written by A and committed
   by B", or "written by C and have word D in the log".  Because
   the boolean logic between match patterns we use internally
   are line oriented, borrowing --and from git-grep is not
   enough ("--committer=A --and --author=B" would mean 'if the
   commit object has a header line that matches "^committer .*A"
   and "^author .*B" at the same time', which is not what we
   want).  We would need a "buffer-wide AND" that can express
   'see if there is a header line that matches "^committer .*A"
   and a header line, which may be different from the
   "committer" one, that matches "^author .*B"'.

   Implementing "buffer-wide AND" will involve updating git-grep
   but as a side effect we will also be able to say "find files
   that have word A and B in them", which would be a useful
   thing.  I'd push the current implementation out to "master"
   soon and release 1.4.3 with it, and defer implementation of
   the buffer-wide AND to a later version.

 - generation of version 3 pack files is 1.4.3 material.

 - new pack object format to express delta base object by the
   offset in the stream will start cooking in "next" soon; I
   just haven't got around to merge it yet.  I feel this to be
   significant enough change that can deserve a bit careful
   handling.  Perhaps in 1.4.4 or 1.4.5 release.

 - windowed mmap() of pack data is an important change (I do not
   mean to pressure Shawn by saying this) and needs to be cooked
   carefully.  I do not expect it to be ready until 1.4.5
   release at the earliest.

Re: What will happen to git.git in the near future

[Petr Baudis]

Dear diary, on Sun, Sep 24, 2006 at 12:37:57PM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
>  - git-resolve is deprecated on "master" and will continue to be
>    so until 1.4.3.  We will remove it before 1.4.4 happens.

Woo-hoo!

>  - We should deprecate git-tar-tree.  However, it has been
>    around and advertised for quite some time, so we need to make
>    sure people would not get burned too badly.  It might be
>    worthwhile to rewrite git-tar-tree as a thin wrapper to
>    "git-archive --format=tar" and remove git-upload-tar now (in
>    other words, "git-tar-tree --remote" will continue to work,
>    but it will talk with "git-upload-archive", not with
>    "git-upload-tar" on the other end), release 1.4.3 with it
>    with a deprecation warning, and then remove it in 1.4.5.

I believe this is way too rushed, please consider keeping git-tar-tree
as the thin wrapper _much_ longer.

We still have ssh-pull and ssh-push around after more than a year of
their deprecation. (BTW, we might as well consider removing those. ;)

>  - packed-refs still has a few issues before it can hit
>    "master". 
> 
>    - deleting branches does not really work yet, as there have
>      been some discussions on the list.
> 
>    - dumb transports are unaware of it.  Trying to fetch a
>      ref that is packed would not work.

This is a big problem.

>    I feel this series to be a significant enough change that
>    deserve a bit careful handling.  Perhaps in 1.4.4 release.

I agree, there are some subtle changes there (like the heads ordering)
that could cause unforeseen problems, better be careful about it.

>  - Git.pm lost Git.xs which hopefully would make it a bit easier
>    to work for wider audiences.  Hopefully we can push it out to
>    "master" soon and see if anybody screams.  Depending on what
>    happens, it may be in 1.4.3 release.

Woo-hoo!

>  - git-show-ref and git-for-each-ref serve similar purpose (when
>    viewed in a bigger picture) but with different interface and
>    different set of features.  We should consolidate them into
>    one command before they hit in any released version.

Do I understand it correctly that those are the only interfaces for
scripts to access packed refs?

Ideally there would be some transition period provided so that I can
teach Cogito about them without having it broken for repositories with
packed refs for some time. But since packing refs is optional and
explicit action, perhaps it's not so critical.

Still, I looked forward for having those tools in the next release so
that Cogito can use them. Oh well. :)

>    Implementing "buffer-wide AND" will involve updating git-grep
>    but as a side effect we will also be able to say "find files
>    that have word A and B in them", which would be a useful
>    thing.  I'd push the current implementation out to "master"
>    soon and release 1.4.3 with it, and defer implementation of
>    the buffer-wide AND to a later version.

Yes. Those options are cool as they are and they can speed up gitweb's
search as well as cg-log -u.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)

Re: What will happen to git.git in the near future

[Rene Scharfe]

Junio C Hamano schrieb:
>  - We should deprecate git-tar-tree.  However, it has been
>    around and advertised for quite some time, so we need to make
>    sure people would not get burned too badly.  It might be
>    worthwhile to rewrite git-tar-tree as a thin wrapper to
>    "git-archive --format=tar" and remove git-upload-tar now (in
>    other words, "git-tar-tree --remote" will continue to work,
>    but it will talk with "git-upload-archive", not with
>    "git-upload-tar" on the other end), release 1.4.3 with it
>    with a deprecation warning, and then remove it in 1.4.5.

Hmm.  The local case in git-tar-tree is already a thin wrapper.
How about something like this shell script as a replacement for
the entire command?

René

--- snip! --
#!/bin/sh
#
# Copyright (C) 2006 Rene Scharfe

USAGE='[--remote=<repo>] <tree-ish> [basedir]'
. git-sh-setup

case "$1" in
--remote=*)	remote=1;;
*)		remote=0;;
esac

case "$#,$remote" in
1,0)	exec git-archive --format=tar                     "$1";;
2,0)	exec git-archive --format=tar --prefix="$2"/      "$1";;
2,1)	exec git-archive --format=tar                "$1" "$2";;
3,1)	exec git-archive --format=tar --prefix="$3"/ "$1" "$2";;
*)	usage;;
esac

Re: What will happen to git.git in the near future

[Johannes Schindelin]

Hi,

On Sun, 24 Sep 2006, Rene Scharfe wrote:

> Junio C Hamano schrieb:
> >  - We should deprecate git-tar-tree.  However, it has been
> >    around and advertised for quite some time, so we need to make
> >    sure people would not get burned too badly.  It might be
> >    worthwhile to rewrite git-tar-tree as a thin wrapper to
> >    "git-archive --format=tar" and remove git-upload-tar now (in
> >    other words, "git-tar-tree --remote" will continue to work,
> >    but it will talk with "git-upload-archive", not with
> >    "git-upload-tar" on the other end), release 1.4.3 with it
> >    with a deprecation warning, and then remove it in 1.4.5.
> 
> Hmm.  The local case in git-tar-tree is already a thin wrapper.
> How about something like this shell script as a replacement for
> the entire command?

I think that this could be done very efficiently (both in terms of time 
and size) as a "pure" builtin, i.e. something with works as
"git tar-tree", but not as "git-tar-tree". Of course, this would break 
scripts using the latter instead of the former. Just my 2 yinyangs.

Ciao,
Dscho

Re: What will happen to git.git in the near future

[A Large Angry SCM]

Johannes Schindelin wrote:
[...]
> I think that this could be done very efficiently (both in terms of time 
> and size) as a "pure" builtin, i.e. something with works as
> "git tar-tree", but not as "git-tar-tree". Of course, this would break 
> scripts using the latter instead of the former. Just my 2 yinyangs.

That would be a bug. If "git foo" works, then "git-foo" should also work.

Re: What will happen to git.git in the near future

[Junio C Hamano]

I've tagged the tip of the master as v1.4.3-rc1 tonight, after
merging things that I listed in the message last week to be
merged from "next".

Have fun.

Re: What will happen to git.git in the near future

[Linus Torvalds]

On Sun, 1 Oct 2006, Junio C Hamano wrote:
>
> I've tagged the tip of the master as v1.4.3-rc1 tonight, after
> merging things that I listed in the message last week to be
> merged from "next".
> 
> Have fun.

I hate that perl crud.

	...
	make -C perl
	make[1]: Entering directory `/home/torvalds/git/perl'
	cp private-Error.pm blib/lib/Error.pm
	cp Git.pm blib/lib/Git.pm
	gcc -c   -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32   -DVERSION=\"0.01\" -DXS_VERSION=\"0.01\" -fPIC "-I/usr/lib/perl5/5.8.8/ppc-linux-thread-multi/CORE"   Git.c
	In file included from Git.xs:8:
	../cache.h:6:10: error: #include expects "FILENAME" or <FILENAME>
	Git.xs: In function 'XS_Git_xs_version':
	Git.xs:62: error: 'GIT_VERSION' undeclared (first use in this function)
	Git.xs:62: error: (Each undeclared identifier is reported only once
	Git.xs:62: error: for each function it appears in.)
	make[1]: *** [Git.o] Error 1
	make[1]: Leaving directory `/home/torvalds/git/perl'
	make: *** [all] Error 2

I don't like how git now doesn't compile just out of the box on a 
perfectly regular FC5 box.

The whole Git.xs stuff has been buggered from the very beginning, at some 
point somebody needs to just admit it. 

Please?

And how come does this actually work for anybody else? I've got PPC_SHA1 
defined, but I don't see what the difference is..

		Linus

Re: What will happen to git.git in the near future

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

> On Sun, 1 Oct 2006, Junio C Hamano wrote:
>>
>> I've tagged the tip of the master as v1.4.3-rc1 tonight, after
>> merging things that I listed in the message last week to be
>> merged from "next".
>> 
>> Have fun.
>
> I hate that perl crud.
>...
> 	Git.xs: In function 'XS_Git_xs_version':
> 	Git.xs:62: error: 'GIT_VERSION' undeclared (first use in this function)
> 	Git.xs:62: error: (Each undeclared identifier is reported only once
> 	Git.xs:62: error: for each function it appears in.)
> 	make[1]: *** [Git.o] Error 1
> 	make[1]: Leaving directory `/home/torvalds/git/perl'
> 	make: *** [all] Error 2
>
> I don't like how git now doesn't compile just out of the box on a 
> perfectly regular FC5 box.

Everybody hated the perl crud, so we removed Git.xs and is not
even part of the source anymore.

This is a symptom that Git.c leftover from an earlier build was
in the working tree.  Could you try running "rm -f perl/Git.c"
before building and see if it helps?

The sad thing is that we do not ship Git.xs nor generate Git.c
from our Makefile, and while it is nicer to have an entry to
remove leftover perl/Git.c in our Makefile, it does not really
help in all cases.  We discussed this exact issue a few days
ago:

http://thread.gmane.org/gmane.comp.version-control.git/27730/focus=27853

Re: What will happen to git.git in the near future

[Johannes Schindelin]

Hi,

On Sun, 1 Oct 2006, Linus Torvalds wrote:

> 	Git.xs: In function 'XS_Git_xs_version':
> 	Git.xs:62: error: 'GIT_VERSION' undeclared (first use in this function)
> 	Git.xs:62: error: (Each undeclared identifier is reported only once
> 	Git.xs:62: error: for each function it appears in.)

We had that discussion in another thread already.

Just rm perl/{Git.{bs,c},Makefile} and remake.

Ciao,
Dscho

Re: What will happen to git.git in the near future

[Linus Torvalds]

On Sun, 1 Oct 2006, Junio C Hamano wrote:
> 
> Everybody hated the perl crud, so we removed Git.xs and is not
> even part of the source anymore.
> 
> This is a symptom that Git.c leftover from an earlier build was
> in the working tree.  Could you try running "rm -f perl/Git.c"
> before building and see if it helps?

Nope.

Then I just get

	make[1]: Entering directory `/home/torvalds/git/perl'
	Running Mkbootstrap for Git ()
	chmod 644 Git.bs
	rm -f blib/arch/auto/Git/Git.so
	gcc  -shared -L/usr/local/lib Git.o  -o blib/arch/auto/Git/Git.so       \
	        \
	  
	gcc: Git.o: No such file or directory
	gcc: no input files

instead.

If that file isn't even supposed to _exist_, then why do we have build 
rules etc crap to do all this? It sounds like the makefiles are broken.

		Linus

Re: What will happen to git.git in the near future

[Linus Torvalds]

On Sun, 1 Oct 2006, Johannes Schindelin wrote:
> 
> Just rm perl/{Git.{bs,c},Makefile} and remake.

Now this works.

So somebody tell me why we even invoke that Makefile that shouldn't be 
there?

		Linus

Re: What will happen to git.git in the near future

[Johannes Schindelin]

Hi,

On Sun, 1 Oct 2006, Linus Torvalds wrote:

> On Sun, 1 Oct 2006, Johannes Schindelin wrote:
> > 
> > Just rm perl/{Git.{bs,c},Makefile} and remake.
> 
> Now this works.
> 
> So somebody tell me why we even invoke that Makefile that shouldn't be 
> there?

The problem is that the Makefile does not realize that Git.xs no longer is 
there. Neither does the code which recreates the Makefile.

You will notice that there is a new generated perl/Makefile, which no 
longer tries to compile Git.xs, Git.bs or Git.c

When there is a Git.c, "perl Makefile.PL" will do the wrong thing, namely 
it expects that you created Git.c by hand, and wants to compile it. If 
there is a Git.bs, it thinks you want Git.c created.

Sort of automake for Perl.

Ciao,
Dscho

Re: What will happen to git.git in the near future

[Linus Torvalds]

On Sun, 1 Oct 2006, Johannes Schindelin wrote:
> 
> The problem is that the Makefile does not realize that Git.xs no longer is 
> there. Neither does the code which recreates the Makefile.

No. The problem is that top-level dependency rules for perl/Makefile are 
simply _wrong_. It claims it depends on some things (which is true), but 
then it totally ignores _other_ things that it also depends on.

Further, even if it was right, the rules to actually _generate_ the 
Makefile then seems wrong, in that it cares about files it shouldn't care 
about in the first place.

So why do that at all? Why accept such crap?

			Linus