summaryrefslogtreecommitdiff
path: root/log-tree.c
AgeCommit message (Collapse)AuthorFilesLines
2011-08-28Merge branch 'nd/decorate-grafts'Libravatar Junio C Hamano1-4/+32
* nd/decorate-grafts: log: Do not decorate replacements with --no-replace-objects log: decorate "replaced" on to replaced commits log: decorate grafted commits with "grafted" Move write_shallow_commits to fetch-pack.c Add for_each_commit_graft() to iterate all grafts decoration: do not mis-decorate refs with same prefix
2011-08-25log: Do not decorate replacements with --no-replace-objectsLibravatar Michael J Gruber1-0/+2
5267d29 (log: decorate "replaced" on to replaced commits, 2011-08-19) introduced textual decorations for replaced commits, based on the detection of refs/replace. Make it so that additionally the use of --no-replace-objects is detected: I.e. replaced commits are only decorated as replaced when they are actually replaced. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-19color: delay auto-color decision until point of useLibravatar Jeff King1-1/+1
When we read a color value either from a config file or from the command line, we use git_config_colorbool to convert it from the tristate always/never/auto into a single yes/no boolean value. This has some timing implications with respect to starting a pager. If we start (or decide not to start) the pager before checking the colorbool, everything is fine. Either isatty(1) will give us the right information, or we will properly check for pager_in_use(). However, if we decide to start a pager after we have checked the colorbool, things are not so simple. If stdout is a tty, then we will have already decided to use color. However, the user may also have configured color.pager not to use color with the pager. In this case, we need to actually turn off color. Unfortunately, the pager code has no idea which color variables were turned on (and there are many of them throughout the code, and they may even have been manipulated after the colorbool selection by something like "--color" on the command line). This bug can be seen any time a pager is started after config and command line options are checked. This has affected "git diff" since 89d07f7 (diff: don't run pager if user asked for a diff style exit code, 2007-08-12). It has also affect the log family since 1fda91b (Fix 'git log' early pager startup error case, 2010-08-24). This patch splits the notion of parsing a colorbool and actually checking the configuration. The "use_color" variables now have an additional possible value, GIT_COLOR_AUTO. Users of the variable should use the new "want_color()" wrapper, which will lazily determine and cache the auto-color decision. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-19log: decorate "replaced" on to replaced commitsLibravatar Nguyễn Thái Ngọc Duy1-1/+15
Old code also decorates "new" commits with "refs/replace/SHA1". This is now gone, but I guess no one will miss it. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-18diff: refactor COLOR_DIFF from a flag into an intLibravatar Jeff King1-2/+2
This lets us store more than just a bit flag for whether we want color; we can also store whether we want automatic colors. This can be useful for making the automatic-color decision closer to the point of use. This mostly just involves replacing DIFF_OPT_* calls with manipulations of the flag. The biggest exception is that calls to DIFF_OPT_TST must check for "o->use_color > 0", which lets an "unknown" value (i.e., the default) stay at "no color". In the previous code, a value of "-1" was not propagated at all. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-18log: decorate grafted commits with "grafted"Libravatar Nguyễn Thái Ngọc Duy1-0/+12
In shallow repositories, this may help detect whether a branch ends, or it is deeper than current depth. It also show graft points that extend a branch. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-18decoration: do not mis-decorate refs with same prefixLibravatar Nguyễn Thái Ngọc Duy1-3/+3
We definitely do not want to decorate refs/headsandtails the same as refs/heads/*, for example. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-31Merge branch 'jk/format-patch-am'Libravatar Junio C Hamano1-1/+3
* jk/format-patch-am: format-patch: preserve subject newlines with -k clean up calling conventions for pretty.c functions pretty: add pp_commit_easy function for simple callers mailinfo: always clean up rfc822 header folding t: test subject handling in format-patch / am pipeline Conflicts: builtin/branch.c builtin/log.c commit.h
2011-05-30format-patch: make zero-length subject prefixes prettierLibravatar Jeff King1-1/+2
If you give a zero-length subject prefix to format-patch (e.g., "format-patch --subject-prefix="), we will print the ugly: Subject: [ 1/2] your subject here because we always insert a space between the prefix and numbering. Requiring the user to provide the space in their prefix would be more flexible, but would break existing usage. This patch provides a DWIM and suppresses the space for zero-length prefixes, under the assumption that nobody actually wants "[ 1/2]". Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-26format-patch: preserve subject newlines with -kLibravatar Jeff King1-0/+1
In older versions of git, we used rfc822 header folding to indicate that the original subject line had multiple lines in it. But since a1f6baa (format-patch: wrap long header lines, 2011-02-23), we now use header folding whenever there is a long line. This means that "git am" cannot trust header folding as a sign from format-patch that newlines should be preserved. Instead, format-patch needs to signal more explicitly that the newlines are significant. This patch does so by rfc2047-encoding the newlines in the subject line. No changes are needed on the "git am" end; it already decodes the newlines properly. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-26clean up calling conventions for pretty.c functionsLibravatar Jeff King1-1/+2
We have a pretty_print_context representing the parameters for a pretty-print session, but we did not use it uniformly. As a result, functions kept growing more and more arguments. Let's clean this up in a few ways: 1. All pretty-print pp_* functions now take a context. This lets us reduce the number of arguments to these functions, since we were just passing around the context values separately. 2. The context argument now has a cmit_fmt field, which was passed around separately. That's one less argument per function. 3. The context argument always comes first, which makes calling a little more uniform. This drops lines from some callers, and adds lines in a few places (because we need an extra line to set the context's fmt field). Overall, we don't save many lines, but the lines that are there are a lot simpler and more readable. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-10git-log: put space after commit markLibravatar Michael J Gruber1-2/+2
Currently, commit marks (left, right, boundary, cherry) are output right before the commit sha1, which makes it difficult to copy sha1s. Sample output for "git log --oneline --cherry": =049c269 t6007: test rev-list --cherry Change this to = 049c269 t6007: test rev-list --cherry which matches exactly the current output of "git log --graph". Leave "git rev-list" output as is (no space) so that they do not break. Adjust "git-svn" which uses "git log --pretty=raw --boundary". Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-09rev-list/log: factor out revision mark generationLibravatar Michael J Gruber1-24/+4
Currently, we have identical code for generating revision marks ('<', '>', '-') in 5 places. Factor out the code to a single function get_revision_mark() for easier maintenance and extensibility. Note that the check for !!revs in graph.c (which gets removed effectively by this patch) is superfluous. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-24Allow customizable commit decorations colorsLibravatar Nazri Ramliy1-0/+36
Signed-off-by: Nazri Ramliy <ayiehere@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-20log --decorate: Colorize commit decorationsLibravatar Nazri Ramliy1-1/+33
This makes the decorations stand out more and easier to distinguish and spot because they are colored differently depending on their type. Signed-off-by: Nazri Ramliy <ayiehere@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-20log-tree.c: Use struct name_decoration's type for classifying decorationLibravatar Nazri Ramliy1-8/+32
The "tag: " prefix is no longer prepended to the name of the decoration. It is now printed conditionally by show_decorations if the decoration type is DECORATION_REF_TAG. Signed-off-by: Nazri Ramliy <ayiehere@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-05-31Output the graph columns at the end of the commit messageLibravatar Bo Yang1-0/+6
There is an empty line between the commit message and the diff output. Add the graph columns as prefix of this line. Signed-off-by: Bo Yang <struggleyb.nku@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-12git log -p -m: document -m and honor --first-parentLibravatar Petr Baudis1-0/+10
git log -p -m is used to show one merge entry per parent, with an appropriate diff; this can be useful when examining histories where full set of changes introduced by a merged branch is interesting, not only the conflicts. This patch properly documents the -m switch, which has so far been mentioned only as a fairly special diff-tree flag. It also makes the code show full patch entry only for the first parent when --first-parent is used. Thus: git log -p -m --first-parent will show the history from the "main branch perspective", while also including full diff of changes introduced by other merged in branches. Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-20Fix "log" family not to be too agressive about showing notesLibravatar Junio C Hamano1-0/+1
Giving "Notes" information in the default output format of "log" and "show" is a sensible progress (the user has asked for it by having the notes), but for some commands (e.g. "format-patch") spewing notes into the formatted commit log message without being asked is too aggressive. Enable notes output only for "log", "show", "whatchanged" by default and only when the user didn't ask any specific --pretty/--format from the command line; users can explicitly override this default with --show-notes and --no-notes option. Parts of tests are taken from Jeff King's fix. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-19Introduce new pretty formats %g[sdD] for reflog informationLibravatar Thomas Rast1-0/+1
Add three new --pretty=format escapes: %gD long reflog descriptor (e.g. refs/stash@{0}) %gd short reflog descriptor (e.g. stash@{0}) %gs reflog message This is achieved by passing down the reflog info, if any, inside the pretty_print_context struct. We use the newly refactored get_reflog_selector(), and give it some extra functionality to extract a shortened ref. The shortening is cached inside the commit_reflogs struct; the only allocation of it happens in read_complete_reflog(), where it is initialised to 0. Also add another helper get_reflog_message() for the message extraction. Note that the --format="%h %gD: %gs" tests may not work in real repositories, as the --pretty formatter doesn't know to leave away the ": " on the last commit in an incomplete (because git-gc removed the old part) reflog. This equivalence is nevertheless the main goal of this patch. Thanks to Jeff King for reviews, the %gd testcase and documentation. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-19Refactor pretty_print_commit arguments into a structLibravatar Thomas Rast1-11/+13
pretty_print_commit() has a bunch of rarely-used arguments, and introducing more of them requires yet another update of all the call sites. Refactor most of them into a struct to make future extensions easier. The ones that stay "plain" arguments were chosen on the grounds that all callers put real arguments there, whereas some callers have 0/NULL for all arguments that were factored into the struct. We declare the struct 'const' to ensure none of the callers are bitten by the changed (no longer call-by-value) semantics. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-12Let --decorate show HEAD positionLibravatar Thomas Rast1-0/+1
'git log --graph --oneline --decorate --all' is a useful way to get a general overview of the repository state, similar to 'gitk --all'. Let it indicate the position of HEAD by loading that ref too, so that the --decorate code can see it. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-29improve reflog date/number heuristicLibravatar Jeff King1-1/+3
When we show a reflog, we have two ways of naming the entry: by sequence number (e.g., HEAD@{0}) or by date (e.g., HEAD@{10 minutes ago}). There is no explicit option to set one or the other, but we guess based on whether or not the user has provided us with a date format, showing them the date version if they have done so, and the sequence number otherwise. This usually made sense if the use did something like "git log -g --date=relative". However, it didn't make much sense if the user set the date format using the log.date config variable; in that case, all of their reflogs would end up as dates. This patch records the source of the date format and only triggers the date-based view if --date= was given on the command line. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2009-08-18git-log: allow --decorate[=short|full]Libravatar Lars Hjemli1-3/+4
Commit de435ac0 changed the behavior of --decorate from printing the full ref (e.g., "refs/heads/master") to a shorter, more human-readable version (e.g., just "master"). While this is nice for human readers, external tools using the output from "git log" may prefer the full version. This patch introduces an extension to --decorate to allow the caller to specify either the short or the full versions. Signed-off-by: Lars Hjemli <hjemli@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-10Expose the has_non_ascii() functionLibravatar Johannes Schindelin1-12/+0
This function is useful outside of log-tree.c, too. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-01log-tree: fix confusing commentLibravatar Jeff King1-1/+2
This comment mentions the case where use_terminator is set, but this case is not handled at all by this chunk of code. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-05-13Prettify log decorations even moreLibravatar Felipe Contreras1-0/+1
"tag: v1.6.2.5" looks much better than "tag: refs/tags/v1.6.2.5". Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-27log-tree: fix patch filename computation in "git format-patch"Libravatar Christian Couder1-10/+5
When using "git format-patch", "get_patch_filename" in "log-tree.c" calls "strbuf_splice" that could die with the following message: "`pos + len' is too far after the end of the buffer" if you have: buf->len < start_len + FORMAT_PATCH_NAME_MAX but: buf->len + suffix_len > start_len + FORMAT_PATCH_NAME_MAX This patch tries to get rid of that bug. [jc: w/ simplified logic] Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-22format-patch: --attach/inline uses filename instead of SHA1Libravatar Stephen Boyd1-7/+11
Currently when format-patch is used with --attach or --inline the patch attachment has the SHA1 of the commit for its filename. This replaces the SHA1 with the filename used by format-patch when outputting to files. Fix tests relying on the SHA1 output and add a test showing how the --suffix option affects the attachment filename output. Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-22format-patch: move get_patch_filename() into log-treeLibravatar Stephen Boyd1-0/+22
Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-11Merge branch 'tr/format-patch-thread'Libravatar Junio C Hamano1-3/+8
* tr/format-patch-thread: format-patch: support deep threading format-patch: thread as reply to cover letter even with in-reply-to format-patch: track several references format-patch: threading test reactivation Conflicts: builtin-log.c
2009-03-07Move local variables to narrower scopesLibravatar Benjamin Kramer1-3/+3
These weren't used outside and can be safely moved Signed-off-by: Benjamin Kramer <benny.kra@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-21format-patch: track several referencesLibravatar Thomas Rast1-3/+8
Currently, format-patch can only track a single reference (the In-Reply-To:) for each mail. To ensure proper threading, we should list all known references for every mail. Change the rev_info.ref_message_id field to a string_list, so that we can append references at will, and change the output formatting routines to print all of them in the References: header. The last entry in the list is implicitly assumed to be the In-Reply-To:, which gives output consistent with RFC 2822: The "References:" field will contain the contents of the parent's "References:" field (if any) followed by the contents of the parent's "Message-ID:" field (if any). Note that this is just preparatory work; nothing uses it yet, so all "References:" fields in the output are still only one deep. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-13log: do not print ellipses with --abbrev-commitLibravatar Thomas Rast1-4/+4
'git log --abbrev-commit' added an ellipsis to all commit names that were abbreviated. This was particularly annoying if you wanted to cut&paste the sha1 from the terminal, since selecting by word would pick up '...' too. So use find_unique_abbrev() instead of diff_unique_abbrev() in all log-related commit sha1 printing routines, and also change the formatting of the 'Merge: parent1 parent2' line output via pretty_print_commit(). Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-11-16Fix machine-parseability of 'git log --source'Libravatar Linus Torvalds1-1/+1
The space between the commit and the source attribute is not easily machine-parseable: if we combine --source with --parents and give a SHA1 as a starting point, it's unnecessarily hard to see where the list of parents ends and the source decoration begins. Example: git show --parents --source $(git rev-list HEAD) which is admittedly contrived, but can easily happen in scripting. So use a <tab> instead of a space as the source separator. The other decorations didn't have this issue, because they were surrounded by parenthesis, so it's obvious that they aren't parent SHA1's. It so happens that _visually_ this makes no difference for "git log --source", since "commit <40-char SHA1>" is 47 characters, so both a space and a <tab> will end up showing as a single commit. Of course, with '--pretty=oneline' or '--parents' or '--abbrev-commit' you'll see the difference. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-11-04Make '--decorate' set an explicit 'show_decorations' flagLibravatar Linus Torvalds1-0/+2
We will want to add decorations without necessarily showing them, so add an explicit revisions info flag as to whether we're showing decorations or not. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-11-04Add a 'source' decorator for commitsLibravatar Linus Torvalds1-3/+5
We already support decorating commits by tags or branches that point to them, but especially when we are looking at multiple branches together, we sometimes want to see _how_ we reached a particular commit. We can abuse the '->util' field in the commit to keep track of that as we walk the commit lists, and get a reasonably useful view into which branch or tag first reaches that commit. Of course, if the commit is reachable through multiple sources (which is common), our particular choice of "first" reachable is entirely random and depends on the particular path we happened to follow. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-10-12Replace calls to strbuf_init(&foo, 0) with STRBUF_INIT initializerLibravatar Brandon Casey1-2/+1
Many call sites use strbuf_init(&foo, 0) to initialize local strbuf variable "foo" which has not been accessed since its declaration. These can be replaced with a static initialization using the STRBUF_INIT macro which is just as readable, saves a function call, and takes up fewer lines. Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-09-04move load_ref_decorations() to log-tree.c and export itLibravatar René Scharfe1-0/+36
log-tree.c is the ideal place for load_ref_decorations() and its helper functions to live in, because the variable name_decoration they're operating on is already located there, so move them thither. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-17Teach git log --exit-code to return an appropriate exit codeLibravatar Peter Valdemar Mørch1-1/+1
Signed-off-by: Peter Valdemar Mørch <peter@morch.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-29format-patch: Produce better output with --inline or --attachLibravatar Kevin Ballard1-1/+1
This patch makes two small changes to improve the output of --inline and --attach. The first is to write a newline preceding the boundary. This is needed because MIME defines the encapsulation boundary as including the preceding CRLF (or in this case, just LF), so we should be writing one. Without this, the last newline in the pre-diff content is consumed instead. The second change is to always write the line termination character (default: newline) even when using --inline or --attach. This is simply to improve the aesthetics of the resulting message. When using --inline an email client should render the resulting message identically to the non-inline version. And when using --attach this adds a blank line preceding the attachment in the email, which is visually attractive. Signed-off-by: Kevin Ballard <kevin@sb.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-25log --graph --left-right: show left/right information in place of '*'Libravatar Adam Simpkins1-18/+23
With the --graph option, the graph already outputs 'o' instead of '*' for boundary commits. Make it emit '<' or '>' when --left-right is specified. (This change also disables the '^' prefix for UNINTERESTING commits. The graph code currently doesn't print anything special for these commits, since it assumes no UNINTERESTING, non-BOUNDARY commits are displayed. This is potentially a bug if UNINTERESTING non-BOUNDARY commits can actually be displayed via some code path.) [jc: squashed the left-right change from Dscho and Adam's fixup into one] Signed-off-by: Adam Simpkins <adam@adamsimpkins.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-05log and rev-list: add --graph optionLibravatar Adam Simpkins1-7/+69
This new option causes a text-based representation of the history to be printed to the left of the normal output. Signed-off-by: Adam Simpkins <adam@adamsimpkins.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-05revision API: split parent rewriting and parent printing optionsLibravatar Adam Simpkins1-2/+2
This change allows parent rewriting to be performed without causing the log and rev-list commands to print the parents. Signed-off-by: Adam Simpkins <adam@adamsimpkins.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-03log: print log entry terminator even if the message is emptyLibravatar Adam Simpkins1-4/+3
This eliminates a special case in the show_log() function, to help simplify the terminator semantics. Now show_log() always prints a newline after the log entry when use_terminator is set, even if the log message is empty. This change should only affect the --pretty=tformat output, since that was the only way to trigger this special case. Signed-off-by: Adam Simpkins <adam@adamsimpkins.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-03Remove dead code: show_log() sep argument and diff_options.msg_sepLibravatar Adam Simpkins1-18/+9
These variables were made unnecessary by commit 3969cf7db1a13a78f3b7a36d8c1084bbe0a53459. Signed-off-by: Adam Simpkins <adam@adamsimpkins.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-04-10log: teach "terminator" vs "separator" mode to "--pretty=format"Libravatar Junio C Hamano1-2/+2
This attached patch introduces a single bit "use_terminator" in "struct rev_info", which is normally false (i.e. most formats use separator semantics) but by flipping it to true, you can ask for terminator semantics just like oneline format does. The function get_commit_format(), which is what parses "--pretty=" option, now takes a pointer to "struct rev_info" and updates its commit_format and use_terminator fields. It used to return the value of type "enum cmit_fmt", but all the callers assigned it to rev->commit_format. There are only two cases the code turns use_terminator on. Obviously, the traditional oneline format (--pretty=oneline) is one of them, and the new case is --pretty=tformat:... that acts like --pretty=format:... but flips the bit on. With this, "--pretty=tformat:%H %s" acts like --pretty=oneline. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-23pretty.c: add %x00 format specifier.Libravatar Govind Salinas1-2/+4
This adds a %xXX format which inserts two hexdigits after %x as a byte value in the resulting string. This can be used to add a NUL byte or any other byte that can make machine parsing easier. It is also necessary to use fwrite to print out the data since printf will terminate if you feed it a NUL. Signed-off-by: Govind Salinas <blix@sophiasuchtig.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-15Merge branch 'maint'Libravatar Junio C Hamano1-3/+12
* maint: format-patch: generate MIME header as needed even when there is format.header
2008-03-15format-patch: generate MIME header as needed even when there is format.headerLibravatar Junio C Hamano1-1/+6
Earlier, the callchain from pretty_print_commit() down to pp_title_line() had an unwarranted assumption that the presense of "after_subject" parameter, means the caller has already output MIME headers for attachments. The parameter's primary purpose is to give extra header lines the caller wants to place after pp_title_line() generates the "Subject: " line. This assumption does not hold when the user used the format.header configuration variable to pass extra headers, and caused a message with non-ASCII character to lack proper MIME headers (e.g. 8-bit CTE header). The earlier logic also failed to suppress duplicated MIME headers when "format-patch -s --attach" is asked for and the signer's name demanded 8-bit clean transport. This patch fixes the logic by introducing a separate need_8bit_cte parameter passed down the callchain. This can have one of these values: -1 : we've already done MIME crap and we do not want to add extra header to say this is 8bit in pp_title_line(); 0 : we haven't done MIME and we have not seen anything that is 8bit yet; 1 : we haven't done MIME and we have seen something that is 8bit; pp_title_line() must add MIME header. It adds two tests by Jeff King who independently diagnosed this issue. Signed-off-by: Junio C Hamano <gitster@pobox.com>