aboutsummaryrefslogtreecommitdiff
path: root/graph.c
Commit message (Collapse)AuthorAge
* Revert "graph.c: mark private file-scope symbols as static"John Keeping2013-03-03
| | | | | | | | | | | | | | | | | 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>
* graph: output padding for merge subsequent parentsJohn Keeping2013-02-07
| | | | | | | | | | | | | | | | | 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>
* Merge branch 'mk/maint-graph-infinity-loop' into maintJunio C Hamano2013-01-14
|\ | | | | | | | | * mk/maint-graph-infinity-loop: graph.c: infinite loop in git whatchanged --graph -m
| * graph.c: infinite loop in git whatchanged --graph -mMichał Kiedrowicz2012-09-25
| | | | | | | | | | | | | | | | 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>
* | graph.c: mark private file-scope symbols as staticJunio C Hamano2012-09-15
|/ | | | Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Add output_prefix_length to diff_optionsLucian Poston2012-04-16
| | | | | | | | 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>
* 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>
* Share color list between graph and show-branchDan McGee2011-04-04
| | | | | | | | 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>
* 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>
* Merge branch 'maint'Junio C Hamano2010-08-22
|\ | | | | | | | | * maint: Typos in code comments, an error message, documentation
| * Typos in code comments, an error message, documentationRalf Wildenhues2010-08-22
| | | | | | | | | | Signed-off-by: Ralf Wildenhues <Ralf.Wildenhues@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Enable custom schemes for column colors in the graph APIJohan Herland2010-07-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Make graph_next_line() available in the graph.h APIJohan Herland2010-07-13
|/ | | | | | | | | | 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>
* graph.c: register a callback for graph outputBo Yang2010-05-31
| | | | | | | | | | | 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>
* Add GIT_COLOR_BOLD_* and GIT_COLOR_BG_*Mark Lodato2010-03-07
| | | | | | | | | | | | | 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>
* Merge branch 'as/maint-graph-interesting-fix'Junio C Hamano2009-08-27
|\ | | | | | | | | | | * as/maint-graph-interesting-fix: Add tests for rev-list --graph with options that simplify history graph API: fix bug in graph_is_interesting()
| * graph API: fix bug in graph_is_interesting()Adam Simpkins2009-08-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | graph API: use a new color when starting a brand new columnAdam Simpkins2009-08-18
|/ | | | | | | | | | | | | 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>
* janitor: use NULL and not 0 for pointers.Pierre Habouzit2009-07-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Merge branch 'ac/graph-horizontal-line'Junio C Hamano2009-05-18
|\ | | | | | | | | * ac/graph-horizontal-line: graph API: Use horizontal lines for more compact graphs
| * graph API: Use horizontal lines for more compact graphsAllan Caffee2009-04-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Fix typos / spelling in commentsMike Ralphson2009-04-22
| | | | | | | | | | Signed-off-by: Mike Ralphson <mike@abacus.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | graph API: fix a bug in the rendering of octopus mergesAllan Caffee2009-04-22
| | | | | | | | | | | | | | | | 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>
* | graph API: fix extra space during pre_commit_line stateAllan Caffee2009-04-22
|/ | | | | | | | | 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>
* graph API: Added logic for colored edgesAllan Caffee2009-04-13
| | | | | | | | 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>
* 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>
* graph.c: make many functions staticNanako Shiraishi2008-09-25
| | | | | | | | 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>
* git log --graph: print '*' for all commits, including mergesAdam Simpkins2008-06-06
| | | | | | | | | | | | 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>
* graph API: fix "git log --graph --first-parent"Adam Simpkins2008-06-06
| | | | | | | | | | | | | | | | 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>
* graph API: avoid printing unnecessary padding before some octopus mergesAdam Simpkins2008-06-01
| | | | | | | | | | | | | | | | | | | | | 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>
* graph API: improve display of merge commitsAdam Simpkins2008-06-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* get_revision(): honor the topo_order flag for boundary commitsAdam Simpkins2008-05-25
| | | | | | | | | 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>
* Fix output of "git log --graph --boundary"Adam Simpkins2008-05-25
| | | | | | | | | | | | | | | | 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>
* 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>
* graph API: don't print branch lines for uninteresting merge parentsAdam Simpkins2008-05-25
| | | | | | | | | | | | | | | | | | | | | 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>
* graph API: fix graph mis-alignment after uninteresting commitsAdam Simpkins2008-05-25
| | | | | | | | | | | | | | | | | | | | | | 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>
* graph API: eliminate unnecessary indentationAdam Simpkins2008-05-05
| | | | | | | | | | 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>
* Add history graph APIAdam Simpkins2008-05-05
This new API allows the commit history to be displayed as a text-based graphical representation. Signed-off-by: Adam Simpkins <adam@adamsimpkins.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>