What's in git.git

* The 'master' branch has these since the last announcement.
  There are some small bits I'd like to merge still brewing
in
  'next' before the -rc1, but please expect a real 1.4.3-rc1
  soon.

  - git-daemon virtual hosting.

  - With git-branch, deleting branch a/b and then creating
    branch a did not work.  Fixed.

  - Updated git-archive documentation.

  - git-repack can be run from project subdirectory.

  - git-log and friends can limit output with --author,
    --committer and --grep options.

  - Minor git-runstatus by Johannes Schindelin.

  - git-diff --color highlights whitespace errors.

  - git-apply --whitespace={warn,error,strip} notices
whitespace
    errors in indentation.

  - git-tar is now a thin wrapper to "git-archive
--format=tar";
    "git-tar --remote" talks with
"git-upload-archive" on the
    other end.

  - Python-based merge-recursive is deprecated.  It is still
    available as "recursive-old" strategy, but
"recursive"
    strategy now uses the C implementation.  The earlier
synonym
    "recur" still available.

  - "git-grep --fixed-strings" with boolean
expression did not
    work; fixed.

  - git-pack-objects generates packfile version 3 that can
    express copying of larger block from delta base.

  - Many internal routines that deal with using packfiles
have
    been cleaned up.

  - Many updates to gitweb by the usual suspects.

  - Default repository to fetch from, and the remote
branches to
    merge, can be specified by per-branch configuration
items.

  - git-svnimport gets the full author name from
Signed-off-by:
    line when available.

  - git-svn got a few updates.

  - git-checkout while not on a branch (e.g. git-init-db
    followed by git-fetch to create branches from remotes)
did
    not work; fixed.

  - Even when core.filemode is set to false (i.e. the
filesystem
    does not have reliable mode bits), git-update-index
still
    registered new paths with random mode bits obtained from
the
    filesystem.  Fixed.


* The 'next' branch, in addition, has these.  I think the
ones
  marked with + could be 1.4.3-rc1 material:

  - Triggered by the packed-ref series from Linus, we have
    accumulated a few topics, but I decided to consolidate
them
    into one topic branch.  It contains:

    - resolve_ref() API cleanup;

    - for_each_ref() API cleanup;

    - git-show-ref helper;

    - git-for-each-ref helper;

    - ref locking fix-up to tighten races for ref creation
and
      deletion cases;

    - packed refs and pruning of refs;

    - git-receive-pack now uses lock_ref_sha1() API and
updates
      ref-log like other programs;

    The series still has a few problems I listed in my
earlier
    message:

	Subject: What will happen to git.git in the near future
	Message-ID: <7v7iztbldm.fsfassigned-by-dhcp.cox.net>

    I do not plan to include this in the next release;
hopefully
    soon after the next release we can have it in 'master'. 


  - cvsimport was updated to use for-each ref.  This
obviously
    depends on the above.

  + Git.pm lost Git.xs; its remnant still remains, though.
    Notably, we still compile x86_64 with -fPIC, and the top
    level Makefile has {BASIC,ALL}_{CFLAGS,LDFLAGS}
distinction
    and INSTALL talks about perl/blib/arch/auto.  I am torn
    between removing these and keeping them; on one hand,
they
    are not needed and makes new developers wonder what the
    distinction between BASIC and ALL are.  On the other
hand,
    we may eventually would want to reintroduce Git.xs in
the
    future and keeping them might help us.  But on the third
    hand , we can
always resurrect it from the repository and
    that is the point of using git to keep track of the
project,
    so removing them might not be such a big deal.  I'd like
to
    decide between this two and push it out to 'master'
before
    doing the -rc1.

  + More gitweb updates from usual suspects.

  + "git-diff --stat" can now be told to use
custom output width
    with --stat-width=N option instead of the default 80.

  + "git-diff --stat --color" shows the graph in
colors.

  - "git-grep --all-match" limits output to files
that have all
    the top-level ORed expressions.  I suck at documentation
and
    the description I added to the manual needs rewriting.
    Help?

  - git-log and friends learned the same --all-match flag. 
With
    it:

    	git log --all-match --author=Linus --committer=Junio
--grep=list

    would show only changes written by Linus and committed
by me
    and talks about "list".

  - updates to packfile format that allows delta base
objects to
    be expressed by offset in the stream, not by 20-byte
object
    name.  Just completed and started cooking in 'next'.

  - upload-pack: stop the other side when they have more
roots than we do.


* The 'pu' branch, in addition, has these.

  - change "git-diff" output for paths with
embedded SP a bit
    friendlier to "GNU patch".  This is done by
appending an
    extra TAB after "--- a/file name" and
"+++ b/file name"
    lines.  This needs to be done in two steps:

    - prepare git-apply to take the new output format.

    - update git-diff to produce such, after people's
git-apply
      has been updated.

    Do people have objection to the output format change?
    Otherwise I'd like to merge the first stage to 'next',
and
    perhaps soon after 1.4.3 to 'master'.

  - two git-cvsexportcommit improvements, which
unfortunately
    fails with certain combination of patch/perl/cvs;
breakage
    under investigation by the author.

-
To unsubscribe from this list: send the line
"unsubscribe git" in
the body of a message to majordomovger.kernel.org
More majordomo info at  http://vge
r.kernel.org/majordomo-info.html

Dear diary, on Thu, Sep 28, 2006 at 09:39:11AM CEST, I got a
letter
where Junio C Hamano <junkiocox.net> said that...
>   -

BTW, what's the difference between '-' and '+'?

>   + Git.pm lost Git.xs; its remnant still remains,
though.
>     Notably, we still compile x86_64 with -fPIC, and
the top
>     level Makefile has {BASIC,ALL}_{CFLAGS,LDFLAGS}
distinction
>     and INSTALL talks about perl/blib/arch/auto.  I am
torn
>     between removing these and keeping them; on one
hand, they
>     are not needed and makes new developers wonder what
the
>     distinction between BASIC and ALL are.  On the
other hand,
>     we may eventually would want to reintroduce Git.xs
in the
>     future and keeping them might help us.  But on the
third
>     hand , we can
always resurrect it from the repository and
>     that is the point of using git to keep track of the
project,
>     so removing them might not be such a big deal.  I'd
like to
>     decide between this two and push it out to 'master'
before
>     doing the -rc1.

FWIW, I'd say kill it all (perhaps except BASIC_*, I don't
know about
that one) - we indeed can easily resurrect this, and that
was the
presumption with which I've killed the rest of Git.xs.
There's no point
in keeping legacy cruft around when we can take it back from
the
history.

Perhaps we could throw a note to perl/Makefile saying

	# If you are thinking about adding Git.xs support, please
note
	# that we have already been there before - see the #next
branch
	# history for more-or-less working one already added, and
also
	# the reason why it was removed for now.

so that noone wastes their time.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl
-sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo
16dioU$k"SK$/SM$nEsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/W//g;$_=pack('H*',/((..)*)$/)
-
To unsubscribe from this list: send the line
"unsubscribe git" in
the body of a message to majordomovger.kernel.org
More majordomo info at  http://vge
r.kernel.org/majordomo-info.html

Hi,

On Thu, 28 Sep 2006, Petr Baudis wrote:

> Dear diary, on Thu, Sep 28, 2006 at 09:39:11AM CEST, I
got a letter
> where Junio C Hamano <junkiocox.net> said that...
> 
> >   + Git.pm lost Git.xs; its remnant still remains,
though.
> >     Notably, we still compile x86_64 with -fPIC,
and the top
> >     level Makefile has
{BASIC,ALL}_{CFLAGS,LDFLAGS} distinction
> >     and INSTALL talks about perl/blib/arch/auto. 
I am torn
> >     between removing these and keeping them; on
one hand, they
> >     are not needed and makes new developers wonder
what the
> >     distinction between BASIC and ALL are.  On the
other hand,
> >     we may eventually would want to reintroduce
Git.xs in the
> >     future and keeping them might help us.  But on
the third
> >     hand , we can
always resurrect it from the repository and
> >     that is the point of using git to keep track
of the project,
> >     so removing them might not be such a big deal.
 I'd like to
> >     decide between this two and push it out to
'master' before
> >     doing the -rc1.
> 
> FWIW, I'd say kill it all (perhaps except BASIC_*, I
don't know about
> that one) - we indeed can easily resurrect this, and
that was the
> presumption with which I've killed the rest of Git.xs.
There's no point
> in keeping legacy cruft around when we can take it back
from the
> history.
> 
> Perhaps we could throw a note to perl/Makefile saying
> 
> 	# If you are thinking about adding Git.xs support,
please note
> 	# that we have already been there before - see the
#next branch
> 	# history for more-or-less working one already added,
and also
> 	# the reason why it was removed for now.
> 
> so that noone wastes their time.

Having ranted so often about Git.xs, I feel like I have to
apologize. It 
would be a better idea (IMHO) to put an effort into having
the _option_ to 
use Git.xs, since it is so much more efficient. If it is a
strict opt-in, 
I think it could remain in "next", and it would be
much more likely that 
people took up the ball and worked towards libifying git.

Ciao,
Dscho

-
To unsubscribe from this list: send the line
"unsubscribe git" in
the body of a message to majordomovger.kernel.org
More majordomo info at  http://vge
r.kernel.org/majordomo-info.html

Petr Baudis <paskysuse.cz> writes:

> FWIW, I'd say kill it all (perhaps except BASIC_*, I
don't know about
> that one) - we indeed can easily resurrect this, and
that was the
> presumption with which I've killed the rest of Git.xs.
There's no point
> in keeping legacy cruft around when we can take it back
from the
> history.

I came up with this to apply on top of "next". 
Extra sets of
eyeballs very much appreciated.

-- >8 --
Remove -fPIC which was only needed for Git.xs

The distinction between BASIC_ vs ALL_ is still kept, since
it
is not Git.xs specific -- we could face the same issue when
we
do other language bindings (e.g. Python). 

Signed-off-by: Junio C Hamano <junkiocox.net>
---

 INSTALL       |   13 -------------
 Makefile      |   13 -------------
 config.mak.in |    1 -
 configure.ac  |    7 -------
 4 files changed, 0 insertions(+), 34 deletions(-)

diff --git a/INSTALL b/INSTALL
index 0d432d7..fa9bf74 100644
--- a/INSTALL
+++ b/INSTALL
 -38,19
+38,6  Issues of note:
    has been actively developed since 1997, and people have
moved over to
    graphical file managers.
 
- - You can use git after building but without installing if
you
-   wanted to.  Various git commands need to find other git
-   commands and scripts to do their work, so you would need
to
-   arrange a few environment variables to tell them that
their
-   friends will be found in your built source area instead
of at
-   their standard installation area.  Something like this
works
-   for me:
-
-	GIT_EXEC_PATH=`pwd`
-	PATH=`pwd`:$PATH
-	GITPERLLIB=`pwd`/perl/blib/lib:`pwd`/perl/blib/arch/auto/G
it
-	export GIT_EXEC_PATH PATH GITPERLLIB
-
  - Git is reasonably self-sufficient, but does depend on a
few external
    programs and libraries:
 
diff --git a/Makefile b/Makefile
index 8a7f29b..1875965 100644
--- a/Makefile
+++ b/Makefile
 -60,9
+60,6  # a bundled SHA1 routine coming from Moz
 # on non-x86 architectures (e.g. PowerPC), while the
OpenSSL version (default
 # choice) has very fast version optimized for i586.
 #
-# Define USE_PIC if you need the main git objects to be
built with -fPIC
-# in order to build and link perl/Git.so.  x86-64 seems to
need this.
-#
 # Define NEEDS_SSL_WITH_CRYPTO if you need -lcrypto with
-lssl (Darwin).
 #
 # Define NEEDS_LIBICONV if linking with libc is not enough
(Darwin).
 -112,7
+109,6  uname_P := $(shell sh -c 'uname -p 2>/de
 # CFLAGS and LDFLAGS are for the users to override from the
command line.
 
 CFLAGS = -g -O2 -Wall
-PIC_FLAG = -fPIC
 LDFLAGS =
 ALL_CFLAGS = $(CFLAGS)
 ALL_LDFLAGS = $(LDFLAGS)
 -402,12
+398,6  endif
 ifneq (,$(findstring arm,$(uname_M)))
 	ARM_SHA1 = YesPlease
 endif
-ifeq ($(uname_M),sun4u)
-	USE_PIC = YesPlease
-endif
-ifeq ($(uname_M),x86_64)
-	USE_PIC = YesPlease
-endif
 
 -include config.mak.autogen
 -include config.mak
 -546,9
+536,6  else
 endif
 endif
 endif
-ifdef USE_PIC
-	ALL_CFLAGS += $(PIC_FLAG)
-endif
 ifdef NO_ACCURATE_DIFF
 	BASIC_CFLAGS += -DNO_ACCURATE_DIFF
 endif
diff --git a/config.mak.in b/config.mak.in
index addda4f..fecae80 100644
--- a/config.mak.in
+++ b/config.mak.in
 -3,7
+3,6  # configure_input
 
 CC = CC
 CFLAGS = CFLAGS
-PIC_FLAG = PIC_FLAG
 AR = AR
 TAR = TAR
 #INSTALL = INSTALL		# needs install-sh or install.sh in
sources
diff --git a/configure.ac b/configure.ac
index 0f93f6f..8192826 100644
--- a/configure.ac
+++ b/configure.ac
 -96,13
+96,6  ## Checks for programs.
 AC_MSG_NOTICE([CHECKS for programs])
 #
 AC_PROG_CC([cc gcc])
-if test -n "$GCC"; then
-	PIC_FLAG="-fPIC"
-else
-	AC_CHECK_DECL(__SUNPRO_C, [CFLAGS="$CFLAGS
-xO3"; PIC_FLAG="-KPIC"])
-fi
-AC_SUBST(PIC_FLAG)
-
 #AC_PROG_INSTALL		# needs install-sh or install.sh in
sources
 AC_CHECK_TOOL(AR, ar, 
 AC_CHECK_PROGS(TAR, [gtar tar])

-
To unsubscribe from this list: send the line
"unsubscribe git" in
the body of a message to majordomovger.kernel.org
More majordomo info at  http://vge
r.kernel.org/majordomo-info.html

Petr Baudis <paskysuse.cz> writes:

> Dear diary, on Thu, Sep 28, 2006 at 09:39:11AM CEST, I
got a letter
> where Junio C Hamano <junkiocox.net> said that...
>>   -
>
> BTW, what's the difference between '-' and '+'?

quoting myself...

|| * The 'next' branch, in addition, has these.  I think the
ones
||   marked with + could be 1.4.3-rc1 material:

-
To unsubscribe from this list: send the line
"unsubscribe git" in
the body of a message to majordomovger.kernel.org
More majordomo info at  http://vge
r.kernel.org/majordomo-info.html

Dear diary, on Fri, Sep 29, 2006 at 09:34:51AM CEST, I got a
letter
where Junio C Hamano <junkiocox.net> said that...
> diff --git a/INSTALL b/INSTALL
> index 0d432d7..fa9bf74 100644
> --- a/INSTALL
> +++ b/INSTALL
>  -38,19 +38,6  Issues of note:
>     has been actively developed since 1997, and people
have moved over to
>     graphical file managers.
>  
> - - You can use git after building but without
installing if you
> -   wanted to.  Various git commands need to find other
git
> -   commands and scripts to do their work, so you would
need to
> -   arrange a few environment variables to tell them
that their
> -   friends will be found in your built source area
instead of at
> -   their standard installation area.  Something like
this works
> -   for me:
> -
> -	GIT_EXEC_PATH=`pwd`
> -	PATH=`pwd`:$PATH
>
-	GITPERLLIB=`pwd`/perl/blib/lib:`pwd`/perl/blib/arch/auto/G
it
> -	export GIT_EXEC_PATH PATH GITPERLLIB
> -
>   - Git is reasonably self-sufficient, but does depend
on a few external
>     programs and libraries:
>  

The passage should be kept and even GITPERLLIB - just drop
the second
path after the colon.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl
-sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo
16dioU$k"SK$/SM$nEsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/W//g;$_=pack('H*',/((..)*)$/)
-
To unsubscribe from this list: send the line
"unsubscribe git" in
the body of a message to majordomovger.kernel.org
More majordomo info at  http://vge
r.kernel.org/majordomo-info.html

Petr Baudis <paskysuse.cz> writes:

>> - - You can use git after building but without
installing if you
>>...
>> -	export GIT_EXEC_PATH PATH GITPERLLIB
>> -
>>   - Git is reasonably self-sufficient, but does
depend on a few external
>>     programs and libraries:
>
> The passage should be kept and even GITPERLLIB - just
drop the second
> path after the colon.

Thanks.

-
To unsubscribe from this list: send the line
"unsubscribe git" in
the body of a message to majordomovger.kernel.org
More majordomo info at  http://vge
r.kernel.org/majordomo-info.html