- 04 10月, 2016 1 次提交
-
-
由 Junio C Hamano 提交于
The code that sets custom abbreviation length, in response to command line argument, often does something like this: if (skip_prefix(arg, "--abbrev=", &arg)) abbrev = atoi(arg); else if (!strcmp("--abbrev", &arg)) abbrev = DEFAULT_ABBREV; /* make the value sane */ if (abbrev < 0 || 40 < abbrev) abbrev = ... some sane value ... However, it is pointless to sanity-check and tweak the value obtained from DEFAULT_ABBREV. We are going to allow it to be initially set to -1 to signal that the default abbreviation length must be auto sized upon the first request to abbreviate, based on the number of objects in the repository, and when that happens, rejecting or tweaking a negative value to a "saner" one will negatively interfere with the auto sizing. The codepaths for git rev-parse --short <object> git diff --raw --abbrev do exactly that; allow them to pass possibly negative abbrevs intact, that will come from DEFAULT_ABBREV in the future. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 09 9月, 2016 3 次提交
-
-
由 Stefan Beller 提交于
When `len < 1`, len has to be 0 or negative, emit_line will then remove the first character and by then `len` would be negative. As this doesn't happen, it is safe to assume it is dead code. This continues to simplify the code, which was started in b8d9c1a6 (2009-09-03, diff.c: the builtin_diff() deals with only two-file comparison). Signed-off-by: NStefan Beller <sbeller@google.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Stefan Beller 提交于
We keep the actual data in the diff options, which are just as accessible. Remove the pointer stored in struct emit_callback for readability. Signed-off-by: NStefan Beller <sbeller@google.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Stefan Beller 提交于
The value of `ecbdata->opt` is accessible via the short variable `o` already, so let's use that instead. Signed-off-by: NStefan Beller <sbeller@google.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 08 9月, 2016 1 次提交
-
-
由 brian m. carlson 提交于
Convert struct cache_entry to use struct object_id by applying the following semantic patch and the object_id transforms from contrib, plus the actual change to the struct: @@ struct cache_entry E1; @@ - E1.sha1 + E1.oid.hash @@ struct cache_entry *E1; @@ - E1->sha1 + E1->oid.hash Signed-off-by: Nbrian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 01 9月, 2016 5 次提交
-
-
由 Jacob Keller 提交于
Teach git-diff and friends a new format for displaying the difference of a submodule. The new format is an inline diff of the contents of the submodule between the commit range of the update. This allows the user to see the actual code change caused by a submodule update. Add tests for the new format and option. Signed-off-by: NJacob Keller <jacob.keller@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jacob Keller 提交于
Since we're going to be changing this function in a future patch, lets go ahead and convert this to use object_id now. Signed-off-by: NJacob Keller <jacob.keller@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jacob Keller 提交于
A future patch will add a new format for displaying the difference of a submodule. Make it easier by changing how we store the current selected format. Replace the DIFF_OPT flag with an enumeration, as each format will be mutually exclusive. Signed-off-by: NJacob Keller <jacob.keller@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jacob Keller 提交于
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: NJacob Keller <jacob.keller@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
"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: NJunio C Hamano <gitster@pobox.com>
-
- 30 7月, 2016 1 次提交
-
-
由 Kevin Willford 提交于
This will allow a diff patch id to be created using only the header data so that the contents of the file will not have to be loaded. Signed-off-by: NKevin Willford <kcwillford@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 23 7月, 2016 1 次提交
-
-
由 Jeff King 提交于
When accessing a blob for a diff, we may try to reuse file contents in the working tree, under the theory that it is faster to mmap those file contents than it would be to extract the content from the object database. When we have to filter those contents, though, that assumption does not hold. Even for our internal conversions like CRLF, we have to allocate and fill a new buffer anyway. But much worse, for external clean filters we have to exec an arbitrary script, and we have no idea how expensive it may be to run. So let's skip this optimization when conversion into git's "clean" form is required. This applies whenever the "want_file" flag is false. When it's true, the caller actually wants the smudged worktree contents, which the reused file by definition already has (in fact, this is a key optimization going the other direction, since reusing the worktree file there lets us skip smudge filters). Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 29 6月, 2016 5 次提交
-
-
由 brian m. carlson 提交于
All of the callers of this function use struct object_id, so convert it to use struct object_id in its arguments and internally. Signed-off-by: Nbrian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 brian m. carlson 提交于
Now that this struct's sha1 member is called "oid", update the comment and the sha1_valid member to be called "oid_valid" instead. The following Coccinelle semantic patch was used to implement this, followed by the transformations in object_id.cocci: @@ struct diff_filespec o; @@ - o.sha1_valid + o.oid_valid @@ struct diff_filespec *p; @@ - p->sha1_valid + p->oid_valid Signed-off-by: Nbrian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 brian m. carlson 提交于
Convert struct diff_filespec's sha1 member to use a struct object_id called "oid" instead. The following Coccinelle semantic patch was used to implement this, followed by the transformations in object_id.cocci: @@ struct diff_filespec o; @@ - o.sha1 + o.oid.hash @@ struct diff_filespec *p; @@ - p->sha1 + p->oid.hash Signed-off-by: Nbrian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 brian m. carlson 提交于
hashcpy with null_sha1 as the source is equivalent to hashclr. In addition to being simpler, using hashclr may give the compiler a chance to optimize better. Convert instances of hashcpy with the source argument of null_sha1 to hashclr. This transformation was implemented using the following semantic patch: @@ expression E1; @@ -hashcpy(E1, null_sha1); +hashclr(E1); Signed-off-by: Nbrian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Johannes Schindelin 提交于
"git diff --output=<file> --color=auto" used to show the ANSI color sequence in the resulting file when the standard output is connected to a terminal, because --color=auto check always checks the standard output, not the actual file that receives the output. We could correct this by using freopen(3) to redirect the standard output to the specified file, which is in like with how format-patch used to match the world order, but following the same reasoning as the earlier "format-patch: explicitly switch off color when writing to files", let's be more strict by bypassing the "auto" check when the --output=<file> option is in use. Strictly speaking, this is a backwards-incompatible change, but it is highly unlikely that any user would want to see ANSI color sequences in a file. The reason this was not caught earlier is most likely that either --output=<file> is not used, or only when stdout is redirected anyway. Users can still give --color=always if they want a colored diff in the resulting file. Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 11 6月, 2016 1 次提交
-
-
由 Junio C Hamano 提交于
http://lkml.kernel.org/g/20160610075043.GA13411@sigill.intra.peff.net reports that a change to add a new "function" with common ending with the existing one at the end of the file is shown like this: def foo do_foo_stuff() + common_ending() +end + +def bar + do_bar_stuff() + common_ending() end when the new heuristic is in use. In reality, the change is to add the blank line before "def bar" and everything below, which is what the code without the new heuristic shows. Disable the heuristics by default, and resurrect the documentation for the option and the configuration variables, while clearly marking the feature as still experimental. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 20 4月, 2016 1 次提交
-
-
由 Stefan Beller 提交于
In order to produce the smallest possible diff and combine several diff hunks together, we implement a heuristic from GNU Diff which moves diff hunks forward as far as possible when we find common context above and below a diff hunk. This sometimes produces less readable diffs when writing C, Shell, or other programming languages, ie: ... /* + * + * + */ + +/* ... instead of the more readable equivalent of ... +/* + * + * + */ + /* ... Implement the following heuristic to (optionally) produce the desired output. If there are diff chunks which can be shifted around, shift each hunk such that the last common empty line is below the chunk with the rest of the context above. This heuristic appears to resolve the above example and several other common issues without producing significantly weird results. However, as with any heuristic it is not really known whether this will always be more optimal. Thus, it can be disabled via diff.compactionHeuristic. Signed-off-by: NStefan Beller <sbeller@google.com> Signed-off-by: NJacob Keller <jacob.e.keller@intel.com> Signed-off-by: NStefan Beller <sbeller@google.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 26 2月, 2016 1 次提交
-
-
由 Matthieu Moy 提交于
Rename detection is a very convenient feature, and new users shouldn't have to dig in the documentation to benefit from it. Potential objections to activating rename detection are that it sometimes fail, and it is sometimes slow. But rename detection is already activated by default in several cases like "git status" and "git merge", so activating diff.renames does not fundamentally change the situation. When the rename detection fails, it now fails consistently between "git diff" and "git status". This setting does not affect plumbing commands, hence well-written scripts will not be affected. Signed-off-by: NMatthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 23 2月, 2016 3 次提交
-
-
由 Jeff King 提交于
We allocate 100 bytes to hold the "Submodule commit ..." text. This is enough, but it's not immediately obvious that this is the case, and we have to repeat the magic 100 twice. We could get away with xstrfmt here, but we want to know the size, as well, so let's use a real strbuf. And while we're here, we can clean up the logic around size_only. It currently sets and clears the "data" field pointlessly, and leaves the "should_free" flag on even after we have cleared the data. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
Using FLEX_ARRAY macros reduces the amount of manual computation size we have to do. It also ensures we don't overflow size_t, and it makes sure we write the same number of bytes that we allocated. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
The memory allocation scheme for the textconv interface is a bit tricky, and not well documented. It was originally designed as an internal part of diff.c (matching fill_mmfile), but gradually was made public. Refactoring it is difficult, but we can at least improve the situation by documenting the intended flow and enforcing it with an in-code assertion. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 22 1月, 2016 1 次提交
-
-
由 Duy Nguyen 提交于
Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 23 10月, 2015 1 次提交
-
-
由 Tobias Klauser 提交于
After switching to use the tempfile module in commit 284098f1 (diff: use tempfile module), no declarations from sigchain.h are used in diff.c anymore. Thus, remove the #include. Signed-off-by: NTobias Klauser <tklauser@distanz.ch> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 06 10月, 2015 1 次提交
-
-
由 Jeff King 提交于
Before sha1_to_hex_r() existed, a simple way to get hex sha1 into a buffer was with: strcpy(buf, sha1_to_hex(sha1)); This isn't wrong (assuming the buf is 41 characters), but it makes auditing the code base for bad strcpy() calls harder, as these become false positives. Let's convert them to sha1_to_hex_r(), and likewise for some calls to find_unique_abbrev(). While we're here, we'll double-check that all of the buffers are correctly sized, and use the more obvious GIT_SHA1_HEXSZ constant. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 29 9月, 2015 1 次提交
-
-
由 Jeff King 提交于
When we call into xdiff to perform a diff, we generally lose the return code completely. Typically by ignoring the return of our xdi_diff wrapper, but sometimes we even propagate that return value up and then ignore it later. This can lead to us silently producing incorrect diffs (e.g., "git log" might produce no output at all, not even a diff header, for a content-level diff). In practice this does not happen very often, because the typical reason for xdiff to report failure is that it malloc() failed (it uses straight malloc, and not our xmalloc wrapper). But it could also happen when xdiff triggers one our callbacks, which returns an error (e.g., outf() in builtin/rerere.c tries to report a write failure in this way). And the next patch also plans to add more failure modes. Let's notice an error return from xdiff and react appropriately. In most of the diff.c code, we can simply die(), which matches the surrounding code (e.g., that is what we do if we fail to load a file for diffing in the first place). This is not that elegant, but we are probably better off dying to let the user know there was a problem, rather than simply generating bogus output. We could also just die() directly in xdi_diff, but the callers typically have a bit more context, and can provide a better message (and if we do later decide to pass errors up, we're one step closer to doing so). There is one interesting case, which is in diff_grep(). Here if we cannot generate the diff, there is nothing to match, and we silently return "no hits". This is actually what the existing code does already, but we make it a little more explicit. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 26 9月, 2015 1 次提交
-
-
由 Jeff King 提交于
We sometimes sprintf into fixed-size buffers when we know that the buffer is large enough to fit the input (either because it's a constant, or because it's numeric input that is bounded in size). Likewise with strcpy of constant strings. However, these sites make it hard to audit sprintf and strcpy calls for buffer overflows, as a reader has to cross-reference the size of the array with the input. Let's use xsnprintf instead, which communicates to a reader that we don't expect this to overflow (and catches the mistake in case we do). Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 20 8月, 2015 1 次提交
-
-
由 Heiko Voigt 提交于
We remove the extracted functions and directly parse into and read out of the cache. This allows us to have one unified way of accessing submodule configuration values specific to single submodules. Regardless whether we need to access a configuration from history or from the worktree. Signed-off-by: NHeiko Voigt <hvoigt@hvoigt.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com> Signed-off-by: NStefan Beller <sbeller@google.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 13 8月, 2015 1 次提交
-
-
由 Michael Haggerty 提交于
Also add some code comments explaining how the fields in "struct diff_tempfile" are used. Signed-off-by: NMichael Haggerty <mhagger@alum.mit.edu> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 13 7月, 2015 1 次提交
-
-
由 René Scharfe 提交于
Check if a matched token is followed by a delimiter before advancing the pointer arg. This avoids accepting composite words like "allnew" or "defaultcontext" and misparsing them as "new" or "context". Signed-off-by: NRene Scharfe <l.s.r@web.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 10 7月, 2015 1 次提交
-
-
由 David Turner 提交于
People who work on projects with mostly linear history with frequent whole file renames may want to always use "git log --follow" when inspecting the life of the content that live in a single path. Teach the command to behave as if "--follow" was given from the command line when log.follow configuration variable is set *and* there is one (and only one) path on the command line. Signed-off-by: NDavid Turner <dturner@twopensource.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 28 5月, 2015 2 次提交
-
-
由 Jeff King 提交于
The latter is a much more descriptive name (and we support "color.diff.context" now). This also updates the name of any local variables which were used to store the color. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
The term "plain" is a bit ambiguous; let's allow the more specific "context", but keep "plain" around for compatibility. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 27 5月, 2015 2 次提交
-
-
由 Junio C Hamano 提交于
Traditionally, we only cared about whitespace breakages introduced in new lines. Some people want to paint whitespace breakages on old lines, too. When they see a whitespace breakage on a new line, they can spot the same kind of whitespace breakage on the corresponding old line and want to say "Ah, those breakages are there but they were inherited from the original, so let's not touch them for now." Introduce `--ws-error-highlight=<kind>` option, that lets them pass a comma separated list of `old`, `new`, and `context` to specify what lines to highlight whitespace errors on. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
Traditionally, we only had emit_add_line() helper, which knows how to find and paint whitespace breakages on the given line, because we only care about whitespace breakages introduced in new lines. The context lines and old (i.e. deleted) lines are emitted with a simpler emit_line_0() that paints the entire line in plain or old colors. Identify callers of emit_line_0() that show deleted lines and context lines, have them call new helpers, emit_del_line() and emit_context_line(), so that we can later tweak what is done to these two classes of lines. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 06 3月, 2015 1 次提交
-
-
由 René Scharfe 提交于
Clear the git_zstream variable at the start of git_deflate_init() etc. so that callers don't have to do that. Signed-off-by: NRene Scharfe <l.s.r@web.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 03 3月, 2015 1 次提交
-
-
由 Mårten Kongstad 提交于
When --shortstat is used in conjunction with --dirstat=changes, git diff will output the dirstat information twice: first as calculated by the 'lines' algorithm, then as calculated by the 'changes' algorithm: $ git diff --dirstat=changes,10 --shortstat v2.2.0..v2.2.1 23 files changed, 453 insertions(+), 54 deletions(-) 33.5% Documentation/RelNotes/ 26.2% t/ 46.6% Documentation/RelNotes/ 16.6% t/ The same duplication happens for --shortstat together with --dirstat=files, but not for --shortstat together with --dirstat=lines. Limit output to only include one dirstat part, calculated as specified by the --dirstat parameter. Also, add test for this. Signed-off-by: NMårten Kongstad <marten.kongstad@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 15 10月, 2014 1 次提交
-
-
由 Jeff King 提交于
Originally the color-parsing function was used only for config variables. It made sense to pass the variable name so that the die() message could be something like: $ git -c color.branch.plain=bogus branch fatal: bad color value 'bogus' for variable 'color.branch.plain' These days we call it in other contexts, and the resulting error messages are a little confusing: $ git log --pretty='%C(bogus)' fatal: bad color value 'bogus' for variable '--pretty format' $ git config --get-color foo.bar bogus fatal: bad color value 'bogus' for variable 'command line' This patch teaches color_parse to complain only about the value, and then return an error code. Config callers can then propagate that up to the config parser, which mentions the variable name. Other callers can provide a custom message. After this patch these three cases now look like: $ git -c color.branch.plain=bogus branch error: invalid color value: bogus fatal: unable to parse 'color.branch.plain' from command-line config $ git log --pretty='%C(bogus)' error: invalid color value: bogus fatal: unable to parse --pretty format $ git config --get-color foo.bar bogus error: invalid color value: bogus fatal: unable to parse default color value Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 21 8月, 2014 1 次提交
-
-
由 René Scharfe 提交于
Most struct child_process variables are cleared using memset first after declaration. Provide a macro, CHILD_PROCESS_INIT, that can be used to initialize them statically instead. That's shorter, doesn't require a function call and is slightly more readable (especially given that we already have STRBUF_INIT, ARGV_ARRAY_INIT etc.). Helped-by: NJohannes Sixt <j6t@kdbg.org> Signed-off-by: NRene Scharfe <l.s.r@web.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-