{"thread":{"id":"7105","subject":"[PATCH] Make 'make' quieter while building git","startedAt":"2007-03-06T06:35:01Z","lastAt":"2007-03-21T16:07:18Z","messageCount":25,"participants":["Shawn O. Pearce","Junio C Hamano","Alex Riesen","Johannes Schindelin","Bill Lear","Andy Parkins","Jakub Narebski"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"36420","messageId":"20070306063501.GA24355@spearce.org","threadId":"7105","inReplyTo":null,"subject":"[PATCH] Make 'make' quieter while building git","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-03-06T06:35:01Z","receivedAt":"2007-03-06T06:35:01Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"I find it difficult to see compiler warnings amongst the massive\nspewing produced by GNU make as it works through our productions.\nThis is especially true if CFLAGS winds up being rather long, due\nto a large number of -W options being enabled and due to a number\nof -D options being configured/required by my platform.\n\nBy defining QUIET_MAKE (e.g. make QUIET_MAKE=YesPlease) during\ncompilation users will get a less verbose output, such as:\n\n ...\n CC builtin-grep.c\nbuiltin-grep.c:187: warning: 'external_grep' defined but not used\n CC builtin-init-db.c\n CC builtin-log.c\n CC builtin-ls-files.c\n CC builtin-ls-tree.c\n ...\n\nThe verbose (normal make) output is still the default.\n\nSigned-off-by: Shawn O. Pearce \n---\n Makefile | 86 +++++++++++++++++++++++++++++----------------------\n perl/Makefile | 8 ++++-\n templates/Makefile | 10 ++++--\n 3 files changed, 62 insertions(+), 42 deletions(-)\n\ndiff --git a/Makefile b/Makefile\nindex a221bdc..66ab992 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -1,6 +1,8 @@\n # The default target of this Makefile is...\n all::\n \n+# Define QUIET_MAKE to have a less verbose compile.\n+#\n # Define NO_OPENSSL environment variable if you do not have OpenSSL.\n # This also implies MOZILLA_SHA1.\n #\n@@ -602,6 +604,19 @@ endif\n ifdef NO_PERL_MAKEMAKER\n \texport NO_PERL_MAKEMAKER\n endif\n+ifdef QUIET_MAKE\n+\tQUIET_CC = @echo ' ' CC $<;\n+\tQUIET_AR = @echo ' ' AR $@;\n+\tQUIET_LINK = @echo ' ' LINK $@;\n+\tQUIET_BUILT_IN = @echo ' ' BUILTIN $@;\n+\tQUIET_GEN = @echo ' ' GEN $@;\n+\tQUIET_SUBDIR0 = @subdir=\n+\tQUIET_SUBDIR1 = ;echo ' ' SUBDIR $$subdir; $(MAKE) -C$$subdir\n+\texport QUIET_MAKE\n+else\n+\tQUIET_SUBDIR0 = $(MAKE) -C\n+\tQUIET_SUBDIR1 =\n+endif\n \n # Shell quote (do not use $(call) to accommodate ancient setups);\n \n@@ -637,35 +652,34 @@ ifneq (,$X)\n endif\n \n all::\n-\t$(MAKE) -C git-gui all\n-\t$(MAKE) -C perl PERL_PATH='$(PERL_PATH_SQ)' prefix='$(prefix_SQ)' all\n-\t$(MAKE) -C templates\n+\t$(QUIET_SUBDIR0)git-gui $(QUIET_SUBDIR1) all\n+\t$(QUIET_SUBDIR0)perl $(QUIET_SUBDIR1) PERL_PATH='$(PERL_PATH_SQ)' prefix='$(prefix_SQ)' all\n+\t$(QUIET_SUBDIR0)templates $(QUIET_SUBDIR1)\n \n strip: $(PROGRAMS) git$X\n \t$(STRIP) $(STRIP_OPTS) $(PROGRAMS) git$X\n \n git$X: git.c common-cmds.h $(BUILTIN_OBJS) $(GITLIBS) GIT-CFLAGS\n-\t$(CC) -DGIT_VERSION='\"$(GIT_VERSION)\"' \\\n+\t$(QUIET_LINK)$(CC) -DGIT_VERSION='\"$(GIT_VERSION)\"' \\\n \t\t$(ALL_CFLAGS) -o $@ $(filter %.c,$^) \\\n \t\t$(BUILTIN_OBJS) $(ALL_LDFLAGS) $(LIBS)\n \n help.o: common-cmds.h\n \n $(BUILT_INS): git$X\n-\trm -f $@ && ln git$X $@\n+\t$(QUIET_BUILT_IN)rm -f $@ && ln git$X $@\n \n common-cmds.h: Documentation/git-*.txt\n-\t./generate-cmdlist.sh > $@+\n-\tmv $@+ $@\n+\t$(QUIET_GEN)./generate-cmdlist.sh > $@+ && mv $@+ $@\n \n $(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh\n-\trm -f $@ $@+\n+\t$(QUIET_GEN)rm -f $@ $@+ && \\\n \tsed -e '1s|#!.*/sh|#!$(SHELL_PATH_SQ)|' \\\n \t -e 's|@@PERL@@|$(PERL_PATH_SQ)|g' \\\n \t -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \\\n \t -e 's/@@NO_CURL@@/$(NO_CURL)/g' \\\n-\t $@.sh >$@+\n-\tchmod +x $@+\n+\t $@.sh >$@+ && \\\n+\tchmod +x $@+ && \\\n \tmv $@+ $@\n \n $(patsubst %.perl,%,$(SCRIPT_PERL)): perl/perl.mak\n@@ -674,7 +688,7 @@ perl/perl.mak: GIT-CFLAGS\n \t$(MAKE) -C perl PERL_PATH='$(PERL_PATH_SQ)' prefix='$(prefix_SQ)' $(@F)\n \n $(patsubst %.perl,%,$(SCRIPT_PERL)): % : %.perl\n-\trm -f $@ $@+\n+\t$(QUIET_GEN)rm -f $@ $@+ && \\\n \tINSTLIBDIR=`$(MAKE) -C perl -s --no-print-directory instlibdir` && \\\n \tsed -e '1{' \\\n \t -e '\ts|#!.*perl|#!$(PERL_PATH_SQ)|' \\\n@@ -685,20 +699,18 @@ $(patsubst %.perl,%,$(SCRIPT_PERL)): % : %.perl\n \t -e '}' \\\n \t -e 's|@@INSTLIBDIR@@|'\"$$INSTLIBDIR\"'|g' \\\n \t -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \\\n-\t $@.perl >$@+\n-\tchmod +x $@+\n+\t $@.perl >$@+ && \\\n+\tchmod +x $@+ && \\\n \tmv $@+ $@\n \n git-cherry-pick: git-revert\n-\tcp $< $@+\n-\tmv $@+ $@\n+\t$(QUIET_GEN)cp $< $@+ && mv $@+ $@\n \n git-status: git-commit\n-\tcp $< $@+\n-\tmv $@+ $@\n+\t$(QUIET_GEN)cp $< $@+ && mv $@+ $@\n \n gitweb/gitweb.cgi: gitweb/gitweb.perl\n-\trm -f $@ $@+\n+\t$(QUIET_GEN)rm -f $@ $@+ && \\\n \tsed -e '1s|#!.*perl|#!$(PERL_PATH_SQ)|' \\\n \t -e 's|++GIT_VERSION++|$(GIT_VERSION)|g' \\\n \t -e 's|++GIT_BINDIR++|$(bindir)|g' \\\n@@ -716,12 +728,12 @@ gitweb/gitweb.cgi: gitweb/gitweb.perl\n \t -e 's|++GITWEB_FAVICON++|$(GITWEB_FAVICON)|g' \\\n \t -e 's|++GITWEB_SITE_HEADER++|$(GITWEB_SITE_HEADER)|g' \\\n \t -e 's|++GITWEB_SITE_FOOTER++|$(GITWEB_SITE_FOOTER)|g' \\\n-\t $< >$@+\n-\tchmod +x $@+\n+\t $< >$@+ && \\\n+\tchmod +x $@+ && \\\n \tmv $@+ $@\n \n git-instaweb: git-instaweb.sh gitweb/gitweb.cgi gitweb/gitweb.css\n-\trm -f $@ $@+\n+\t$(QUIET_GEN)rm -f $@ $@+ && \\\n \tsed -e '1s|#!.*/sh|#!$(SHELL_PATH_SQ)|' \\\n \t -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \\\n \t -e 's/@@NO_CURL@@/$(NO_CURL)/g' \\\n@@ -729,15 +741,15 @@ git-instaweb: git-instaweb.sh gitweb/gitweb.cgi gitweb/gitweb.css\n \t -e '/@@GITWEB_CGI@@/d' \\\n \t -e '/@@GITWEB_CSS@@/r gitweb/gitweb.css' \\\n \t -e '/@@GITWEB_CSS@@/d' \\\n-\t $@.sh > $@+\n-\tchmod +x $@+\n+\t $@.sh > $@+ && \\\n+\tchmod +x $@+ && \\\n \tmv $@+ $@\n \n configure: configure.ac\n-\trm -f $@ $<+\n+\t$(QUIET_GEN)rm -f $@ $<+ && \\\n \tsed -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \\\n-\t $< > $<+\n-\tautoconf -o $@ $<+\n+\t $< > $<+ && \\\n+\tautoconf -o $@ $<+ && \\\n \trm -f $<+\n \n # These can record GIT_VERSION\n@@ -747,25 +759,25 @@ git$X git.spec \\\n \t: GIT-VERSION-FILE\n \n %.o: %.c GIT-CFLAGS\n-\t$(CC) -o $*.o -c $(ALL_CFLAGS) $<\n+\t$(QUIET_CC)$(CC) -o $*.o -c $(ALL_CFLAGS) $<\n %.o: %.S\n-\t$(CC) -o $*.o -c $(ALL_CFLAGS) $<\n+\t$(QUIET_CC)$(CC) -o $*.o -c $(ALL_CFLAGS) $<\n \n exec_cmd.o: exec_cmd.c GIT-CFLAGS\n-\t$(CC) -o $*.o -c $(ALL_CFLAGS) '-DGIT_EXEC_PATH=\"$(gitexecdir_SQ)\"' $<\n+\t$(QUIET_CC)$(CC) -o $*.o -c $(ALL_CFLAGS) '-DGIT_EXEC_PATH=\"$(gitexecdir_SQ)\"' $<\n builtin-init-db.o: builtin-init-db.c GIT-CFLAGS\n-\t$(CC) -o $*.o -c $(ALL_CFLAGS) -DDEFAULT_GIT_TEMPLATE_DIR='\"$(template_dir_SQ)\"' $<\n+\t$(QUIET_CC)$(CC) -o $*.o -c $(ALL_CFLAGS) -DDEFAULT_GIT_TEMPLATE_DIR='\"$(template_dir_SQ)\"' $<\n \n http.o: http.c GIT-CFLAGS\n-\t$(CC) -o $*.o -c $(ALL_CFLAGS) -DGIT_USER_AGENT='\"git/$(GIT_VERSION)\"' $<\n+\t$(QUIET_CC)$(CC) -o $*.o -c $(ALL_CFLAGS) -DGIT_USER_AGENT='\"git/$(GIT_VERSION)\"' $<\n \n ifdef NO_EXPAT\n http-fetch.o: http-fetch.c http.h GIT-CFLAGS\n-\t$(CC) -o $*.o -c $(ALL_CFLAGS) -DNO_EXPAT $<\n+\t$(QUIET_CC)$(CC) -o $*.o -c $(ALL_CFLAGS) -DNO_EXPAT $<\n endif\n \n git-%$X: %.o $(GITLIBS)\n-\t$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)\n+\t$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)\n \n ssh-pull.o: ssh-fetch.c\n ssh-push.o: ssh-upload.c\n@@ -779,11 +791,11 @@ git-imap-send$X: imap-send.o $(LIB_FILE)\n \n http.o http-fetch.o http-push.o: http.h\n git-http-fetch$X: fetch.o http.o http-fetch.o $(GITLIBS)\n-\t$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \\\n+\t$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \\\n \t\t$(LIBS) $(CURL_LIBCURL) $(EXPAT_LIBEXPAT)\n \n git-http-push$X: revision.o http.o http-push.o $(GITLIBS)\n-\t$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \\\n+\t$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \\\n \t\t$(LIBS) $(CURL_LIBCURL) $(EXPAT_LIBEXPAT)\n \n $(LIB_OBJS) $(BUILTIN_OBJS) fetch.o: $(LIB_H)\n@@ -791,7 +803,7 @@ $(patsubst git-%$X,%.o,$(PROGRAMS)): $(LIB_H) $(wildcard */*.h)\n $(DIFF_OBJS): diffcore.h\n \n $(LIB_FILE): $(LIB_OBJS)\n-\trm -f $@ && $(AR) rcs $@ $(LIB_OBJS)\n+\t$(QUIET_AR)rm -f $@ && $(AR) rcs $@ $(LIB_OBJS)\n \n XDIFF_OBJS=xdiff/xdiffi.o xdiff/xprepare.o xdiff/xutils.o xdiff/xemit.o \\\n \txdiff/xmerge.o\n@@ -799,7 +811,7 @@ $(XDIFF_OBJS): xdiff/xinclude.h xdiff/xmacros.h xdiff/xdiff.h xdiff/xtypes.h \\\n \txdiff/xutils.h xdiff/xprepare.h xdiff/xdiffi.h xdiff/xemit.h\n \n $(XDIFF_LIB): $(XDIFF_OBJS)\n-\trm -f $@ && $(AR) rcs $@ $(XDIFF_OBJS)\n+\t$(QUIET_AR)rm -f $@ && $(AR) rcs $@ $(XDIFF_OBJS)\n \n \n perl/Makefile: perl/Git.pm perl/Makefile.PL GIT-CFLAGS\ndiff --git a/perl/Makefile b/perl/Makefile\nindex 099beda..2fceff2 100644\n--- a/perl/Makefile\n+++ b/perl/Makefile\n@@ -6,11 +6,15 @@ makfile:=perl.mak\n PERL_PATH_SQ = $(subst ','\\'',$(PERL_PATH))\n prefix_SQ = $(subst ','\\'',$(prefix))\n \n+ifdef QUIET_MAKE\n+\tQUIET = @\n+endif\n+\n all install instlibdir: $(makfile)\n-\t$(MAKE) -f $(makfile) $@\n+\t$(QUIET)$(MAKE) -f $(makfile) $@\n \n clean:\n-\ttest -f $(makfile) && $(MAKE) -f $(makfile) $@ || exit 0\n+\t$(QUIET)test -f $(makfile) && $(MAKE) -f $(makfile) $@ || exit 0\n \t$(RM) ppport.h\n \t$(RM) $(makfile)\n \t$(RM) $(makfile).old\ndiff --git a/templates/Makefile b/templates/Makefile\nindex 0eeee43..81bd86c 100644\n--- a/templates/Makefile\n+++ b/templates/Makefile\n@@ -1,5 +1,9 @@\n # make and install sample templates\n \n+ifdef QUIET_MAKE\n+\tQUIET = @\n+endif\n+\n INSTALL ?= install\n TAR ?= tar\n prefix ?= $(HOME)\n@@ -18,7 +22,7 @@ all: boilerplates.made custom\n \n bpsrc = $(filter-out %~,$(wildcard *--*))\n boilerplates.made : $(bpsrc)\n-\tls *--* 2>/dev/null | \\\n+\t$(QUIET)ls *--* 2>/dev/null | \\\n \twhile read boilerplate; \\\n \tdo \\\n \t\tcase \"$$boilerplate\" in *~) continue ;; esac && \\\n@@ -29,13 +33,13 @@ boilerplates.made : $(bpsrc)\n \t\t*--) ;; \\\n \t\t*) cp $$boilerplate blt/$$dst ;; \\\n \t\tesac || exit; \\\n-\tdone || exit\n+\tdone && \\\n \tdate >$@\n \n # If you need build-tailored templates, build them into blt/\n # directory yourself here.\n custom:\n-\t: no custom templates yet\n+\t$(QUIET): no custom templates yet\n \n clean:\n \trm -rf blt boilerplates.made\n-- \n1.5.0.3.863.gf0989\n"},{"id":"36424","messageId":"7v1wk2ua55.fsf@assigned-by-dhcp.cox.net","threadId":"7105","inReplyTo":"20070306063501.GA24355@spearce.org","subject":"Re: [PATCH] Make 'make' quieter while building git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-03-06T07:03:02Z","receivedAt":"2007-03-06T07:03:02Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Shawn O. Pearce\" writes:\n\n> I find it difficult to see compiler warnings amongst the massive\n> spewing produced by GNU make as it works through our productions.\n\nI agree, and suspect it might even be a better idea to make this\nthe default, with \"make V=1\" to make chattier.\n\nNow we should do the same to git-gui, shouldn't we? Time for me\nto subtree-merge git-gui to my master?\n"},{"id":"36428","messageId":"20070306071630.GB24004@spearce.org","threadId":"7105","inReplyTo":"7v1wk2ua55.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Make 'make' quieter while building git","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-03-06T07:16:30Z","receivedAt":"2007-03-06T07:16:30Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> \"Shawn O. Pearce\" writes:\n> \n> > I find it difficult to see compiler warnings amongst the massive\n> > spewing produced by GNU make as it works through our productions.\n> \n> I agree, and suspect it might even be a better idea to make this\n> the default, with \"make V=1\" to make chattier.\n\nSee my other patch. ;-)\n \n> Now we should do the same to git-gui, shouldn't we? Time for me\n> to subtree-merge git-gui to my master?\n\nDone. gitgui-0.6.3 is tagged and ready to be pulled into maint.\nThere's a few small fixes in there that have been accumlating too.\nBe nice to get them into your next release, whatever that winds\nup being. ;-)\n\n-- \nShawn.\n"},{"id":"36437","messageId":"7v649ess7q.fsf@assigned-by-dhcp.cox.net","threadId":"7105","inReplyTo":"20070306071630.GB24004@spearce.org","subject":"Re: [PATCH] Make 'make' quieter while building git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-03-06T08:15:37Z","receivedAt":"2007-03-06T08:15:37Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Shawn O. Pearce\" writes:\n\n> Done. gitgui-0.6.3 is tagged and ready to be pulled into maint.\n> There's a few small fixes in there that have been accumlating too.\n\nJust to make sure this is not the rewrite and big clean-up you\nwere talking about but for maintenance?\n"},{"id":"36438","messageId":"20070306082108.GC24004@spearce.org","threadId":"7105","inReplyTo":"7v649ess7q.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Make 'make' quieter while building git","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-03-06T08:21:08Z","receivedAt":"2007-03-06T08:21:08Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> \"Shawn O. Pearce\" writes:\n> \n> > Done. gitgui-0.6.3 is tagged and ready to be pulled into maint.\n> > There's a few small fixes in there that have been accumlating too.\n> \n> Just to make sure this is not the rewrite and big clean-up you\n> were talking about but for maintenance?\n\nYes. I have not even started rewrite and big clean-up effort,\nlet alone pushed it to repo.or.cz. ;-)\n\n-- \nShawn.\n"},{"id":"36442","messageId":"81b0412b0703060116m166e2da7saeab82c67536558e@mail.gmail.com","threadId":"7105","inReplyTo":"20070306063501.GA24355@spearce.org","subject":"Re: [PATCH] Make 'make' quieter while building git","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-03-06T09:16:12Z","receivedAt":"2007-03-06T09:16:12Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 3/6/07, Shawn O. Pearce wrote:\n> ...\n> CC builtin-grep.c\n> builtin-grep.c:187: warning: 'external_grep' defined but not used\n\nCan I suggest printing the resulting object file instead of source?\nIt is useful if you want rebuild just one file by mouse-copy-paste it\ninto command line (the source file name for editor in case of\nerror is already in error message).\n"},{"id":"36450","messageId":"7vtzwyprr7.fsf_-_@assigned-by-dhcp.cox.net","threadId":"7105","inReplyTo":"20070306071630.GB24004@spearce.org","subject":"Short term release plans","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-03-06T10:53:48Z","receivedAt":"2007-03-06T10:53:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Shawn O. Pearce\" writes:\n\n> Be nice to get them into your next release, whatever that winds\n> up being. ;-)\n\nSurely git-gui 0.6.3 will be in 1.5.0.4, but I'd like to start\nplanning for 1.5.1 now.\n\nIn addition to what are described in the current 1.5.1 draft\nrelease notes, I'd like to have a few topics graduated to\n'master' and declare 1.5.1 by the end of the month.\n\nThat would mean we would have these biggies among other things\nin 1.5.1:\n\nAlready in 'master':\n\n - git-apply subdirectory behaviour fix\n - git-remote update\n - git-bundle\n - working on filesystems without symbolic links\n - automatic CRLF munging\n - git-rev-list --boundary --max-count (broken)\n - /etc/gitconfig\n\nCooking in 'next':\n\n - git-diff --no-index\n - built-in git-revert/git-cherry-pick\n - git-rev-list --boundary --max-count fix (this is sorely\n needed to make \"gitk -50 master\" to work)\n - handling corrupt loose objects in git-fsck and unpack_sha1_file\n - commit --interactive\n - format-patch --inline/--attach\n\nNot in 'next' yet, but would like to have in 1.5.1:\n\n - git-branch --track and git-checkout -B\n\nIn 'next' or 'pu' but needs more work, will not be in 1.5.1:\n\n - git-fetch half-C-rewrite.\n - .gitattributes (the code needs redesign --- handling multiple\n actions on a single path is nasty).\n - git-merge-subtree (subtree matching needs more work).\n"},{"id":"36462","messageId":"Pine.LNX.4.63.0703061422580.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"7105","inReplyTo":"81b0412b0703060116m166e2da7saeab82c67536558e@mail.gmail.com","subject":"Re: [PATCH] Make 'make' quieter while building git","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-03-06T13:24:22Z","receivedAt":"2007-03-06T13:24:22Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 6 Mar 2007, Alex Riesen wrote:\n\n> On 3/6/07, Shawn O. Pearce wrote:\n> > ...\n> > CC builtin-grep.c\n> > builtin-grep.c:187: warning: 'external_grep' defined but not used\n> \n> Can I suggest printing the resulting object file instead of source?\n> It is useful if you want rebuild just one file by mouse-copy-paste it\n> into command line (the source file name for editor in case of\n> error is already in error message).\n\nI don't understand. If you want to fix what was triggering the warning, \nyou have to edit the source, no? Besides, this warning is generated by the \ncompiler, so I doubt we can do anything about it.\n\nCiao,\nDscho\n"},{"id":"36463","messageId":"81b0412b0703060537u5140a034s91b35f0d842843a3@mail.gmail.com","threadId":"7105","inReplyTo":"Pine.LNX.4.63.0703061422580.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] Make 'make' quieter while building git","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-03-06T13:37:19Z","receivedAt":"2007-03-06T13:37:19Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 3/6/07, Johannes Schindelin wrote:\n> > > ...\n> > > CC builtin-grep.c\n> > > builtin-grep.c:187: warning: 'external_grep' defined but not used\n> >\n> > Can I suggest printing the resulting object file instead of source?\n> > It is useful if you want rebuild just one file by mouse-copy-paste it\n> > into command line (the source file name for editor in case of\n> > error is already in error message).\n>\n> I don't understand.\n\nRight. Because I was suggesting to output something like this:\n\n$ make\n...\n CC builtin-grep.o\nbuiltin-grep.c:187: warning: 'external_grep' defined but not used\n\nNotice \"builtin-grep.o\" (the \".o\", not _.c_). IOW, we already\nsee builtin-grep.c when we need it (in the error/warning message),\nBUT the builtin-grep.o is missing (and is useful for mouse-copy-paste).\n"},{"id":"36464","messageId":"Pine.LNX.4.63.0703061518250.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"7105","inReplyTo":"81b0412b0703060537u5140a034s91b35f0d842843a3@mail.gmail.com","subject":"Re: [PATCH] Make 'make' quieter while building git","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-03-06T14:19:00Z","receivedAt":"2007-03-06T14:19:00Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 6 Mar 2007, Alex Riesen wrote:\n\n> On 3/6/07, Johannes Schindelin wrote:\n> > > > ...\n> > > > CC builtin-grep.c\n> > > > builtin-grep.c:187: warning: 'external_grep' defined but not used\n> > >\n> > > Can I suggest printing the resulting object file instead of source?\n> > > It is useful if you want rebuild just one file by mouse-copy-paste it\n> > > into command line (the source file name for editor in case of\n> > > error is already in error message).\n> > \n> > I don't understand.\n> \n> Right. Because I was suggesting to output something like this:\n> \n> $ make\n> ...\n> CC builtin-grep.o\n> builtin-grep.c:187: warning: 'external_grep' defined but not used\n> \n> Notice \"builtin-grep.o\" (the \".o\", not _.c_). IOW, we already\n> see builtin-grep.c when we need it (in the error/warning message),\n> BUT the builtin-grep.o is missing (and is useful for mouse-copy-paste).\n\nAh! That explains it why I did not understand.\n\nCiao,\nDscho\n"},{"id":"36489","messageId":"7vejo2nffj.fsf@assigned-by-dhcp.cox.net","threadId":"7105","inReplyTo":"Pine.LNX.4.63.0703061518250.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] Make 'make' quieter while building git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-03-06T23:02:56Z","receivedAt":"2007-03-06T23:02:56Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> On Tue, 6 Mar 2007, Alex Riesen wrote:\n> ...\n>> ... I was suggesting to output something like this:\n>> \n>> $ make\n>> ...\n>> CC builtin-grep.o\n>> builtin-grep.c:187: warning: 'external_grep' defined but not used\n>> \n>> Notice \"builtin-grep.o\" (the \".o\", not _.c_). IOW, we already\n>> see builtin-grep.c when we need it (in the error/warning message),\n>> BUT the builtin-grep.o is missing (and is useful for mouse-copy-paste).\n>\n> Ah! That explains it why I did not understand.\n\nBut doesn't \"CC foo.o\" look just simply WRONG? We compile foo.c\nto produce foo.o. An alternative that I could slightly more\nsympathize with would be something like this:\n\n\tCC builtin-grep.c => builtin-grep.o\n"},{"id":"36491","messageId":"81b0412b0703061511j30683d14h584275b993d40e1c@mail.gmail.com","threadId":"7105","inReplyTo":"7vejo2nffj.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Make 'make' quieter while building git","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-03-06T23:11:30Z","receivedAt":"2007-03-06T23:11:30Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 3/7/07, Junio C Hamano wrote:\n> But doesn't \"CC foo.o\" look just simply WRONG? We compile foo.c\n> to produce foo.o. An alternative that I could slightly more\n> sympathize with would be something like this:\n\nnot if you compiled kernels. Doesn't it look wrong to\noutput information you already have, if you need to?\n"},{"id":"36497","messageId":"20070306232413.GA25785@spearce.org","threadId":"7105","inReplyTo":"81b0412b0703061511j30683d14h584275b993d40e1c@mail.gmail.com","subject":"Re: [PATCH] Make 'make' quieter while building git","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-03-06T23:24:13Z","receivedAt":"2007-03-06T23:24:13Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Alex Riesen wrote:\n> On 3/7/07, Junio C Hamano wrote:\n> >But doesn't \"CC foo.o\" look just simply WRONG? We compile foo.c\n> >to produce foo.o. An alternative that I could slightly more\n> >sympathize with would be something like this:\n> \n> not if you compiled kernels. Doesn't it look wrong to\n> output information you already have, if you need to?\n\nWell, I have to admit, the Linux kernel is where I got the idea from.\nBut I have not built one in a while so I didn't remember what it\noutputs, exactly.\n\nI also was too lazy to go look at the kernel makefiles, even though\nI have them handy.\n\n;-)\n\n-- \nShawn.\n"},{"id":"37484","messageId":"7v8xdth5c4.fsf_-_@assigned-by-dhcp.cox.net","threadId":"7105","inReplyTo":"7vtzwyprr7.fsf_-_@assigned-by-dhcp.cox.net","subject":"GIT v1.5.1-rc1","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-03-19T10:53:47Z","receivedAt":"2007-03-19T10:53:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Some 1000 messages ago, I sent out a short-term release plan and\nlisted the topics that we would want to have in 1.5.1. As of\nlast week, all of them have been cooked enough in 'next' and now\nare in 'master'.\n\nThe last round to reach 1.5.0 took painfully long. While it was\nworth it, considering that 1.5.0 is a big departure from 1.4.4\nseries and satisfied our \"usability and teachability\" goal, I\nthink we should slow down and make smaller releases a bit more\noften. So I tagged the tip of the 'master' with -rc1 tag, after\nfixing one issue that has been nagging me while it was in 'next'.\n\nSo from now on until the final, which I am hoping to do before\nthe end of month, please concentrate on fixes and \"obviously\nlow-impact\" improvements.\n\nWith the system we have in place that uses two primary\nintegration branches to manage git.git project, earth-shattering\nenhancements or new commands could still be cooked in 'pu', or\ntheoretically even in 'next' without causing problems to the\nstabilization effort, but I'd rather see people's attention on\nperfecting what will be in 1.5.1 before starting anything new.\nI expect to spend much less time looking at any material that\nare not meant for 'master' until the end of the month, so please\nconsider that the chance of getting things in 'next' is very\nslim from now on. I might queue new stuff in 'pu' only to give\na distribution point that is easier to access for everybody to\ntest, but I won't guarantee that the branch will even compile.\n\nHaving said that, there always are exceptions to the rule.\n\nSome of the things we have reviewed and discussed on the list\nfor the past several days might have been good for 'next' (or\neven 'master'). I did not have enough time to look at them\nfully, I might have missed them, and/or I commented on them with\nintention to cook them in 'next' but might have forgotten to\napply. If they are reasonably well isolated new features\n(e.g. \"remote show showing push entries\") I would not mind\napplying them, but please make convincing sales talk to explain\nwhy your new feature is useful to users. If it is something so\ncommonly useful to be placed on \"Everyday GIT\", or tutorial,\nadding a paragraph to these documents to show why it is a *must*\n*have* is a good way to sell your ware, for example.\n\nAlso I might have dropped a handful patches to non-core area,\ne.g. contrib/emacs/ and cvs interface. Please remind me of them\nif they should be in 1.5.1 by cheering them on with your Acks,\nresends, and follow-up patches.\n\nEven though it is rather core area, I suspect that it wouldn't\nbe a change with huge impact to exploit what Linus did today to\nallow optimizing pathspec pruning in tree_entry_interesting().\nIf such a change is done obviously correctly, I think it is Ok\nto have it in 'next' and make it graduate to 'master' before\n1.5.1 final.\n\nAlthough we've talked about it for a while, the more I look at\nthe current code, the more I feel that resolving the issue of\n\"read-tree -m\" gotcha that causes switching between branches\nthat have file (or symlink) A and a directory A would be quite\nhigh impact, so unless there is an obviously correct fix, I'd\nlike to defer it post 1.5.1.\n\nFinally, here is to review what we have so far to be in the\nupcoming 1.5.1. Patches to Documentation/RelNotes-1.5.1.txt to\nfill items I missed, older than ceb8442a, are very much\nappreciated.\n\n\nGIT v1.5.1 Release Notes (draft)\n========================\n\nUpdates since v1.5.0\n--------------------\n\n* Deprecated commands and options.\n\n - git-diff-stages and git-resolve have been removed.\n\n* New commands and options.\n\n - \"git log\" and friends take --reverse. This makes output\n that typically goes reverse order in chronological order.\n \"git shortlog\" usually lists commits in chronological order,\n but with \"--reverse\", they are shown in reverse\n chronological order.\n\n - \"git diff\" learned --ignore-space-at-eol. This is a weaker\n form of --ignore-space-change.\n\n - \"git diff --no-index pathA pathB\" can be used as diff\n replacement with git specific enhancements.\n\n - \"git diff --pretty=format:\" to allow more flexible\n custom log output.\n\n - \"git diff --no-index\" can read from '-' (standard input).\n\n - \"git diff\" also learned --exit-code to exit with non-zero\n status when it found differences. In the future we might\n want to make this the default but that would be a rather big\n backward incompatible change; it will stay as an option for\n now.\n\n - \"git branch --track\" can be used to set up configuration\n variables to help it easier to base your work on branches\n you track from a remote site.\n\n - \"git format-patch --attach\" now emits attachments. Use\n --inline to get an inlined multipart/mixed.\n\n - \"git name-rev\" learned --refs=, to limit the tags\n used for naming the given revisions only to the ones\n matching the given pattern.\n\n - \"git remote update\" is to run \"git fetch\" for defined remotes\n to update tracking branches.\n\n - \"git cvsimport\" can now take '-d' to talk with a CVS\n repository different from what are recorded in CVS/Root\n (overriding it with environment CVSROOT does not work).\n\n - \"git bundle\" can help sneaker-netting your changes between\n repositories.\n\n - \"git mergetool\" can help 3-way file-level conflict\n resolution with your favorite graphical merge tools.\n\n - A new configuration \"core.symlinks\" can be used to disable\n symlinks on filesystems that do not support them; they are\n checked out as regular files instead.\n\n\n* Updated behaviour of existing commands.\n\n - \"git fsck\" does not barf on corrupt loose objects.\n\n - \"git archimport\" allows remapping when coming up with git\n branch names from arch names.\n\n - git-svn got almost a rewrite.\n\n - core.autocrlf configuration, when set to 'true', makes git\n to convert CRLF at the end of lines in text files to LF when\n reading from the filesystem, and convert in reverse when\n writing to the filesystem. The variable can be set to\n 'input', in which case the conversion happens only while\n reading from the filesystem but files are written out with\n LF at the end of lines. Currently, which paths to consider\n 'text' (i.e. be subjected to the autocrlf mechanism) is\n decided purely based on the contents, but the plan is to\n allow users to explicitly override this heuristic based on\n paths.\n\n - The behaviour of 'git-apply', when run in a subdirectory,\n without --index nor --cached were inconsistent with that of\n the command with these options. This was fixed to match the\n behaviour with --index. A patch that is meant to be applied\n with -p1 from the toplevel of the project tree can be\n applied with any custom -p option. A patch that is not\n relative to the toplevel needs to be applied with -p\n option with or without --index (or --cached).\n\n - \"git diff\" outputs a trailing HT when pathnames have embedded\n SP on +++/--- header lines, in order to help \"GNU patch\" to\n parse its output. \"git apply\" was already updated to accept\n this modified output format since ce74618d (Sep 22, 2006).\n\n - \"git cvsserver\" runs hooks/update and honors its exit status.\n\n - \"git cvsserver\" can be told to send everything with -kb.\n\n - \"git diff --check\" also honors the --color output option.\n\n - \"git name-rev\" used to stress the fact that a ref is a tag too\n much, by saying something like \"v1.2.3^0~22\". It now says\n \"v1.2.3~22\" in such a case (it still says \"v1.2.3^0\" if it does\n not talk about an ancestor of the commit that is tagged, which\n makes sense).\n\n - \"git rev-list --boundary\" now shows boundary markers for the\n commits omitted by --max-age and --max-count condition.\n\n - The configuration mechanism now reads $(prefix)/etc/gitconfig.\n\n - \"git apply --verbose\" shows what preimage lines were wanted\n when it couldn't find them.\n\n - \"git status\" in a read-only repository got a bit saner.\n\n - \"git fetch\" (hence \"git clone\" and \"git pull\") are less\n noisy when the output does not go to tty.\n\n - \"git fetch\" between repositories with many refs were slow\n even when there are not many changes that needed\n transferring. This has been sped up by partially rewriting\n the heaviest parts in C.\n\n - \"git mailinfo\" which splits an e-mail into a patch and the\n metainformation was rewritten, thanks to Don Zickus. It\n handles nested multipart better.\n\n - send-email learned configurable bcc and chain-reply-to.\n\n - Using objects from packs is now seriouly optimized by clever\n use of a cache. This should be most noticeable in git-log\n family of commands that involve reading many tree objects.\n In addition, traversing revisions while filtering changes\n with pathspecs is made faster by terminating the comparison\n between the trees as early as possible.\n\n\n* Hooks\n\n - The sample update hook to show how to send out notification\n e-mail was updated to show only new commits that appeared in\n the repository. Earlier, it showed new commits that appeared\n on the branch.\n\n\n* Others\n\n - git-revert, git-gc and git-cherry-pick are now built-ins.\n"},{"id":"37495","messageId":"17918.36447.419632.224014@lisa.zopyra.com","threadId":"7105","inReplyTo":"7v8xdth5c4.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: GIT v1.5.1-rc1","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-03-19T13:21:35Z","receivedAt":"2007-03-19T13:21:35Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"On Monday, March 19, 2007 at 03:53:47 (-0700) Junio C Hamano writes:\n>...\n>* Hooks\n>\n> - The sample update hook to show how to send out notification\n> e-mail was updated to show only new commits that appeared in\n> the repository. Earlier, it showed new commits that appeared\n> on the branch.\n\nI did not see Shawn's changes to the update hooks in here, and can't\nrecall where these stand at the moment --- will these be forthcoming?\n\n\nBill\n"},{"id":"37500","messageId":"Pine.LNX.4.63.0703191459440.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"7105","inReplyTo":"7v8xdth5c4.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: GIT v1.5.1-rc1","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-03-19T14:13:31Z","receivedAt":"2007-03-19T14:13:31Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 19 Mar 2007, Junio C Hamano wrote:\n\n> - \"git diff --pretty=format:\" to allow more flexible\n> custom log output.\n\nYou mean \"git log\" there, not \"git diff\", correct?\n\nCiao,\nDscho\n"},{"id":"37566","messageId":"7vd534d8tq.fsf@assigned-by-dhcp.cox.net","threadId":"7105","inReplyTo":"Pine.LNX.4.63.0703191459440.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: GIT v1.5.1-rc1","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-03-20T01:04:17Z","receivedAt":"2007-03-20T01:04:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> On Mon, 19 Mar 2007, Junio C Hamano wrote:\n>\n>> - \"git diff --pretty=format:\" to allow more flexible\n>> custom log output.\n>\n> You mean \"git log\" there, not \"git diff\", correct?\n\nOf course you are right. Any other typos?\n\nI could not parse the --reverse description so I rewrote it\nwhile I was at it, and also I found we did not mention ':/'\nso I added it.\n\n\ndiff --git a/Documentation/RelNotes-1.5.1.txt b/Documentation/RelNotes-1.5.1.txt\nindex f78cf56..215159f 100644\n--- a/Documentation/RelNotes-1.5.1.txt\n+++ b/Documentation/RelNotes-1.5.1.txt\n@@ -10,11 +10,15 @@ Updates since v1.5.0\n \n * New commands and options.\n \n- - \"git log\" and friends take --reverse. This makes output\n- that typically goes reverse order in chronological order.\n- \"git shortlog\" usually lists commits in chronological order,\n- but with \"--reverse\", they are shown in reverse\n- chronological order.\n+ - \"git log\" and friends take --reverse, which instructs them\n+ to give their output in the order opposite from their usual.\n+ They typically output from new to old, but with this option\n+ their output would read from old to new. \"git shortlog\"\n+ usually lists older commits first, but with this option,\n+ they are shown from new to old.\n+\n+ - \"git log --pretty=format:\" to allow more flexible\n+ custom log output.\n \n - \"git diff\" learned --ignore-space-at-eol. This is a weaker\n form of --ignore-space-change.\n@@ -22,9 +26,6 @@ Updates since v1.5.0\n - \"git diff --no-index pathA pathB\" can be used as diff\n replacement with git specific enhancements.\n \n- - \"git diff --pretty=format:\" to allow more flexible\n- custom log output.\n-\n - \"git diff --no-index\" can read from '-' (standard input).\n \n - \"git diff\" also learned --exit-code to exit with non-zero\n@@ -61,6 +62,15 @@ Updates since v1.5.0\n symlinks on filesystems that do not support them; they are\n checked out as regular files instead.\n \n+ - You can name a commit object with its first line of the\n+ message. The syntax to use is ':/message text'. E.g. \n+ \n+ $ git show \":/object name: introduce ':/' notation\"\n+\n+ means the same thing as:\n+\n+ $ git show 28a4d940443806412effa246ecc7768a21553ec7\n+\n \n * Updated behaviour of existing commands.\n \ndiff --git a/Makefile b/Makefile\n"},{"id":"37567","messageId":"7v7itcd8mk.fsf@assigned-by-dhcp.cox.net","threadId":"7105","inReplyTo":"17918.36447.419632.224014@lisa.zopyra.com","subject":"Re: GIT v1.5.1-rc1","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-03-20T01:08:35Z","receivedAt":"2007-03-20T01:08:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Bill Lear writes:\n\n> On Monday, March 19, 2007 at 03:53:47 (-0700) Junio C Hamano writes:\n>>...\n>>* Hooks\n>>\n>> - The sample update hook to show how to send out notification\n>> e-mail was updated to show only new commits that appeared in\n>> the repository. Earlier, it showed new commits that appeared\n>> on the branch.\n>\n> I did not see Shawn's changes to the update hooks in here, and can't\n> recall where these stand at the moment --- will these be forthcoming?\n\nDo you mean \"[PATCH] Split sample update hook into post-receive\nhook\"? My impression was that the discussion that followed made\nits interface obsolete with later 8-patch series from Shawn.\n"},{"id":"37568","messageId":"Pine.LNX.4.63.0703200217480.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"7105","inReplyTo":"7vd534d8tq.fsf@assigned-by-dhcp.cox.net","subject":"Re: GIT v1.5.1-rc1","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-03-20T01:19:24Z","receivedAt":"2007-03-20T01:19:24Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 19 Mar 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > On Mon, 19 Mar 2007, Junio C Hamano wrote:\n> >\n> >> - \"git diff --pretty=format:\" to allow more flexible\n> >> custom log output.\n> >\n> > You mean \"git log\" there, not \"git diff\", correct?\n> \n> Of course you are right. Any other typos?\n\nNot that I know of any...\n\n> I could not parse the --reverse description so I rewrote it\n\n> + - \"git log\" and friends take --reverse, which instructs them\n> + to give their output in the order opposite from their usual.\n\ns/usual/& order/ ?\n\nCiao,\nDscho\n"},{"id":"37573","messageId":"20070320025539.GA28922@spearce.org","threadId":"7105","inReplyTo":"7v7itcd8mk.fsf@assigned-by-dhcp.cox.net","subject":"Re: GIT v1.5.1-rc1","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-03-20T02:55:39Z","receivedAt":"2007-03-20T02:55:39Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> Bill Lear writes:\n> \n> > On Monday, March 19, 2007 at 03:53:47 (-0700) Junio C Hamano writes:\n> >>...\n> >>* Hooks\n> >>\n> >> - The sample update hook to show how to send out notification\n> >> e-mail was updated to show only new commits that appeared in\n> >> the repository. Earlier, it showed new commits that appeared\n> >> on the branch.\n> >\n> > I did not see Shawn's changes to the update hooks in here, and can't\n> > recall where these stand at the moment --- will these be forthcoming?\n> \n> Do you mean \"[PATCH] Split sample update hook into post-receive\n> hook\"? My impression was that the discussion that followed made\n> its interface obsolete with later 8-patch series from Shawn.\n\nI think that's what Bill means, and you are correct Junio, that patch\nis not valid anymore now that post-receive takes its data on stdin.\n\nI was hoping Andy or one of the other folks who have worked on\nthat hook would pick up the ball and update the hook, but I\nthink they are stuck on the fact that you cannot use:\n\n\tgit log $new --not --all\n\nin the post-receive hook to see what commits are \"new to this\nrepository\", as $new is already in --all. ;-)\n\nThat almost needs a --all-except=\"refs/heads/a refs/heads/b\" option\nto rev-list. Grrrr.\n\n-- \nShawn.\n"},{"id":"37612","messageId":"200703200937.39440.andyparkins@gmail.com","threadId":"7105","inReplyTo":"20070320025539.GA28922@spearce.org","subject":"Re: GIT v1.5.1-rc1","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-03-20T09:37:38Z","receivedAt":"2007-03-20T09:37:38Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Tuesday 2007 March 20 02:55, Shawn O. Pearce wrote:\n\n> I was hoping Andy or one of the other folks who have worked on\n> that hook would pick up the ball and update the hook, but I\n\nI'll be delighted to port the hook script - I've got some fixes that haven't \nbeen nicely stacked yet. The problem I have for porting the hook is as you \npoint out:\n\n> think they are stuck on the fact that you cannot use:\n>\n> \tgit log $new --not --all\n\n> That almost needs a --all-except=\"refs/heads/a refs/heads/b\" option\n> to rev-list. Grrrr.\n\nI'm afraid so. Would a --ignore list be more appropriate? That way you could \nlist any refs you wanted (i.e. not just --all) and then have that list \nfinally filtered by --ignore.\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"37621","messageId":"20070320144206.GB1750@spearce.org","threadId":"7105","inReplyTo":"200703200937.39440.andyparkins@gmail.com","subject":"Re: GIT v1.5.1-rc1","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-03-20T14:42:06Z","receivedAt":"2007-03-20T14:42:06Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Andy Parkins wrote:\n> On Tuesday 2007 March 20 02:55, Shawn O. Pearce wrote:\n> > think they are stuck on the fact that you cannot use:\n> >\n> > \tgit log $new --not --all\n> \n> > That almost needs a --all-except=\"refs/heads/a refs/heads/b\" option\n> > to rev-list. Grrrr.\n> \n> I'm afraid so. Would a --ignore list be more appropriate? That way you could \n> list any refs you wanted (i.e. not just --all) and then have that list \n> finally filtered by --ignore.\n\nLast night on #git Dscho suggested something like:\n\n git log $new --not '!a' '!b' --all\n\nas a way to say ignore ref a and ref b when otherwise parsing the\ncommand line arguments. Ugly, very ugly. But is more or less the\nsame idea you are talking about with the --ignore flag.\n\n-- \nShawn.\n"},{"id":"37645","messageId":"etpqlk$jvq$1@sea.gmane.org","threadId":"7105","inReplyTo":"20070320144206.GB1750@spearce.org","subject":"Re: GIT v1.5.1-rc1","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-03-20T23:30:46Z","receivedAt":"2007-03-20T23:30:46Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Shawn O. Pearce wrote:\n\n> Andy Parkins wrote:\n>> On Tuesday 2007 March 20 02:55, Shawn O. Pearce wrote:\n>>> think they are stuck on the fact that you cannot use:\n>>>\n>>> git log $new --not --all\n>> \n>>> That almost needs a --all-except=\"refs/heads/a refs/heads/b\" option\n>>> to rev-list. Grrrr.\n>> \n>> I'm afraid so. Would a --ignore list be more appropriate? That way you could \n>> list any refs you wanted (i.e. not just --all) and then have that list \n>> finally filtered by --ignore.\n> \n> Last night on #git Dscho suggested something like:\n> \n> git log $new --not '!a' '!b' --all\n> \n> as a way to say ignore ref a and ref b when otherwise parsing the\n> command line arguments. Ugly, very ugly. But is more or less the\n> same idea you are talking about with the --ignore flag.\n\nYou mean\n\n git log $new --not ^a ^b --all\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"37657","messageId":"7v648v5goy.fsf@assigned-by-dhcp.cox.net","threadId":"7105","inReplyTo":"20070320025539.GA28922@spearce.org","subject":"Re: GIT v1.5.1-rc1","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-03-21T05:06:05Z","receivedAt":"2007-03-21T05:06:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Shawn O. Pearce\" writes:\n\n> I was hoping Andy or one of the other folks who have worked on\n> that hook would pick up the ball and update the hook, but I\n> think they are stuck on the fact that you cannot use:\n>\n> \tgit log $new --not --all\n>\n> in the post-receive hook to see what commits are \"new to this\n> repository\", as $new is already in --all. ;-)\n\nAs you have the set of refs that were updated and their old and\nnew commit object names, I do not think it is a problem at all.\nInstead of using --all, you can list the old commit object names\nfor the refs involved in this round of the push and you\nenumerate the refs that are _not_ involved in this round of the\npush.\n\nBut I do not think \"new to this repository\" is the right thing\nto compute in the first place. In a heavily topic-oriented\ndevelopment style, you may do something like this:\n\n\t$ git checkout -b topic master\n $ git am series.mbox\n\t$ git checkout next\n\t$ git merge topic\n $ git push $URL next\n\nThe hook would report the commit resulting from patches in\nseries.mbox after this push, which is fine.\n\nHowever, after the topic cooks in 'next' and proves to be fine,\nthe next push would go like this:\n\n\t$ git checkout master\n $ git merge topic\n $ git push $URL master\n\nThere is no new commit that appeared in the repository with this\npush, and there will be no notification sent out, if you do \"new\nto this repository\".\n\nThe latter is, however, far more significant event than the\nformer, from the point of view of overall project history, both\nfor a casual user who tracks only the primary integration branch\nand for a developer who is expected to fork his new work off of\nthe primary integration branch. Showing only new commits that\nappeared in the repository is absolutely the wrong thing to do.\n"},{"id":"37679","messageId":"200703211607.20361.andyparkins@gmail.com","threadId":"7105","inReplyTo":"7v648v5goy.fsf@assigned-by-dhcp.cox.net","subject":"Re: GIT v1.5.1-rc1","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-03-21T16:07:18Z","receivedAt":"2007-03-21T16:07:18Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Wednesday 2007 March 21 05:06, Junio C Hamano wrote:\n\n> But I do not think \"new to this repository\" is the right thing\n> to compute in the first place. In a heavily topic-oriented\n> development style, you may do something like this:\n\nUnfortunately, I think it's the only thing that can sensibly be done.\n\nAssume that we want every commit to appear on one, and only one email. It's \ngot to be done by only showing the new commits.\n\n> However, after the topic cooks in 'next' and proves to be fine,\n> the next push would go like this:\n>\n> \t$ git checkout master\n> $ git merge topic\n> $ git push $URL master\n>\n> There is no new commit that appeared in the repository with this\n> push, and there will be no notification sent out, if you do \"new\n> to this repository\".\n\nYes there is; the notification says that ref master was updated. It wouldn't \nshow any new commits - which is exactly right. This to my mind is the same \nreason that fast-forward merges are better than all-merges-the-same.\n\nThe truth is that there were no new commits, so the email generator should \nshow no new commits; however there was a ref change so it should show that. \nThat's exactly what the current hook does.\n\nThe only fault in it, that I've yet to fix, is that it shows an empty log \nsection; I eventually want the zero-new-commits case to be caught and a \nlittle description of why there are no new commits output instead.\n\n> The latter is, however, far more significant event than the\n> former, from the point of view of overall project history, both\n> for a casual user who tracks only the primary integration branch\n> and for a developer who is expected to fork his new work off of\n> the primary integration branch. Showing only new commits that\n> appeared in the repository is absolutely the wrong thing to do.\n\nI don't think so; either the merge generated a new commit, in which case that \nmerge commit will be shown, or the merge didn't generate a new commit in \nwhich case the report of the branch change is all that is needed.\n\nNote: none of your examples describe a case where an email of some sort is not \ngenerated.\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"}]}