git/builtin/commit.c, branch v1.8.2.2

git-commit: only append a newline to -m mesg if necessary

2013-02-19T17:30:50Z

Currently, git will append two newlines to every message supplied via the -m switch. The purpose of this is to allow -m to be supplied multiple times and have each supplied string become a paragraph in the resulting commit message. Normally, this does not cause a problem since any trailing newlines will be removed by the cleanup operation. If cleanup=verbatim for example, then the trailing newlines will not be removed and will survive into the resulting commit message. Instead, let's ensure that the string supplied to -m is newline terminated, but only append a second newline when appending additional messages. Fixes the test in t7502. Signed-off-by: Brandon Casey Reviewed-by: Jonathan Nieder Signed-off-by: Junio C Hamano

Merge branch 'maint'

2013-02-12T20:23:12Z

* maint: Replace filepattern with pathspec for consistency

Replace filepattern with pathspec for consistency

2013-02-12T18:05:38Z

pathspec is the most widely used term, and is the one defined in gitglossary.txt. was used only in the synopsys for git-add and git-commit, and in git-add.txt. Get rid of it. This patch is obtained with by running: perl -pi -e 's/filepattern/pathspec/' `git grep -l filepattern` Signed-off-by: Matthieu Moy Signed-off-by: Junio C Hamano

Merge branch 'jk/read-commit-buffer-data-after-free'

2013-02-04T18:25:18Z

Clarify the ownership rule for commit->buffer field, which some callers incorrectly accessed without making sure it is populated. * jk/read-commit-buffer-data-after-free: logmsg_reencode: lazily load missing commit buffers logmsg_reencode: never return NULL commit: drop useless xstrdup of commit message

Merge branch 'jc/custom-comment-char'

2013-02-04T18:23:49Z

Allow a configuration variable core.commentchar to customize the character used to comment out the hint lines in the edited text from the default '#'. * jc/custom-comment-char: Allow custom "comment char"

logmsg_reencode: never return NULL

2013-01-26T21:28:21Z

The logmsg_reencode function will return the reencoded commit buffer, or NULL if reencoding failed or no reencoding was necessary. Since every caller then ends up checking for NULL and just using the commit's original buffer, anyway, we can be a bit more helpful and just return that buffer when we would have returned NULL. Since the resulting string may or may not need to be freed, we introduce a logmsg_free, which checks whether the buffer came from the commit object or not (callers either implemented the same check already, or kept two separate pointers, one to mark the buffer to be used, and one for the to-be-freed string). Pushing this logic into logmsg_* simplifies the callers, and will let future patches lazily load the commit buffer in a single place. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

commit: drop useless xstrdup of commit message

2013-01-26T21:28:19Z

When git-commit is asked to reuse a commit message via "-c", we call read_commit_message, which looks up the commit and hands back either the re-encoded result, or a copy of the original. We make a copy in the latter case so that the ownership semantics of the return value are clear (in either case, it can be freed). However, since we return a "const char *", and since the resulting buffer's lifetime is the same as that of the whole program, we never bother to free it at all. Let's just drop the copy. That saves us a copy in the common case. While it does mean we leak in the re-encode case, it doesn't matter, since we are relying on program exit to free the memory anyway. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'as/pre-push-hook'

2013-01-24T05:19:25Z

Add an extra hook so that "git push" that is run without making sure what is being pushed is sane can be checked and rejected (as opposed to the user deciding not pushing). * as/pre-push-hook: Add sample pre-push hook script push: Add support for pre-push hooks hooks: Add function to check if a hook exists

Allow custom "comment char"

2013-01-16T20:48:22Z

Some users do want to write a line that begin with a pound sign, #, in their commit log message. Many tracking system recognise a token of # form, for example. The support we offer these use cases is not very friendly to the end users. They have a choice between - Don't do it. Avoid such a line by rewrapping or indenting; and - Use --cleanup=whitespace but remove all the hint lines we add. Give them a way to set a custom comment char, e.g. $ git -c core.commentchar="%" commit so that they do not have to do either of the two workarounds. [jc: although I started the topic, all the tests and documentation updates, many of the call sites of the new strbuf_add_commented_*() functions, and the change to git-submodule.sh scripted Porcelain are from Ralf.] Signed-off-by: Junio C Hamano Signed-off-by: Ralf Thielow Signed-off-by: Junio C Hamano

hooks: Add function to check if a hook exists

2013-01-14T17:25:40Z

Create find_hook() function to determine if a given hook exists and is executable. If it is, the path to the script will be returned, otherwise NULL is returned. This encapsulates the tests that are used to check for the existence of a hook in one place, making it easier to modify those checks if that is found to be necessary. This also makes it simple for places that can use a hook to check if a hook exists before doing, possibly lengthy, setup work which would be pointless if no such hook is present. The returned value is left as a static value from get_pathname() rather than a duplicate because it is anticipated that the return value will either be used as a boolean, immediately added to an argv_array list which would result in it being duplicated at that point, or used to actually run the command without much intervening work. Callers which need to hold onto the returned value for a longer time are expected to duplicate the return value themselves. Signed-off-by: Aaron Schrab Signed-off-by: Junio C Hamano