patchMake 'make' quieter while building git

I find it difficult to see compiler warnings amongst the massive spewing produced by GNU make as it works through our productions. This is especially true if CFLAGS winds up being rather long, due to a large number of -W options being enabled and due to a number of -D options being configured/required by my platform.

By defining QUIET_MAKE (e.g. make QUIET_MAKE=YesPlease) during compilation users will get a less verbose output, such as:

    ...
    CC builtin-grep.c
builtin-grep.c:187: warning: 'external_grep' defined but not used
    CC builtin-init-db.c
    CC builtin-log.c
    CC builtin-ls-files.c
    CC builtin-ls-tree.c
    ...

The verbose (normal make) output is still the default.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
 Makefile           |   86 +++++++++++++++++++++++++++++----------------------
 perl/Makefile      |    8 ++++-
 templates/Makefile |   10 ++++--
 3 files changed, 62 insertions(+), 42 deletions(-)

"Shawn O. Pearce" <spearce@spearce.org> writes:

I agree, and suspect it might even be a better idea to make this the default, with "make V=1" to make chattier.

Now we should do the same to git-gui, shouldn't we? Time for me to subtree-merge git-gui to my master?

Junio C Hamano <junkio@cox.net> wrote:

See my other patch.  ;-)
 

Done. gitgui-0.6.3 is tagged and ready to be pulled into maint. There's a few small fixes in there that have been accumlating too. Be nice to get them into your next release, whatever that winds up being. ;-)

"Shawn O. Pearce" <spearce@spearce.org> writes:

Just to make sure this is not the rewrite and big clean-up you were talking about but for maintenance?

Junio C Hamano <junkio@cox.net> wrote:

Yes. I have not even started rewrite and big clean-up effort, let alone pushed it to repo.or.cz. ;-)

"Shawn O. Pearce" <spearce@spearce.org> writes:

Surely git-gui 0.6.3 will be in 1.5.0.4, but I'd like to start planning for 1.5.1 now.

In addition to what are described in the current 1.5.1 draft release notes, I'd like to have a few topics graduated to 'master' and declare 1.5.1 by the end of the month.

That would mean we would have these biggies among other things in 1.5.1:

Already in 'master':

 - git-apply subdirectory behaviour fix
 - git-remote update
 - git-bundle
 - working on filesystems without symbolic links
 - automatic CRLF munging
 - git-rev-list --boundary --max-count (broken)
 - /etc/gitconfig

Cooking in 'next':

 - git-diff --no-index
 - built-in git-revert/git-cherry-pick
 - git-rev-list --boundary --max-count fix (this is sorely
   needed to make "gitk -50 master" to work)
 - handling corrupt loose objects in git-fsck and unpack_sha1_file
 - commit --interactive
 - format-patch --inline/--attach

Not in 'next' yet, but would like to have in 1.5.1:

 - git-branch --track and git-checkout -B

In 'next' or 'pu' but needs more work, will not be in 1.5.1:

 - git-fetch half-C-rewrite.
 - .gitattributes (the code needs redesign --- handling multiple
   actions on a single path is nasty).
 - git-merge-subtree (subtree matching needs more work).

Some 1000 messages ago, I sent out a short-term release plan and listed the topics that we would want to have in 1.5.1. As of last week, all of them have been cooked enough in 'next' and now are in 'master'.

The last round to reach 1.5.0 took painfully long. While it was worth it, considering that 1.5.0 is a big departure from 1.4.4 series and satisfied our "usability and teachability" goal, I think we should slow down and make smaller releases a bit more often. So I tagged the tip of the 'master' with -rc1 tag, after fixing one issue that has been nagging me while it was in 'next'.

So from now on until the final, which I am hoping to do before the end of month, please concentrate on fixes and "obviously low-impact" improvements.

With the system we have in place that uses two primary integration branches to manage git.git project, earth-shattering enhancements or new commands could still be cooked in 'pu', or theoretically even in 'next' without causing problems to the stabilization effort, but I'd rather see people's attention on perfecting what will be in 1.5.1 before starting anything new. I expect to spend much less time looking at any material that are not meant for 'master' until the end of the month, so please consider that the chance of getting things in 'next' is very slim from now on. I might queue new stuff in 'pu' only to give a distribution point that is easier to access for everybody to test, but I won't guarantee that the branch will even compile.

Having said that, there always are exceptions to the rule.

Some of the things we have reviewed and discussed on the list for the past several days might have been good for 'next' (or even 'master'). I did not have enough time to look at them fully, I might have missed them, and/or I commented on them with intention to cook them in 'next' but might have forgotten to apply. If they are reasonably well isolated new features (e.g. "remote show showing push entries") I would not mind applying them, but please make convincing sales talk to explain why your new feature is useful to users. If it is something so commonly useful to be placed on "Everyday GIT", or tutorial, adding a paragraph to these documents to show why it is a *must* *have* is a good way to sell your ware, for example.

Also I might have dropped a handful patches to non-core area, e.g. contrib/emacs/ and cvs interface. Please remind me of them if they should be in 1.5.1 by cheering them on with your Acks, resends, and follow-up patches.

Even though it is rather core area, I suspect that it wouldn't be a change with huge impact to exploit what Linus did today to allow optimizing pathspec pruning in tree_entry_interesting(). If such a change is done obviously correctly, I think it is Ok to have it in 'next' and make it graduate to 'master' before 1.5.1 final.

Although we've talked about it for a while, the more I look at the current code, the more I feel that resolving the issue of "read-tree -m" gotcha that causes switching between branches that have file (or symlink) A and a directory A would be quite high impact, so unless there is an obviously correct fix, I'd like to defer it post 1.5.1.

Finally, here is to review what we have so far to be in the upcoming 1.5.1. Patches to Documentation/RelNotes-1.5.1.txt to fill items I missed, older than ceb8442a, are very much appreciated.

GIT v1.5.1 Release Notes (draft) ========================

Updates since v1.5.0 --------------------

* Deprecated commands and options.

  - git-diff-stages and git-resolve have been removed.

* New commands and options.

  - "git log" and friends take --reverse.  This makes output
    that typically goes reverse order in chronological order.
    "git shortlog" usually lists commits in chronological order,
    but with "--reverse", they are shown in reverse
    chronological order.

  - "git diff" learned --ignore-space-at-eol.  This is a weaker
    form of --ignore-space-change.

  - "git diff --no-index pathA pathB" can be used as diff
    replacement with git specific enhancements.

  - "git diff --pretty=format:<string>" to allow more flexible
    custom log output.

  - "git diff --no-index" can read from '-' (standard input).

  - "git diff" also learned --exit-code to exit with non-zero
    status when it found differences.  In the future we might
    want to make this the default but that would be a rather big
    backward incompatible change; it will stay as an option for
    now.

  - "git branch --track" can be used to set up configuration
    variables to help it easier to base your work on branches
    you track from a remote site.

  - "git format-patch --attach" now emits attachments.  Use
    --inline to get an inlined multipart/mixed.

  - "git name-rev" learned --refs=<pattern>, to limit the tags
    used for naming the given revisions only to the ones
    matching the given pattern.

  - "git remote update" is to run "git fetch" for defined remotes
    to update tracking branches.

  - "git cvsimport" can now take '-d' to talk with a CVS
    repository different from what are recorded in CVS/Root
    (overriding it with environment CVSROOT does not work).

  - "git bundle" can help sneaker-netting your changes between
    repositories.

  - "git mergetool" can help 3-way file-level conflict
    resolution with your favorite graphical merge tools.

  - A new configuration "core.symlinks" can be used to disable
    symlinks on filesystems that do not support them; they are
    checked out as regular files instead.

* Updated behaviour of existing commands.

  - "git fsck" does not barf on corrupt loose objects.

  - "git archimport" allows remapping when coming up with git
    branch names from arch names.

  - git-svn got almost a rewrite.

  - core.autocrlf configuration, when set to 'true', makes git
    to convert CRLF at the end of lines in text files to LF when
    reading from the filesystem, and convert in reverse when
    writing to the filesystem.  The variable can be set to
    'input', in which case the conversion happens only while
    reading from the filesystem but files are written out with
    LF at the end of lines.  Currently, which paths to consider
    'text' (i.e. be subjected to the autocrlf mechanism) is
    decided purely based on the contents, but the plan is to
    allow users to explicitly override this heuristic based on
    paths.

  - The behaviour of 'git-apply', when run in a subdirectory,
    without --index nor --cached were inconsistent with that of
    the command with these options.  This was fixed to match the
    behaviour with --index.  A patch that is meant to be applied
    with -p1 from the toplevel of the project tree can be
    applied with any custom -p<n> option.  A patch that is not
    relative to the toplevel needs to be applied with -p<n>
    option with or without --index (or --cached).

  - "git diff" outputs a trailing HT when pathnames have embedded
    SP on +++/--- header lines, in order to help "GNU patch" to
    parse its output.  "git apply" was already updated to accept
    this modified output format since ce74618d (Sep 22, 2006).

  - "git cvsserver" runs hooks/update and honors its exit status.

  - "git cvsserver" can be told to send everything with -kb.

  - "git diff --check" also honors the --color output option.

  - "git name-rev" used to stress the fact that a ref is a tag too
    much, by saying something like "v1.2.3^0~22".  It now says
    "v1.2.3~22" in such a case (it still says "v1.2.3^0" if it does
    not talk about an ancestor of the commit that is tagged, which
    makes sense).

  - "git rev-list --boundary" now shows boundary markers for the
    commits omitted by --max-age and --max-count condition.

  - The configuration mechanism now reads $(prefix)/etc/gitconfig.

  - "git apply --verbose" shows what preimage lines were wanted
    when it couldn't find them.

  - "git status" in a read-only repository got a bit saner.

  - "git fetch" (hence "git clone" and "git pull") are less
    noisy when the output does not go to tty.

  - "git fetch" between repositories with many refs were slow
    even when there are not many changes that needed
    transferring.  This has been sped up by partially rewriting
    the heaviest parts in C.

  - "git mailinfo" which splits an e-mail into a patch and the
    metainformation was rewritten, thanks to Don Zickus.  It
    handles nested multipart better.

  - send-email learned configurable bcc and chain-reply-to.

  - Using objects from packs is now seriouly optimized by clever
    use of a cache.  This should be most noticeable in git-log
    family of commands that involve reading many tree objects.
    In addition, traversing revisions while filtering changes
    with pathspecs is made faster by terminating the comparison
    between the trees as early as possible.

* Hooks

  - The sample update hook to show how to send out notification
    e-mail was updated to show only new commits that appeared in
    the repository.  Earlier, it showed new commits that appeared
    on the branch.

* Others

  - git-revert, git-gc and git-cherry-pick are now built-ins.

On Monday, March 19, 2007 at 03:53:47 (-0700) Junio C Hamano writes:

I did not see Shawn's changes to the update hooks in here, and can't recall where these stand at the moment --- will these be forthcoming?

Bill

Bill Lear <rael@zopyra.com> writes:

Do you mean "[PATCH] Split sample update hook into post-receive hook"? My impression was that the discussion that followed made its interface obsolete with later 8-patch series from Shawn.

Junio C Hamano <junkio@cox.net> wrote:

I think that's what Bill means, and you are correct Junio, that patch is not valid anymore now that post-receive takes its data on stdin.

I was hoping Andy or one of the other folks who have worked on that hook would pick up the ball and update the hook, but I think they are stuck on the fact that you cannot use:

	git log $new --not --all

in the post-receive hook to see what commits are "new to this repository", as $new is already in --all. ;-)

That almost needs a --all-except="refs/heads/a refs/heads/b" option to rev-list. Grrrr.

On Tuesday 2007 March 20 02:55, Shawn O. Pearce wrote:

I'll be delighted to port the hook script - I've got some fixes that haven't been nicely stacked yet. The problem I have for porting the hook is as you point out:

I'm afraid so. Would a --ignore list be more appropriate? That way you could list any refs you wanted (i.e. not just --all) and then have that list finally filtered by --ignore.

Andy

Andy Parkins <andyparkins@gmail.com> wrote:

Last night on #git Dscho suggested something like:

  git log $new --not '!a' '!b' --all

as a way to say ignore ref a and ref b when otherwise parsing the command line arguments. Ugly, very ugly. But is more or less the same idea you are talking about with the --ignore flag.

Shawn O. Pearce wrote:

You mean

  git log $new --not ^a ^b --all

"Shawn O. Pearce" <spearce@spearce.org> writes:

As you have the set of refs that were updated and their old and new commit object names, I do not think it is a problem at all. Instead of using --all, you can list the old commit object names for the refs involved in this round of the push and you enumerate the refs that are _not_ involved in this round of the push.

But I do not think "new to this repository" is the right thing to compute in the first place. In a heavily topic-oriented development style, you may do something like this:

	$ git checkout -b topic master
        $ git am series.mbox
	$ git checkout next
	$ git merge topic
        $ git push $URL next

The hook would report the commit resulting from patches in series.mbox after this push, which is fine.

However, after the topic cooks in 'next' and proves to be fine, the next push would go like this:

	$ git checkout master
        $ git merge topic
        $ git push $URL master

There is no new commit that appeared in the repository with this push, and there will be no notification sent out, if you do "new to this repository".

The latter is, however, far more significant event than the former, from the point of view of overall project history, both for a casual user who tracks only the primary integration branch and for a developer who is expected to fork his new work off of the primary integration branch. Showing only new commits that appeared in the repository is absolutely the wrong thing to do.

On Wednesday 2007 March 21 05:06, Junio C Hamano wrote:

Unfortunately, I think it's the only thing that can sensibly be done.

Assume that we want every commit to appear on one, and only one email. It's got to be done by only showing the new commits.

Yes there is; the notification says that ref master was updated. It wouldn't show any new commits - which is exactly right. This to my mind is the same reason that fast-forward merges are better than all-merges-the-same.

The truth is that there were no new commits, so the email generator should show no new commits; however there was a ref change so it should show that. That's exactly what the current hook does.

The only fault in it, that I've yet to fix, is that it shows an empty log section; I eventually want the zero-new-commits case to be caught and a little description of why there are no new commits output instead.

I don't think so; either the merge generated a new commit, in which case that merge commit will be shown, or the merge didn't generate a new commit in which case the report of the branch change is all that is needed.

Note: none of your examples describe a case where an email of some sort is not 
generated.

Andy

Hi,

On Mon, 19 Mar 2007, Junio C Hamano wrote:

You mean "git log" there, not "git diff", correct?

Ciao, Dscho

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Of course you are right.  Any other typos?

I could not parse the --reverse description so I rewrote it while I was at it, and also I found we did not mention ':/<message>' so I added it.

Hi,

On Mon, 19 Mar 2007, Junio C Hamano wrote:

Not that I know of any...

s/usual/& order/ ?

Ciao, Dscho

On 3/6/07, Shawn O. Pearce <spearce@spearce.org> wrote:

Can I suggest printing the resulting object file instead of source? It is useful if you want rebuild just one file by mouse-copy-paste it into command line (the source file name for editor in case of error is already in error message).

Hi,

On Tue, 6 Mar 2007, Alex Riesen wrote:

I don't understand. If you want to fix what was triggering the warning, you have to edit the source, no? Besides, this warning is generated by the compiler, so I doubt we can do anything about it.

Ciao, Dscho

On 3/6/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Right. Because I was suggesting to output something like this:

$ make
...
     CC builtin-grep.o
builtin-grep.c:187: warning: 'external_grep' defined but not used

Notice "builtin-grep.o" (the ".o", not _.c_). IOW, we already see builtin-grep.c when we need it (in the error/warning message), BUT the builtin-grep.o is missing (and is useful for mouse-copy-paste).

Hi,

On Tue, 6 Mar 2007, Alex Riesen wrote:

Ah! That explains it why I did not understand.

Ciao, Dscho

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

But doesn't "CC foo.o" look just simply WRONG? We compile foo.c to produce foo.o. An alternative that I could slightly more sympathize with would be something like this:

	CC builtin-grep.c => builtin-grep.o

On 3/7/07, Junio C Hamano <junkio@cox.net> wrote:

not if you compiled kernels. Doesn't it look wrong to output information you already have, if you need to?

Alex Riesen <raa.lkml@gmail.com> wrote:

Well, I have to admit, the Linux kernel is where I got the idea from. But I have not built one in a while so I didn't remember what it outputs, exactly.

I also was too lazy to go look at the kernel makefiles, even though I have them handy.

;-)