* dt/tests-with-env-not-subshell:
  tests: use "env" to run commands with temporary env-var settings

Ordinarily, we would say "VAR=VAL command" to execute a tested
command with environment variable(s) set only for that command.
This however does not work if 'command' is a shell function (most
notably 'test_must_fail'); the result of the assignment is retained
and affects later commands.

To avoid this, we used to assign and export environment variables
and run such a test in a subshell, like so:

        (
                VAR=VAL && export VAR &&
                test_must_fail git command to be tested
        )

But with "env" utility, we should be able to say:

        test_must_fail env VAR=VAL git command to be tested

which is much shorter and easier to read.

Signed-off-by: David Tran <unsignedzero@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Currently "git notes add -C $object" will read the raw bytes from $object,
and then copy those bytes into the note object, which is hardcoded to be
of type blob. This means that if the given $object is a non-blob (e.g.
tree or commit), the raw bytes from that object is copied into a blob
object. This is probably not useful, and certainly not what any sane
user would expect. So disallow it, by erroring out if the $object passed
to the -C option is not a blob.

The fix also applies to the -c option (in which the user is prompted to
edit/verify the note contents in a text editor), and also when -c/-C is
passed to "git notes append" (which appends the $object contents to an
existing note object). In both cases, passing a non-blob $object does not
make sense.

Also add a couple of tests demonstrating expected behavior.

Suggested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Teach the command to read object names to remove from the standard
input, in addition to the object names given from the command line.

Signed-off-by: Junio C Hamano <gitster@pobox.com>

Depending on the application, it is not necessarily an error for an object
to lack a note, especially if the only thing the caller wants to make sure
is that notes are cleared for an object.  By passing this option from the
command line, the "git notes remove" command considers it a success if the
object did not have any note to begin with.

Signed-off-by: Junio C Hamano <gitster@pobox.com>

While "xargs -n1 git notes rm" is certainly a possible way to remove notes
from many objects, this would create one notes "commit" per removal, which
is not quite suitable for seasonal housekeeping.

Allow taking more than one on the command line, and record their removal
as a single atomic event if everthing goes well.

Even though the old code insisted that "git notes rm" must be given only
one object (or zero, in which case it would default to HEAD), this
condition was not tested. Add tests to handle the new case where we feed
multiple objects, and also make sure if there is a bad input, no change
is recorded.

Signed-off-by: Junio C Hamano <gitster@pobox.com>

* jk/notes-ui-updates:
  contrib/completion: --notes, --no-notes
  log/pretty-options: Document --[no-]notes and deprecate old notes options
  revision.c: make --no-notes reset --notes list
  revision.c: support --notes command-line option
  notes: refactor display notes default handling
  notes: refactor display notes extra refs field
  revision.c: refactor notes ref expansion
  notes: make expand_notes_ref globally accessible

Currently, "notes add" (without -f/--force) will abort when the given object
already has existing notes. This makes sense for the modes of "git notes add"
that would necessarily overwrite the old message (when using the -m/-F/-C/-c
options). However, when no options are given (meaning the notes are created
from scratch in the editor) it is not very user-friendly to abort on existing
notes, and forcing the user to run "git notes edit".

Instead, it is better to simply "redirect" to "git notes edit" automatically,
i.e. open the existing notes in the editor and let the user edit them.
This patch does just that.

This changes the behavior of "git notes add" without options when notes
already exist for the given object, but I doubt that many users really depend
on the previous failure from "git notes add" in this case.

Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

With most command line options, later instances of an option
override earlier ones. With cumulative options like
"--notes", however, there is no way to say "forget the
--notes I gave you before".

Let's have --no-notes trigger this forgetting, so that:

  git log --notes=foo --no-notes --notes=bar

will show only the "bar" notes.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

We already have --show-notes, but it has a few shortcomings:

  1. Using --show-notes=<ref> implies that we should also
     show the default notes. Which means you also need to
     use --no-standard-notes if you want to suppress them.

  2. It is negated by --no-notes, which doesn't match.

  3. It's too long to type. :)

This patch introduces --notes, which behaves exactly like
--show-notes, except that using "--notes=<ref>" does not
imply showing the default notes.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>