{"thread":{"id":"5734","subject":"What's in git.git","startedAt":"2006-09-28T07:39:11Z","lastAt":"2006-09-30T07:31:18Z","messageCount":7,"participants":["Junio C Hamano","Petr Baudis","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"27878","messageId":"7vodt0zbhc.fsf@assigned-by-dhcp.cox.net","threadId":"5734","inReplyTo":null,"subject":"What's in git.git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-09-28T07:39:11Z","receivedAt":"2006-09-28T07:39:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"* The 'master' branch has these since the last announcement.\n There are some small bits I'd like to merge still brewing in\n 'next' before the -rc1, but please expect a real 1.4.3-rc1\n soon.\n\n - git-daemon virtual hosting.\n\n - With git-branch, deleting branch a/b and then creating\n branch a did not work. Fixed.\n\n - Updated git-archive documentation.\n\n - git-repack can be run from project subdirectory.\n\n - git-log and friends can limit output with --author,\n --committer and --grep options.\n\n - Minor git-runstatus by Johannes Schindelin.\n\n - git-diff --color highlights whitespace errors.\n\n - git-apply --whitespace={warn,error,strip} notices whitespace\n errors in indentation.\n\n - git-tar is now a thin wrapper to \"git-archive --format=tar\";\n \"git-tar --remote\" talks with \"git-upload-archive\" on the\n other end.\n\n - Python-based merge-recursive is deprecated. It is still\n available as \"recursive-old\" strategy, but \"recursive\"\n strategy now uses the C implementation. The earlier synonym\n \"recur\" still available.\n\n - \"git-grep --fixed-strings\" with boolean expression did not\n work; fixed.\n\n - git-pack-objects generates packfile version 3 that can\n express copying of larger block from delta base.\n\n - Many internal routines that deal with using packfiles have\n been cleaned up.\n\n - Many updates to gitweb by the usual suspects.\n\n - Default repository to fetch from, and the remote branches to\n merge, can be specified by per-branch configuration items.\n\n - git-svnimport gets the full author name from Signed-off-by:\n line when available.\n\n - git-svn got a few updates.\n\n - git-checkout while not on a branch (e.g. git-init-db\n followed by git-fetch to create branches from remotes) did\n not work; fixed.\n\n - Even when core.filemode is set to false (i.e. the filesystem\n does not have reliable mode bits), git-update-index still\n registered new paths with random mode bits obtained from the\n filesystem. Fixed.\n\n\n* The 'next' branch, in addition, has these. I think the ones\n marked with + could be 1.4.3-rc1 material:\n\n - Triggered by the packed-ref series from Linus, we have\n accumulated a few topics, but I decided to consolidate them\n into one topic branch. It contains:\n\n - resolve_ref() API cleanup;\n\n - for_each_ref() API cleanup;\n\n - git-show-ref helper;\n\n - git-for-each-ref helper;\n\n - ref locking fix-up to tighten races for ref creation and\n deletion cases;\n\n - packed refs and pruning of refs;\n\n - git-receive-pack now uses lock_ref_sha1() API and updates\n ref-log like other programs;\n\n The series still has a few problems I listed in my earlier\n message:\n\n\tSubject: What will happen to git.git in the near future\n\tMessage-ID: <7v7iztbldm.fsf@assigned-by-dhcp.cox.net>\n\n I do not plan to include this in the next release; hopefully\n soon after the next release we can have it in 'master'. \n\n - cvsimport was updated to use for-each ref. This obviously\n depends on the above.\n\n + Git.pm lost Git.xs; its remnant still remains, though.\n Notably, we still compile x86_64 with -fPIC, and the top\n level Makefile has {BASIC,ALL}_{CFLAGS,LDFLAGS} distinction\n and INSTALL talks about perl/blib/arch/auto. I am torn\n between removing these and keeping them; on one hand, they\n are not needed and makes new developers wonder what the\n distinction between BASIC and ALL are. On the other hand,\n we may eventually would want to reintroduce Git.xs in the\n future and keeping them might help us. But on the third\n hand ;-), we can always resurrect it from the repository and\n that is the point of using git to keep track of the project,\n so removing them might not be such a big deal. I'd like to\n decide between this two and push it out to 'master' before\n doing the -rc1.\n\n + More gitweb updates from usual suspects.\n\n + \"git-diff --stat\" can now be told to use custom output width\n with --stat-width=N option instead of the default 80.\n\n + \"git-diff --stat --color\" shows the graph in colors.\n\n - \"git-grep --all-match\" limits output to files that have all\n the top-level ORed expressions. I suck at documentation and\n the description I added to the manual needs rewriting.\n Help?\n\n - git-log and friends learned the same --all-match flag. With\n it:\n\n \tgit log --all-match --author=Linus --committer=Junio --grep=list\n\n would show only changes written by Linus and committed by me\n and talks about \"list\".\n\n - updates to packfile format that allows delta base objects to\n be expressed by offset in the stream, not by 20-byte object\n name. Just completed and started cooking in 'next'.\n\n - upload-pack: stop the other side when they have more roots than we do.\n\n\n* The 'pu' branch, in addition, has these.\n\n - change \"git-diff\" output for paths with embedded SP a bit\n friendlier to \"GNU patch\". This is done by appending an\n extra TAB after \"--- a/file name\" and \"+++ b/file name\"\n lines. This needs to be done in two steps:\n\n - prepare git-apply to take the new output format.\n\n - update git-diff to produce such, after people's git-apply\n has been updated.\n\n Do people have objection to the output format change?\n Otherwise I'd like to merge the first stage to 'next', and\n perhaps soon after 1.4.3 to 'master'.\n\n - two git-cvsexportcommit improvements, which unfortunately\n fails with certain combination of patch/perl/cvs; breakage\n under investigation by the author.\n"},{"id":"27881","messageId":"20060928093623.GJ20017@pasky.or.cz","threadId":"5734","inReplyTo":"7vodt0zbhc.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-09-28T09:36:23Z","receivedAt":"2006-09-28T09:36:23Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Thu, Sep 28, 2006 at 09:39:11AM CEST, I got a letter\nwhere Junio C Hamano said that...\n> -\n\nBTW, what's the difference between '-' and '+'?\n\n> + Git.pm lost Git.xs; its remnant still remains, though.\n> Notably, we still compile x86_64 with -fPIC, and the top\n> level Makefile has {BASIC,ALL}_{CFLAGS,LDFLAGS} distinction\n> and INSTALL talks about perl/blib/arch/auto. I am torn\n> between removing these and keeping them; on one hand, they\n> are not needed and makes new developers wonder what the\n> distinction between BASIC and ALL are. On the other hand,\n> we may eventually would want to reintroduce Git.xs in the\n> future and keeping them might help us. But on the third\n> hand ;-), we can always resurrect it from the repository and\n> that is the point of using git to keep track of the project,\n> so removing them might not be such a big deal. I'd like to\n> decide between this two and push it out to 'master' before\n> doing the -rc1.\n\nFWIW, I'd say kill it all (perhaps except BASIC_*, I don't know about\nthat one) - we indeed can easily resurrect this, and that was the\npresumption with which I've killed the rest of Git.xs. There's no point\nin keeping legacy cruft around when we can take it back from the\nhistory.\n\nPerhaps we could throw a note to perl/Makefile saying\n\n\t# If you are thinking about adding Git.xs support, please note\n\t# that we have already been there before - see the #next branch\n\t# history for more-or-less working one already added, and also\n\t# the reason why it was removed for now.\n\nso that noone wastes their time.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i Dear diary, on Thu, Sep 28, 2006 at 09:39:11AM CEST, I got a letter\n> where Junio C Hamano said that...\n> \n> > + Git.pm lost Git.xs; its remnant still remains, though.\n> > Notably, we still compile x86_64 with -fPIC, and the top\n> > level Makefile has {BASIC,ALL}_{CFLAGS,LDFLAGS} distinction\n> > and INSTALL talks about perl/blib/arch/auto. I am torn\n> > between removing these and keeping them; on one hand, they\n> > are not needed and makes new developers wonder what the\n> > distinction between BASIC and ALL are. On the other hand,\n> > we may eventually would want to reintroduce Git.xs in the\n> > future and keeping them might help us. But on the third\n> > hand ;-), we can always resurrect it from the repository and\n> > that is the point of using git to keep track of the project,\n> > so removing them might not be such a big deal. I'd like to\n> > decide between this two and push it out to 'master' before\n> > doing the -rc1.\n> \n> FWIW, I'd say kill it all (perhaps except BASIC_*, I don't know about\n> that one) - we indeed can easily resurrect this, and that was the\n> presumption with which I've killed the rest of Git.xs. There's no point\n> in keeping legacy cruft around when we can take it back from the\n> history.\n> \n> Perhaps we could throw a note to perl/Makefile saying\n> \n> \t# If you are thinking about adding Git.xs support, please note\n> \t# that we have already been there before - see the #next branch\n> \t# history for more-or-less working one already added, and also\n> \t# the reason why it was removed for now.\n> \n> so that noone wastes their time.\n\nHaving ranted so often about Git.xs, I feel like I have to apologize. It \nwould be a better idea (IMHO) to put an effort into having the _option_ to \nuse Git.xs, since it is so much more efficient. If it is a strict opt-in, \nI think it could remain in \"next\", and it would be much more likely that \npeople took up the ball and worked towards libifying git.\n\nCiao,\nDscho\n"},{"id":"27984","messageId":"7vhcyrnn1g.fsf@assigned-by-dhcp.cox.net","threadId":"5734","inReplyTo":"20060928093623.GJ20017@pasky.or.cz","subject":"Re: What's in git.git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-09-29T07:34:51Z","receivedAt":"2006-09-29T07:34:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis writes:\n\n> FWIW, I'd say kill it all (perhaps except BASIC_*, I don't know about\n> that one) - we indeed can easily resurrect this, and that was the\n> presumption with which I've killed the rest of Git.xs. There's no point\n> in keeping legacy cruft around when we can take it back from the\n> history.\n\nI came up with this to apply on top of \"next\". Extra sets of\neyeballs very much appreciated.\n\n-- >8 --\nRemove -fPIC which was only needed for Git.xs\n\nThe distinction between BASIC_ vs ALL_ is still kept, since it\nis not Git.xs specific -- we could face the same issue when we\ndo other language bindings (e.g. Python). \n\nSigned-off-by: Junio C Hamano \n---\n\n INSTALL | 13 -------------\n Makefile | 13 -------------\n config.mak.in | 1 -\n configure.ac | 7 -------\n 4 files changed, 0 insertions(+), 34 deletions(-)\n\ndiff --git a/INSTALL b/INSTALL\nindex 0d432d7..fa9bf74 100644\n--- a/INSTALL\n+++ b/INSTALL\n@@ -38,19 +38,6 @@ Issues of note:\n has been actively developed since 1997, and people have moved over to\n graphical file managers.\n \n- - You can use git after building but without installing if you\n- wanted to. Various git commands need to find other git\n- commands and scripts to do their work, so you would need to\n- arrange a few environment variables to tell them that their\n- friends will be found in your built source area instead of at\n- their standard installation area. Something like this works\n- for me:\n-\n-\tGIT_EXEC_PATH=`pwd`\n-\tPATH=`pwd`:$PATH\n-\tGITPERLLIB=`pwd`/perl/blib/lib:`pwd`/perl/blib/arch/auto/Git\n-\texport GIT_EXEC_PATH PATH GITPERLLIB\n-\n - Git is reasonably self-sufficient, but does depend on a few external\n programs and libraries:\n \ndiff --git a/Makefile b/Makefile\nindex 8a7f29b..1875965 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -60,9 +60,6 @@ # a bundled SHA1 routine coming from Moz\n # on non-x86 architectures (e.g. PowerPC), while the OpenSSL version (default\n # choice) has very fast version optimized for i586.\n #\n-# Define USE_PIC if you need the main git objects to be built with -fPIC\n-# in order to build and link perl/Git.so. x86-64 seems to need this.\n-#\n # Define NEEDS_SSL_WITH_CRYPTO if you need -lcrypto with -lssl (Darwin).\n #\n # Define NEEDS_LIBICONV if linking with libc is not enough (Darwin).\n@@ -112,7 +109,6 @@ uname_P := $(shell sh -c 'uname -p 2>/de\n # CFLAGS and LDFLAGS are for the users to override from the command line.\n \n CFLAGS = -g -O2 -Wall\n-PIC_FLAG = -fPIC\n LDFLAGS =\n ALL_CFLAGS = $(CFLAGS)\n ALL_LDFLAGS = $(LDFLAGS)\n@@ -402,12 +398,6 @@ endif\n ifneq (,$(findstring arm,$(uname_M)))\n \tARM_SHA1 = YesPlease\n endif\n-ifeq ($(uname_M),sun4u)\n-\tUSE_PIC = YesPlease\n-endif\n-ifeq ($(uname_M),x86_64)\n-\tUSE_PIC = YesPlease\n-endif\n \n -include config.mak.autogen\n -include config.mak\n@@ -546,9 +536,6 @@ else\n endif\n endif\n endif\n-ifdef USE_PIC\n-\tALL_CFLAGS += $(PIC_FLAG)\n-endif\n ifdef NO_ACCURATE_DIFF\n \tBASIC_CFLAGS += -DNO_ACCURATE_DIFF\n endif\ndiff --git a/config.mak.in b/config.mak.in\nindex addda4f..fecae80 100644\n--- a/config.mak.in\n+++ b/config.mak.in\n@@ -3,7 +3,6 @@ # @configure_input@\n \n CC = @CC@\n CFLAGS = @CFLAGS@\n-PIC_FLAG = @PIC_FLAG@\n AR = @AR@\n TAR = @TAR@\n #INSTALL = @INSTALL@\t\t# needs install-sh or install.sh in sources\ndiff --git a/configure.ac b/configure.ac\nindex 0f93f6f..8192826 100644\n--- a/configure.ac\n+++ b/configure.ac\n@@ -96,13 +96,6 @@ ## Checks for programs.\n AC_MSG_NOTICE([CHECKS for programs])\n #\n AC_PROG_CC([cc gcc])\n-if test -n \"$GCC\"; then\n-\tPIC_FLAG=\"-fPIC\"\n-else\n-\tAC_CHECK_DECL(__SUNPRO_C, [CFLAGS=\"$CFLAGS -xO3\"; PIC_FLAG=\"-KPIC\"])\n-fi\n-AC_SUBST(PIC_FLAG)\n-\n #AC_PROG_INSTALL\t\t# needs install-sh or install.sh in sources\n AC_CHECK_TOOL(AR, ar, :)\n AC_CHECK_PROGS(TAR, [gtar tar])\n"},{"id":"27986","messageId":"7vd59fnlfh.fsf@assigned-by-dhcp.cox.net","threadId":"5734","inReplyTo":"20060928093623.GJ20017@pasky.or.cz","subject":"Re: What's in git.git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-09-29T08:09:38Z","receivedAt":"2006-09-29T08:09:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis writes:\n\n> Dear diary, on Thu, Sep 28, 2006 at 09:39:11AM CEST, I got a letter\n> where Junio C Hamano said that...\n>> -\n>\n> BTW, what's the difference between '-' and '+'?\n\nquoting myself...\n\n|| * The 'next' branch, in addition, has these. I think the ones\n|| marked with + could be 1.4.3-rc1 material:\n"},{"id":"27988","messageId":"20060929083208.GL13132@pasky.or.cz","threadId":"5734","inReplyTo":"7vhcyrnn1g.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-09-29T08:32:08Z","receivedAt":"2006-09-29T08:32:08Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Fri, Sep 29, 2006 at 09:34:51AM CEST, I got a letter\nwhere Junio C Hamano said that...\n> diff --git a/INSTALL b/INSTALL\n> index 0d432d7..fa9bf74 100644\n> --- a/INSTALL\n> +++ b/INSTALL\n> @@ -38,19 +38,6 @@ Issues of note:\n> has been actively developed since 1997, and people have moved over to\n> graphical file managers.\n> \n> - - You can use git after building but without installing if you\n> - wanted to. Various git commands need to find other git\n> - commands and scripts to do their work, so you would need to\n> - arrange a few environment variables to tell them that their\n> - friends will be found in your built source area instead of at\n> - their standard installation area. Something like this works\n> - for me:\n> -\n> -\tGIT_EXEC_PATH=`pwd`\n> -\tPATH=`pwd`:$PATH\n> -\tGITPERLLIB=`pwd`/perl/blib/lib:`pwd`/perl/blib/arch/auto/Git\n> -\texport GIT_EXEC_PATH PATH GITPERLLIB\n> -\n> - Git is reasonably self-sufficient, but does depend on a few external\n> programs and libraries:\n> \n\nThe passage should be kept and even GITPERLLIB - just drop the second\npath after the colon.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i writes:\n\n>> - - You can use git after building but without installing if you\n>>...\n>> -\texport GIT_EXEC_PATH PATH GITPERLLIB\n>> -\n>> - Git is reasonably self-sufficient, but does depend on a few external\n>> programs and libraries:\n>\n> The passage should be kept and even GITPERLLIB - just drop the second\n> path after the colon.\n\nThanks.\n"}]}