aboutsummaryrefslogtreecommitdiff
path: root/log-tree.c
Commit message (Collapse)AuthorAge
* Merge branch 'js/log-show-children'Junio C Hamano2011-10-18
|\ | | | | | | | | * js/log-show-children: log --children
| * log --childrenJay Soffian2011-10-04
| | | | | | | | | | | | | | | | | | Teach git-log to support --children, which was added by f35f5603f4 to the revision machinery, and by 72276a3ecb to rev-list, but was never added to git-log. Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'nd/decorate-grafts'Junio C Hamano2011-08-28
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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
| * | log: Do not decorate replacements with --no-replace-objectsMichael J Gruber2011-08-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | log: decorate "replaced" on to replaced commitsNguyễn Thái Ngọc Duy2011-08-19
| | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | log: decorate grafted commits with "grafted"Nguyễn Thái Ngọc Duy2011-08-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | decoration: do not mis-decorate refs with same prefixNguyễn Thái Ngọc Duy2011-08-18
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | color: delay auto-color decision until point of useJeff King2011-08-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | diff: refactor COLOR_DIFF from a flag into an intJeff King2011-08-18
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge branch 'jk/format-patch-am'Junio C Hamano2011-05-31
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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
| * | format-patch: preserve subject newlines with -kJeff King2011-05-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | clean up calling conventions for pretty.c functionsJeff King2011-05-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | format-patch: make zero-length subject prefixes prettierJeff King2011-05-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | git-log: put space after commit markMichael J Gruber2011-03-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | rev-list/log: factor out revision mark generationMichael J Gruber2011-03-09
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Allow customizable commit decorations colorsNazri Ramliy2010-06-24
| | | | | | | | | | Signed-off-by: Nazri Ramliy <ayiehere@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | log --decorate: Colorize commit decorationsNazri Ramliy2010-06-20
| | | | | | | | | | | | | | | | 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>
* | log-tree.c: Use struct name_decoration's type for classifying decorationNazri Ramliy2010-06-20
| | | | | | | | | | | | | | | | | | 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>
* | Output the graph columns at the end of the commit messageBo Yang2010-05-31
| | | | | | | | | | | | | | | | 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>
* | git log -p -m: document -m and honor --first-parentPetr Baudis2010-02-12
|/ | | | | | | | | | | | | | | | | | | | | 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>
* Fix "log" family not to be too agressive about showing notesJunio C Hamano2010-01-20
| | | | | | | | | | | | | | | | | 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>
* Introduce new pretty formats %g[sdD] for reflog informationThomas Rast2009-10-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Refactor pretty_print_commit arguments into a structThomas Rast2009-10-19
| | | | | | | | | | | | | | | | | 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>
* Let --decorate show HEAD positionThomas Rast2009-10-12
| | | | | | | | | | '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>
* improve reflog date/number heuristicJeff King2009-09-29
| | | | | | | | | | | | | | | | | | | | | | | 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>
* git-log: allow --decorate[=short|full]Lars Hjemli2009-08-18
| | | | | | | | | | | | | | | 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>
* Expose the has_non_ascii() functionJohannes Schindelin2009-08-10
| | | | | | | 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>
* log-tree: fix confusing commentJeff King2009-07-01
| | | | | | | | 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>
* Prettify log decorations even moreFelipe Contreras2009-05-13
| | | | | | | | "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>
* log-tree: fix patch filename computation in "git format-patch"Christian Couder2009-03-27
| | | | | | | | | | | | | | | | | | | | | | | 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>
* format-patch: --attach/inline uses filename instead of SHA1Stephen Boyd2009-03-22
| | | | | | | | | | | | | 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>
* format-patch: move get_patch_filename() into log-treeStephen Boyd2009-03-22
| | | | | Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'tr/format-patch-thread'Junio C Hamano2009-03-11
|\ | | | | | | | | | | | | | | | | | | | | * 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
| * format-patch: track several referencesThomas Rast2009-02-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Move local variables to narrower scopesBenjamin Kramer2009-03-07
|/ | | | | | | 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>
* log: do not print ellipses with --abbrev-commitThomas Rast2009-02-13
| | | | | | | | | | | | | | | '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>
* Fix machine-parseability of 'git log --source'Linus Torvalds2008-11-16
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Make '--decorate' set an explicit 'show_decorations' flagLinus Torvalds2008-11-04
| | | | | | | | | 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>
* Add a 'source' decorator for commitsLinus Torvalds2008-11-04
| | | | | | | | | | | | | | | | | 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>
* Replace calls to strbuf_init(&foo, 0) with STRBUF_INIT initializerBrandon Casey2008-10-12
| | | | | | | | | | | 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>
* move load_ref_decorations() to log-tree.c and export itRené Scharfe2008-09-04
| | | | | | | | | 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>
* Teach git log --exit-code to return an appropriate exit codePeter Valdemar Mørch2008-08-17
| | | | | Signed-off-by: Peter Valdemar Mørch <peter@morch.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* format-patch: Produce better output with --inline or --attachKevin Ballard2008-07-29
| | | | | | | | | | | | | | | | | | | | 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>
* log --graph --left-right: show left/right information in place of '*'Adam Simpkins2008-05-25
| | | | | | | | | | | | | | | | | 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>
* log and rev-list: add --graph optionAdam Simpkins2008-05-05
| | | | | | | | 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>
* revision API: split parent rewriting and parent printing optionsAdam Simpkins2008-05-05
| | | | | | | | 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>
* log: print log entry terminator even if the message is emptyAdam Simpkins2008-05-03
| | | | | | | | | | | | | 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>
* Remove dead code: show_log() sep argument and diff_options.msg_sepAdam Simpkins2008-05-03
| | | | | | | | 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>
* log: teach "terminator" vs "separator" mode to "--pretty=format"Junio C Hamano2008-04-10
| | | | | | | | | | | | | | | | | | | | | 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>
* pretty.c: add %x00 format specifier.Govind Salinas2008-03-23
| | | | | | | | | | | 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>
generated by cgit v1.2.1 (git 2.18.0) at 2024-11-15 10:29:52 +0000