summaryrefslogtreecommitdiff
path: root/builtin/log.c
AgeCommit message (Collapse)AuthorFilesLines
2010-09-29Merge branch 'rr/format-patch-count-without-merges'Libravatar Junio C Hamano1-6/+1
* rr/format-patch-count-without-merges: format-patch: Don't go over merge commits t4014-format-patch: Call test_tick before committing
2010-08-27format-patch: Don't go over merge commitsLibravatar Ramkumar Ramachandra1-6/+1
If the topmost three commits in a branch were merge commits, 'git format-patch -3' used to output nothing. Since Git can't prepare patches out of merge commits anyway, don't go over them in the first place. 'git format-patch -3' now prepares three patches from the topmost three commits without counting merge commits. Also add a corresponding test in t4014-format-patch and update documentation. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-25Fix 'git log' early pager startup error caseLibravatar Linus Torvalds1-6/+1
We start the pager too early for several git commands, which results in the errors sometimes going to the pager rather than show up as errors. This is often hidden by the fact that we pass in '-X' to less by default, which causes 'less' to exit for small output, but if you do export LESS=-S you can then clearly see the problem by doing git log --prretty which shows the error message ("fatal: unrecognized argument: --prretty") being sent to the pager. This happens for pretty much all git commands that use USE_PAGER, and then check arguments separately. But "git diff" does it too early too (even though it does an explicit setup_pager() call) This only fixes it for the trivial "git log" family case. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-30Merge branch 'ar/decorate-color'Libravatar Junio C Hamano1-0/+3
* ar/decorate-color: Add test for correct coloring of git log --decoration Allow customizable commit decorations colors log --decorate: Colorize commit decorations log-tree.c: Use struct name_decoration's type for classifying decoration commit.h: add 'type' to struct name_decoration
2010-06-30Merge branch 'jp/string-list-api-cleanup'Libravatar Junio C Hamano1-10/+10
* jp/string-list-api-cleanup: string_list: Fix argument order for string_list_append string_list: Fix argument order for string_list_lookup string_list: Fix argument order for string_list_insert_at_index string_list: Fix argument order for string_list_insert string_list: Fix argument order for for_each_string_list string_list: Fix argument order for print_string_list
2010-06-27string_list: Fix argument order for string_list_appendLibravatar Julian Phillips1-10/+10
Update the definition and callers of string_list_append to use the string_list as the first argument. This helps make the string_list API easier to use by being more consistent. Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-24Allow customizable commit decorations colorsLibravatar Nazri Ramliy1-0/+3
Signed-off-by: Nazri Ramliy <ayiehere@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-16format-patch: Add a signature option (--signature)Libravatar Stephen Boyd1-3/+15
By default, git uses the version string as the signature for all patches output by format-patch. Many employers (mine included) require the use of a signature on all outgoing mails. In a format-patch | send-email workflow there isn't an easy way to modify the signature without breaking the pipe and manually replacing the version string with the signature required. Instead of doing all that work, add an option (--signature) and a config variable (format.signature) to replace the default git version signature when formatting patches. This does modify the original behavior of format-patch a bit. First off the version string is now placed in the cover letter by default. Secondly, once the configuration variable format.signature is added to the .config file there is no way to revert back to the default git version signature. Instead, specifying the --no-signature option will remove the signature from the patches entirely. Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-05-08Merge branch 'sd/log-decorate'Libravatar Junio C Hamano1-6/+40
* sd/log-decorate: log.decorate: only ignore it under "log --pretty=raw" script with rev-list instead of log log --pretty/--oneline: ignore log.decorate log.decorate: usability fixes Add `log.decorate' configuration variable. git_config_maybe_bool() Conflicts: builtin/log.c
2010-04-13pretty: Initialize notes if %N is usedLibravatar Johannes Gilger1-1/+5
When using git log --pretty='%N' without an explicit --show-notes, git would segfault. This patches fixes this behaviour by loading the needed notes datastructures if --pretty is used and the format contains %N. When --pretty='%N' is used together with --no-notes, %N won't be expanded. This is an extension to a proposed patch by Jeff King. Signed-off-by: Johannes Gilger <heipei@hackvalue.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-03Merge branch 'ef/cherry-abbrev'Libravatar Junio C Hamano1-18/+21
* ef/cherry-abbrev: ls: remove redundant logic cherry: support --abbrev option
2010-03-29Merge branch 'maint'Libravatar Junio C Hamano1-1/+8
* maint: format-patch: Squelch 'fatal: Not a range." error
2010-03-24Merge branch 'tr/notes-display'Libravatar Junio C Hamano1-0/+5
* tr/notes-display: git-notes(1): add a section about the meaning of history notes: track whether notes_trees were changed at all notes: add shorthand --ref to override GIT_NOTES_REF commit --amend: copy notes to the new commit rebase: support automatic notes copying notes: implement helpers needed for note copying during rewrite notes: implement 'git notes copy --stdin' rebase -i: invoke post-rewrite hook rebase: invoke post-rewrite hook commit --amend: invoke post-rewrite hook Documentation: document post-rewrite hook Support showing notes from more than one notes tree test-lib: unset GIT_NOTES_REF to stop it from influencing tests Conflicts: git-am.sh refs.c
2010-03-24Merge branch 'pb/log-first-parent-p-m'Libravatar Junio C Hamano1-11/+38
* pb/log-first-parent-p-m: show --first-parent/-m: do not default to --cc show -c: show patch text revision: introduce setup_revision_opt t4013: add tests for log -p -m --first-parent git log -p -m: document -m and honor --first-parent
2010-03-21cherry: support --abbrev optionLibravatar Erik Faye-Lund1-18/+21
Switch to parse-options API while we're at it. Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-15Merge branch 'sd/format-patch-to'Libravatar Junio C Hamano1-39/+61
* sd/format-patch-to: send-email: add --no-cc, --no-to, and --no-bcc format-patch: add --no-cc, --no-to, and --no-add-headers format-patch: use a string_list for headers Add 'git format-patch --to=' option and 'format.to' configuration variable.
2010-02-22Move 'builtin-*' into a 'builtin/' subdirectoryLibravatar Linus Torvalds1-0/+1352
This shrinks the top-level directory a bit, and makes it much more pleasant to use auto-completion on the thing. Instead of [torvalds@nehalem git]$ em buil<tab> Display all 180 possibilities? (y or n) [torvalds@nehalem git]$ em builtin-sh builtin-shortlog.c builtin-show-branch.c builtin-show-ref.c builtin-shortlog.o builtin-show-branch.o builtin-show-ref.o [torvalds@nehalem git]$ em builtin-shor<tab> builtin-shortlog.c builtin-shortlog.o [torvalds@nehalem git]$ em builtin-shortlog.c you get [torvalds@nehalem git]$ em buil<tab> [type] builtin/ builtin.h [torvalds@nehalem git]$ em builtin [auto-completes to] [torvalds@nehalem git]$ em builtin/sh<tab> [type] shortlog.c shortlog.o show-branch.c show-branch.o show-ref.c show-ref.o [torvalds@nehalem git]$ em builtin/sho [auto-completes to] [torvalds@nehalem git]$ em builtin/shor<tab> [type] shortlog.c shortlog.o [torvalds@nehalem git]$ em builtin/shortlog.c which doesn't seem all that different, but not having that annoying break in "Display all 180 possibilities?" is quite a relief. NOTE! If you do this in a clean tree (no object files etc), or using an editor that has auto-completion rules that ignores '*.o' files, you won't see that annoying 'Display all 180 possibilities?' message - it will just show the choices instead. I think bash has some cut-off around 100 choices or something. So the reason I see this is that I'm using an odd editory, and thus don't have the rules to cut down on auto-completion. But you can simulate that by using 'ls' instead, or something similar. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>