summaryrefslogtreecommitdiff
path: root/graph.c
AgeCommit message (Collapse)AuthorFilesLines
2016-08-31graph: add support for --line-prefix on all graph-aware outputLibravatar Jacob Keller1-34/+64
Add an extension to git-diff and git-log (and any other graph-aware displayable output) such that "--line-prefix=<string>" will print the additional line-prefix on every line of output. To make this work, we have to fix a few bugs in the graph API that force graph_show_commit_msg to be used only when you have a valid graph. Additionally, we extend the default_diff_output_prefix handler to work even when no graph is enabled. This is somewhat of a hack on top of the graph API, but I think it should be acceptable here. This will be used by a future extension of submodule display which displays the submodule diff as the actual diff between the pre and post commit in the submodule project. Add some tests for both git-log and git-diff to ensure that the prefix is honored correctly. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-31diff.c: remove output_prefix_length fieldLibravatar Junio C Hamano1-2/+0
"diff/log --stat" has a logic that determines the display columns available for the diffstat part of the output and apportions it for pathnames and diffstat graph automatically. 5e71a84a (Add output_prefix_length to diff_options, 2012-04-16) added the output_prefix_length field to diff_options structure to allow this logic to subtract the display columns used for the history graph part from the total "terminal width"; this matters when the "git log --graph -p" option is in use. The field must be set to the number of display columns needed to show the output from the output_prefix() callback, which is error prone. As there is only one user of the field, and the user has the actual value of the prefix string, let's get rid of the field and have the user count the display width itself. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-19Merge branch 'js/log-to-diffopt-file'Libravatar Junio C Hamano1-13/+17
The commands in the "log/diff" family have had an FILE* pointer in the data structure they pass around for a long time, but some codepaths used to always write to the standard output. As a preparatory step to make "git format-patch" available to the internal callers, these codepaths have been updated to consistently write into that FILE* instead. * js/log-to-diffopt-file: mingw: fix the shortlog --output=<file> test diff: do not color output when --color=auto and --output=<file> is given t4211: ensure that log respects --output=<file> shortlog: respect the --output=<file> setting format-patch: use stdout directly format-patch: avoid freopen() format-patch: explicitly switch off color when writing to files shortlog: support outputting to streams other than stdout graph: respect the diffopt.file setting line-log: respect diffopt's configured output file stream log-tree: respect diffopt's configured output file stream log: prepare log/log-tree to reuse the diffopt.close_file attribute
2016-06-24graph: respect the diffopt.file settingLibravatar Johannes Schindelin1-13/+17
When the caller overrides diffopt.file (which defaults to stdout), the diff machinery already redirects its output, and the graph display should also write to that file. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-16pretty: pass graph width to pretty formatting for use in '%>|(N)'Libravatar Josef Kufner1-0/+7
Pass graph width to pretty formatting, to make N in '%>|(N)' include columns consumed by graph rendered when --graph option is in use. For example, in the output of git log --all --graph --pretty='format: [%>|(20)%h] %ar%d' this change will make all commit hashes align at 20th column from the edge of the terminal, not from the edge of the graph. Signed-off-by: Josef Kufner <josef@kufner.cz> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22convert trivial cases to ALLOC_ARRAYLibravatar Jeff King1-6/+4
Each of these cases can be converted to use ALLOC_ARRAY or REALLOC_ARRAY, which has two advantages: 1. It automatically checks the array-size multiplication for overflow. 2. It always uses sizeof(*array) for the element-size, so that it can never go out of sync with the declared type of the array. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-29Merge branch 'rs/graph-simplify'Libravatar Junio C Hamano1-13/+4
* rs/graph-simplify: graph: simplify graph_padding_line()
2014-09-26Merge branch 'rs/realloc-array'Libravatar Junio C Hamano1-10/+4
Code cleanup. * rs/realloc-array: use REALLOC_ARRAY for changing the allocation size of arrays add macro REALLOC_ARRAY
2014-09-22graph: simplify graph_padding_line()Libravatar René Scharfe1-13/+4
Deduplicate code common to both branches of if statements. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-18use REALLOC_ARRAY for changing the allocation size of arraysLibravatar René Scharfe1-10/+4
Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-08strbuf: use strbuf_addchars() for adding a char multiple timesLibravatar René Scharfe1-3/+2
Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-18graph: fix coloring around octopus mergesLibravatar Hemmo Nieminen1-2/+2
When drawing the graph of an octopus merge, we draw a horizontal line from parents 3 and above into the asterisk representing the commit. The sections of this line should be colored to match the graph lines coming in from above. However, if the commit is not in the left-most column we do not take into account the columns to the left of the commit when calculating these colors. Fix this by adding the appropriate offset to the column index used for calculating the color. Signed-off-by: Hemmo Nieminen <hemmo.nieminen@iki.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-03Revert "graph.c: mark private file-scope symbols as static"Libravatar John Keeping1-30/+2
This reverts commit ba35480439d05b8f6cca50527072194fe3278bbb. CGit uses these symbols to output the correct HTML around graph elements. Making these symbols private means that CGit cannot be updated to use Git 1.8.0 or newer, so let's not do that. On top of the revert, also add comments so that we avoid reintroducing this problem in the future and suggest to those modifying this API that they might want to discuss it with the CGit developers. Signed-off-by: John Keeping <john@keeping.me.uk> Acked-by: Jason A. Donenfeld <Jason@zx2c4.com> Acked-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-07graph: output padding for merge subsequent parentsLibravatar John Keeping1-0/+10
When showing merges in git-log, the same commit is shown once for each parent. Combined with "--graph" this results in graph_show_commit() being called once for each parent without graph_update() being called. Currently graph_show_commit() does not print anything on subsequent invocations for the same commit (this was changed by commit 656197a - "graph.c: infinite loop in git whatchanged --graph -m" from the previous behaviour of looping infinitely). Change this so that if the graph code believes it has already shown the commit it prints a single padding line. Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-14Merge branch 'mk/maint-graph-infinity-loop' into maintLibravatar Junio C Hamano1-1/+1
* mk/maint-graph-infinity-loop: graph.c: infinite loop in git whatchanged --graph -m
2012-09-25graph.c: infinite loop in git whatchanged --graph -mLibravatar Michał Kiedrowicz1-1/+1
Running "whatchanged --graph -m" on a simple two-head merges can fall into infinite loop. Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-15graph.c: mark private file-scope symbols as staticLibravatar Junio C Hamano1-2/+30
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-16Add output_prefix_length to diff_optionsLibravatar Lucian Poston1-0/+3
Add output_prefix_length to diff_options. Initialize the value to 0 and only set it when graph.c:diff_output_prefix_callback() is called. Signed-off-by: Lucian Poston <lucian.poston@gmail.com> 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-18diff: refactor COLOR_DIFF from a flag into an intLibravatar Jeff King1-1/+1
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-04-04Share color list between graph and show-branchLibravatar Dan McGee1-22/+1
This also adds the new colors to show-branch that were added a while back for graph output. Signed-off-by: Dan McGee <dpmcgee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-09rev-list/log: factor out revision mark generationLibravatar Michael J Gruber1-15/+2
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-08-22Merge branch 'maint'Libravatar Junio C Hamano1-1/+1
* maint: Typos in code comments, an error message, documentation
2010-08-22Typos in code comments, an error message, documentationLibravatar Ralf Wildenhues1-1/+1
Signed-off-by: Ralf Wildenhues <Ralf.Wildenhues@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-13Enable custom schemes for column colors in the graph APILibravatar Johan Herland1-11/+26
Currently, the graph code is hardcoded to use ANSI color escapes for coloring the column characters in the generated graphs. This patch allows a custom scheme of colors to be set at runtime, allowing different types of color escapes to be used. A new function - graph_set_column_colors() - is added to the graph.h API, which allows a custom column_colors array (and column_colors_max value) to replace the builtin ANSI array (and _max value). The new function - if used - must be called before graph_init() is called. Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-13Make graph_next_line() available in the graph.h APILibravatar Johan Herland1-12/+1
In order to successfully use the graph API from a context other than the stdout/command-line scenario (where the graph_show_* functions are suitable), we need direct access to graph_next_line(), to drive the graph drawing process. Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-05-31graph.c: register a callback for graph outputLibravatar Bo Yang1-0/+19
It will look better if the 'git log --graph' print the graph pading lines before the diff output just like what it does for commit message. And this patch leverage the new diff prefix callback function to achieve this. Signed-off-by: Bo Yang <struggleyb.nku@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-07Add GIT_COLOR_BOLD_* and GIT_COLOR_BG_*Libravatar Mark Lodato1-6/+6
Add GIT_COLOR_BOLD_* macros to set both bold and the color in one sequence. This saves two characters of output ("ESC [ m", minus ";") and makes the code more readable. Add the remaining GIT_COLOR_BG_* macros to make the list complete. The white and black colors are not included since they look bad on most terminals. Signed-off-by: Mark Lodato <lodatom@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-27Merge branch 'as/maint-graph-interesting-fix'Libravatar Junio C Hamano1-2/+3
* as/maint-graph-interesting-fix: Add tests for rev-list --graph with options that simplify history graph API: fix bug in graph_is_interesting()
2009-08-21graph API: fix bug in graph_is_interesting()Libravatar Adam Simpkins1-2/+3
Previously, graph_is_interesting() did not behave quite the same way as the code in get_revision(). As a result, it would sometimes think commits were uninteresting, even though get_revision() would return them. This resulted in incorrect lines in the graph output. This change creates a get_commit_action() function, which graph_is_interesting() and simplify_commit() both now use to determine if a commit will be shown. It is identical to the old simplify_commit() behavior, except that it never calls rewrite_parents(). This problem was reported by Santi Béjar. The following command would exhibit the problem before, but now works correctly: git log --graph --simplify-by-decoration --oneline v1.6.3.3 Previously git graph did not display the output for this command correctly between f29ac4f and 66996ec, among other places. Signed-off-by: Adam Simpkins <simpkins@facebook.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-18graph API: use a new color when starting a brand new columnLibravatar Adam Simpkins1-3/+11
Use a new color for commits that don't have any previously printed children. The following command demonstrates the changes: git log --graph --pretty=tformat:'%h %s%n' -7 481c7a6 18b0793 Now the two independent lines of development are displayed with different colors, instead of both using the same color. Signed-off-by: Adam Simpkins <simpkins@facebook.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-22janitor: use NULL and not 0 for pointers.Libravatar Pierre Habouzit1-1/+1
Brought to you thanks to coccinelle: ---8<---- @@ expression *E; @@ ( E == - 0 + NULL | E != - 0 + NULL | E = - 0 + NULL ) @@ identifier f; type T; @@ T *f(...) { <... - return 0; + return NULL; ...> } --->8---- There are a lot more hits in compat/nedmallox and compat/regex but these are borrowed code we rather do not want to maintain our own forks for, and this patch refrains from touching them. Signed-off-by: Pierre Habouzit <madcoder@debian.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-05-18Merge branch 'ac/graph-horizontal-line'Libravatar Junio C Hamano1-15/+47
* ac/graph-horizontal-line: graph API: Use horizontal lines for more compact graphs
2009-04-22Fix typos / spelling in commentsLibravatar Mike Ralphson1-1/+1
Signed-off-by: Mike Ralphson <mike@abacus.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-22graph API: Use horizontal lines for more compact graphsLibravatar Allan Caffee1-15/+47
Use horizontal lines instead of long diagonal lines during the collapsing state of graph rendering. For example what used to be: | | | | | | | | |/ | | |/| | |/| | |/| | | | | | | is now | | | | | | |_|_|/ |/| | | | | | | This results in more compact and legible graphs. Signed-off-by: Allan Caffee <allan.caffee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-22graph API: fix a bug in the rendering of octopus mergesLibravatar Allan Caffee1-1/+1
An off by one error was causing octopus merges with 3 parents to not be rendered correctly. This regression was introduced by 427fc5. Signed-off-by: Allan Caffee <allan.caffee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-22graph API: fix extra space during pre_commit_line stateLibravatar Allan Caffee1-2/+2
An extra space is being inserted between the "commit" column and all of the successive edges. Remove this space. This regression was introduced by 427fc5b. Signed-off-by: Allan Caffee <allan.caffee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-13graph API: Added logic for colored edgesLibravatar Allan Caffee1-48/+198
Modified the graph drawing logic to colorize edges based on parent-child relationships similiarly to gitk. Signed-off-by: Allan Caffee <allan.caffee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-10-12Replace calls to strbuf_init(&foo, 0) with STRBUF_INIT initializerLibravatar Brandon Casey1-9/+4
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-25graph.c: make many functions staticLibravatar Nanako Shiraishi1-14/+43
These function are not used anywhere. Also removes graph_release() that is never called. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-06-06git log --graph: print '*' for all commits, including mergesLibravatar Adam Simpkins1-14/+0
Previously, merge commits were printed with 'M' instead of '*'. This had the potential to confuse users when not all parents of the merge commit were included in the log output. As Junio has pointed out, merge commits can almost always be easily identified from the log message, anyway. Signed-off-by: Adam Simpkins <adam@adamsimpkins.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-06graph API: fix "git log --graph --first-parent"Libravatar Adam Simpkins1-11/+53
This change teaches the graph API that only the first parent of each commit is interesting when "--first-parent" was specified. This change also consolidates the graph parent walking logic into two new internal functions, first_interesting_parent() and next_interesting_parent(). A simpler fix would have been to simply break at the end of the 2 existing for loops when graph->revs->first_parent_only is set. However, this change seems nicer, especially if we ever need to add any new loops over the parent list in the future. Signed-off-by: Adam Simpkins <adam@adamsimpkins.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-01graph API: avoid printing unnecessary padding before some octopus mergesLibravatar Adam Simpkins1-5/+8
When an octopus merge is printed, several lines are printed before it to move over existing branch lines to its right. This is needed to make room for the children of the octopus merge. For example: | | | | | | \ \ | | \ \ | | \ \ | M---. \ \ | |\ \ \ \ \ However, this step isn't necessary if there are no branch lines to the right of the octopus merge. Therefore, skip this step when it is not needed, to avoid printing extra lines that don't really serve any purpose. Signed-off-by: Adam Simpkins <adam@adamsimpkins.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-01graph API: improve display of merge commitsLibravatar Adam Simpkins1-17/+93
This change improves the way merge commits are displayed, to eliminate a few visual artifacts. Previously, merge commits were displayed as: | M \ | |\ | As pointed out by Teemu Likonen, this didn't look nice if the rightmost branch line was displayed as '\' on the previous line, as it then appeared to have an extra space in it: | |\ | M \ | |\ | This change updates the code so that branch lines to the right of merge commits are printed slightly differently depending on how the previous line was displayed: | |\ | | | | | / | M \ | M | | M | | |\ \ | |\ \ | |\ \ Signed-off-by: Adam Simpkins <adam@adamsimpkins.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-25get_revision(): honor the topo_order flag for boundary commitsLibravatar Adam Simpkins1-8/+1
Now get_revision() sorts the boundary commits when topo_order is set. Since sort_in_topological_order() takes a struct commit_list, it first places the boundary commits into revs->commits. Signed-off-by: Adam Simpkins <adam@adamsimpkins.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-25Fix output of "git log --graph --boundary"Libravatar Adam Simpkins1-13/+66
Previously the graphing API wasn't aware of the revs->boundary flag, and it always assumed that commits marked UNINTERESTING would not be displayed. As a result, the boundary commits were printed at the end of the log output, but they didn't have any branch lines connecting them to their children in the graph. There was also another bug in the get_revision() code that caused graph_update() to be called twice on the first boundary commit. This caused the graph API to think that a commit had been skipped, and print a "..." line in the output. Signed-off-by: Adam Simpkins <adam@adamsimpkins.net> 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-11/+11
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-25graph API: don't print branch lines for uninteresting merge parentsLibravatar Adam Simpkins1-13/+44
Previously, the graphing code printed lines coming out of a merge commit for all of its parents, even if some of them were uninteresting. Now it only prints lines for interesting commits. For example, for a merge commit where only the first parent is interesting, the code now prints: * merge commit * interesting child instead of: M merge commit |\ * interesting child Signed-off-by: Adam Simpkins <adam@adamsimpkins.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-25graph API: fix graph mis-alignment after uninteresting commitsLibravatar Adam Simpkins1-0/+3
The graphing code had a bug that caused it to output branch lines incorrectly after ignoring an uninteresting commit. When computing how to match up the branch lines from the current commit to the next one, it forgot to take into account that it needed to initially start with 2 empty spaces where the missing commit would have gone. So, instead of drawing this, | * | <- Commit with uninteresting parent | / * | It used to incorrectly draw this: | * | <- Commit with uninteresting parent * | Signed-off-by: Adam Simpkins <adam@adamsimpkins.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-05graph API: eliminate unnecessary indentationLibravatar Adam Simpkins1-14/+52
This change improves the calculation of the amount of horizontal padding, so that there is always exactly 1 space of padding. Previously, most commits had 3 spaces of padding, but commits that didn't have any children in the graph had only 1 space of padding. Signed-off-by: Adam Simpkins <adam@adamsimpkins.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>