- 08 9月, 2016 1 次提交
-
-
由 brian m. carlson 提交于
Signed-off-by: Nbrian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 12 8月, 2016 1 次提交
-
-
由 Kevin Willford 提交于
The `rebase` family of Git commands avoid applying patches that were already integrated upstream. They do that by using the revision walking option that computes the patch IDs of the two sides of the rebase (local-only patches vs upstream-only ones) and skipping those local patches whose patch ID matches one of the upstream ones. In many cases, this causes unnecessary churn, as already the set of paths touched by a given commit would suffice to determine that an upstream patch has no local equivalent. This hurts performance in particular when there are a lot of upstream patches, and/or large ones. Therefore, let's introduce the concept of a "diff-header-only" patch ID, compare those first, and only evaluate the "full" patch ID lazily. Please note that in contrast to the "full" patch IDs, those "diff-header-only" patch IDs are prone to collide with one another, as adjacent commits frequently touch the very same files. Hence we now have to be careful to allow multiple hash entries with the same hash. We accomplish that by using the hashmap_add() function that does not even test for hash collisions. This also allows us to evaluate the full patch ID lazily, i.e. only when we found commits with matching diff-header-only patch IDs. We add a performance test that demonstrates ~1-6% improvement. In practice this will depend on various factors such as how many upstream changes and how big those changes are along with whether file system caches are cold or warm. As Git's test suite has no way of catching performance regressions, we also add a regression test that verifies that the full patch ID computation is skipped when the diff-header-only computation suffices. Signed-off-by: NKevin Willford <kcwillford@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 02 8月, 2016 1 次提交
-
-
由 Josh Triplett 提交于
This helps users who would prefer format-patch to default to --from, and makes it easier to change the default in the future. Signed-off-by: NJosh Triplett <josh@joshtriplett.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 25 6月, 2016 5 次提交
-
-
由 Johannes Schindelin 提交于
Earlier, we freopen()ed stdout in order to write patches to files. That forced us to duplicate stdout (naming it "realstdout") because we *still* wanted to be able to report the file names. As we do not abuse stdout that way anymore, we no longer need to duplicate stdout, either. Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Johannes Schindelin 提交于
We just taught the relevant functions to respect the diffopt.file field, to allow writing somewhere else than stdout. Let's make use of it. Technically, we do not need to avoid that call in a builtin: we assume that builtins (as opposed to library functions) are stand-alone programs that may do with their (global) state. Yet, we want to be able to reuse that code in properly lib-ified code, e.g. when converting scripts into builtins. Further, while we did not *have* to touch the cmd_show() and cmd_cherry() code paths (because they do not want to write anywhere but stdout as of yet), it just makes sense to be consistent, making it easier and safer to move the code later. Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Johannes Schindelin 提交于
The --color=auto handling is done by seeing if file descriptor 1 (the standard output) is connected to a terminal. format-patch used freopen() to reuse the standard output stream even when sending its output to an on-disk file, and this check is appropriate. In the next step, however, we will stop reusing "FILE *stdout", and instead start using arbitrary file descriptor obtained by doing an fopen(3) ourselves. The check --color=auto does will become useless, as we no longer are writing to the standard output stream. But then, we do not need to guess to begin with. As argued in the commit message of 7787570c (format-patch: ignore ui.color, 2011-09-13), we do not allow the ui.color setting to affect format-patch's output. The only time, therefore, that we allow color sequences to be written to the output files is when the user specified the --color=always command-line option explicitly. Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Johannes Schindelin 提交于
We are about to teach the log-tree machinery to reuse the diffopt.file field to output to a file stream other than stdout, in line with the diff machinery already writing to diffopt.file. However, we might want to write something after the diff in log_tree_commit() (e.g. with the --show-linear-break option), therefore we must not let the diff machinery close the file (as per diffopt.close_file. This means that log_tree_commit() itself must override the diffopt.close_file flag and close the file, and if log_tree_commit() is called in a loop, the caller is responsible to do the same. Note: format-patch has an `--output-directory` option. Due to the fact that format-patch's options are parsed first, and that the parse-options machinery accepts uniquely abbreviated options, the diff options `--output` (and `-o`) are shadowed. Therefore close_file is not set to 1 so that cmd_format_patch() does *not* need to handle the close_file flag differently, even if it calls log_tree_commit() in a loop. Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Mehul Jain 提交于
Users may want to always use "--show-signature" while using git-log and related commands. When log.showSignature is set to true, git-log and related commands will behave as if "--show-signature" was given to them. Note that this config variable is meant to affect git-log, git-show, git-whatchanged and git-reflog. Other commands like git-format-patch, git-rev-list are not to be affected by this config variable. Signed-off-by: NMehul Jain <mehul.jain2029@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 14 6月, 2016 1 次提交
-
-
由 Jeff King 提交于
There are two types of string_lists: those that own the string memory, and those that don't. You can tell the difference by the strdup_strings flag, and one should use either STRING_LIST_INIT_DUP, or STRING_LIST_INIT_NODUP as an initializer. Historically, the normal all-zeros initialization has corresponded to the NODUP case. Many sites use no initializer at all, and that works as a shorthand for that case. But for a reader of the code, it can be hard to remember which is which. Let's be more explicit and actually have each site declare which type it means to use. This is a fairly mechanical conversion; I assumed each site was correct as-is, and just switched them all to NODUP. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 07 6月, 2016 1 次提交
-
-
由 Eric Wong 提交于
This output format prevents format-patch output from breaking readers if somebody copy+pasted an mbox into a commit message. Unlike the traditional "mboxo" format, "mboxrd" is designed to be fully-reversible. "mboxrd" also gracefully degrades to showing extra ">" in existing "mboxo" readers. This degradation is preferable to breaking message splitting completely, a problem I've seen in "mboxcl" due to having multiple, non-existent, or inaccurate Content-Length headers. "mboxcl2" is a non-starter since it's inherits the problems of "mboxcl" while being completely incompatible with existing tooling based around mailsplit. ref: http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/mail-mbox-formats.htmlSigned-off-by: NEric Wong <e@80x24.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 27 4月, 2016 3 次提交
-
-
由 Xiaolong Ye 提交于
This allows to record the base commit automatically, it is equivalent to set --base=auto in cmdline. The format.useAutoBase has lower priority than command line option, so if user set format.useAutoBase and pass the command line option in the meantime, base_commit will be the one passed to command line option. Signed-off-by: NXiaolong Ye <xiaolong.ye@intel.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Xiaolong Ye 提交于
Introduce --base=auto to record the base commit info automatically, the base_commit will be the merge base of tip commit of the upstream branch and revision-range specified in cmdline. Helped-by: NJunio C Hamano <gitster@pobox.com> Helped-by: NWu Fengguang <fengguang.wu@intel.com> Signed-off-by: NXiaolong Ye <xiaolong.ye@intel.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Xiaolong Ye 提交于
Maintainers or third party testers may want to know the exact base tree the patch series applies to. Teach git format-patch a '--base' option to record the base tree info and append it at the end of the first message (either the cover letter or the first patch in the series). The base tree info consists of the "base commit", which is a well-known commit that is part of the stable part of the project history everybody else works off of, and zero or more "prerequisite patches", which are well-known patches in flight that is not yet part of the "base commit" that need to be applied on top of "base commit" in topological order before the patches can be applied. The "base commit" is shown as "base-commit: " followed by the 40-hex of the commit object name. A "prerequisite patch" is shown as "prerequisite-patch-id: " followed by the 40-hex "patch id", which can be obtained by passing the patch through the "git patch-id --stable" command. Imagine that on top of the public commit P, you applied well-known patches X, Y and Z from somebody else, and then built your three-patch series A, B, C, the history would be like: ---P---X---Y---Z---A---B---C With "git format-patch --base=P -3 C" (or variants thereof, e.g. with "--cover-letter" of using "Z..C" instead of "-3 C" to specify the range), the base tree information block is shown at the end of the first message the command outputs (either the first patch, or the cover letter), like this: base-commit: P prerequisite-patch-id: X prerequisite-patch-id: Y prerequisite-patch-id: Z Helped-by: NJunio C Hamano <gitster@pobox.com> Helped-by: NWu Fengguang <fengguang.wu@intel.com> Signed-off-by: NXiaolong Ye <xiaolong.ye@intel.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 31 3月, 2016 1 次提交
-
-
由 Junio C Hamano 提交于
"git log --pretty={medium,full,fuller}" and "git log" by default prepend 4 spaces to the log message, so it makes sense to enable the new "expand-tabs" facility by default for these formats. Add --no-expand-tabs option to override the new default. The change alone breaks a test in t4201 that runs "git shortlog" on the output from "git log", and expects that the output from "git log" does not do such a tab expansion. Adjust the test to explicitly disable expand-tabs with --no-expand-tabs. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 26 2月, 2016 2 次提交
-
-
由 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>
-
由 Matthieu Moy 提交于
This is currently a wrapper around init_grep_defaults(), but will allow adding more initialization in further patches. Signed-off-by: NMatthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 14 1月, 2016 1 次提交
-
-
由 Alexander Kuleshov 提交于
We can pass -o/--output-directory to the format-patch command to store patches in some place other than the working directory. This patch introduces format.outputDirectory configuration option for same purpose. The case of usage of this configuration option can be convenience to not pass every time -o/--output-directory if an user has pattern to store all patches in the /patches directory for example. The format.outputDirectory has lower priority than command line option, so if user will set format.outputDirectory and pass the command line option, a result will be stored in a directory that passed to command line option. Signed-off-by: NAlexander Kuleshov <kuleshovmail@gmail.com> Signed-off-by: NStephen P. Smith <ischis2@cox.net> Reviewed-by: NEric Sunshine <sunshine@sunshineco.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 16 12月, 2015 1 次提交
-
-
由 brian m. carlson 提交于
Oftentimes, patches created by git format-patch will be stored in version control or compared with diff. In these cases, two otherwise identical patches can have different commit hashes, leading to diff noise. Teach git format-patch a --zero-commit option that instead produces an all-zero hash to avoid this diff noise. Signed-off-by: Nbrian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 20 11月, 2015 3 次提交
-
-
由 brian m. carlson 提交于
Convert all instances of get_object_hash to use an appropriate reference to the hash member of the oid member of struct object. This provides no functional change, as it is essentially a macro substitution. Signed-off-by: Nbrian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: NJeff King <peff@peff.net>
-
由 brian m. carlson 提交于
struct object is one of the major data structures dealing with object IDs. Convert it to use struct object_id instead of an unsigned char array. Convert get_object_hash to refer to the new member as well. Signed-off-by: Nbrian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: NJeff King <peff@peff.net>
-
由 brian m. carlson 提交于
Convert most instances where the sha1 member of struct object is dereferenced to use get_object_hash. Most instances that are passed to functions that have versions taking struct object_id, such as get_sha1_hex/get_oid_hex, or instances that can be trivially converted to use struct object_id instead, are not converted. Signed-off-by: Nbrian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: NJeff King <peff@peff.net>
-
- 06 10月, 2015 1 次提交
-
-
由 Jeff King 提交于
When working with paths in strbufs, we frequently want to ensure that a directory contains a trailing slash before appending to it. We can shorten this code (and make the intent more obvious) by calling strbuf_complete. Most of these cases are trivially identical conversions, but there are two things to note: - in a few cases we did not check that the strbuf is non-empty (which would lead to an out-of-bounds memory access). These were generally not triggerable in practice, either from earlier assertions, or typically because we would have just fed the strbuf to opendir(), which would choke on an empty path. - in a few cases we indexed the buffer with "original_len" or similar, rather than the current sb->len, and it is not immediately obvious from the diff that they are the same. In all of these cases, I manually verified that the strbuf does not change between the assignment and the strbuf_complete call. This does not convert cases which look like: if (sb->len && !is_dir_sep(sb->buf[sb->len - 1])) strbuf_addch(sb, '/'); as those are obviously semantically different. Some of these cases arguably should be doing that, but that is out of scope for this change, which aims purely for cleanup with no behavior change (and at least it will make such sites easier to find and examine in the future, as we can grep for strbuf_complete). Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 26 8月, 2015 1 次提交
-
-
由 Junio C Hamano 提交于
Two logical lines that were not overly long was split in the middle, which made them read worse. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 21 8月, 2015 3 次提交
-
-
由 Junio C Hamano 提交于
We defaulted to ignoring merge diffs because long long ago, in a galaxy far away, we didn't have a great way to show the diffs. The whole "--cc" option goes back to January '06 and commit d8f4790e ("diff-tree --cc: denser combined diff output for a merge commit"). And before that option - so for about 8 months - we had no good way to show the diffs of merges in a good dense way. So the whole "don't show diffs for merges by default" actually made a lot of sense originally, because our merge diffs were not very useful. And this was carried forward to this day. "git log --cc" still ignores merge commits, and you need to say "git log -m --cc" to view a sensible rendition of merge and non-merge commits, even with the previous change to make "--cc" imply "-p". Teach "git log" that "--cc" means the user wants to see interesting changes in merge commits by turning "-m" on. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
The "--cc" option to "git log" is clearly a request to show some sort of combined diff (be it --patch or --raw), but traditionally we required the command line to explicitly ask for "git log -p --cc". Teach the command line parser to treat a lone "--cc" as if the user specified "-p --cc". Formats that do ask for other forms of diff output, e.g. "log --raw --cc", are not overriden. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
The revision walking API allows the callers to tweak its configuration at the last minute, immediately after all the revision and pathspec parameters are parsed from the command line but before the default actions are decided based on them, by defining a "tweak" callback function when calling setup_revisions(). Traditionally, this facility was used by "git show" to turn on the patch output "-p" by default when no diff output option (e.g. "--raw" or "-s" to squelch the output altogether) is given on the command line, and further give dense combined diffs "--cc" for merge commits when no option to countermand it (e.g. "-m" to show pairwise patches). Recently, "git log" started using the same facility, but we named the callback function "default_follow_tweak()", as if the only kind of tweaking we would want for "git log" will forever be limited to turning "--follow" on by default when told by a configuration variable. That was myopic. Rename it to more generic name "log_setup_revisions_tweak()", and match the one used by show "show_setup_revisions_tweak()". 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>
-
- 30 6月, 2015 1 次提交
-
-
由 Jeff King 提交于
In preparation for adding date modes that may carry extra information beyond the mode itself, this patch converts the date_mode enum into a struct. Most of the conversion is fairly straightforward; we pass the struct as a pointer and dereference the type field where necessary. Locations that declare a date_mode can use a "{}" constructor. However, the tricky case is where we use the enum labels as constants, like: show_date(t, tz, DATE_NORMAL); Ideally we could say: show_date(t, tz, &{ DATE_NORMAL }); but of course C does not allow that. Likewise, we cannot cast the constant to a struct, because we need to pass an actual address. Our options are basically: 1. Manually add a "struct date_mode d = { DATE_NORMAL }" definition to each caller, and pass "&d". This makes the callers uglier, because they sometimes do not even have their own scope (e.g., they are inside a switch statement). 2. Provide a pre-made global "date_normal" struct that can be passed by address. We'd also need "date_rfc2822", "date_iso8601", and so forth. But at least the ugliness is defined in one place. 3. Provide a wrapper that generates the correct struct on the fly. The big downside is that we end up pointing to a single global, which makes our wrapper non-reentrant. But show_date is already not reentrant, so it does not matter. This patch implements 3, along with a minor macro to keep the size of the callers sane. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 23 6月, 2015 1 次提交
-
-
由 Michael Haggerty 提交于
Some functions from the refs module were still declared in cache.h. Move them to refs.h. Signed-off-by: NMichael Haggerty <mhagger@alum.mit.edu> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 02 6月, 2015 1 次提交
-
-
由 Junio C Hamano 提交于
"git format-patch --ignore-if-in-upstream A..B", when either A or B is a tag, failed miserably. This is because the code passes the tips it used for traversal to clear_commit_marks(), after running a temporary revision traversal to enumerate the commits on both branches to find if they have commits that make equivalent changes. The revision traversal machinery knows how to enumerate commits reachable starting from a tag, but clear_commit_marks() wants to take nothing but a commit. In the longer term, it might be a more correct fix to teach clear_commit_marks() to do the same "committish to commit" dereferencing that is done in the revision traversal machinery, but for now this fix should suffice. Reported-by: NBruce Korb <bruce.korb@gmail.com> Helped-by: NChristian Couder <christian.couder@gmail.com> Helped-by: Nbrian m. carlson <sandals@crustytoothpaste.net> Helped-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 22 5月, 2015 2 次提交
-
-
由 Jeff King 提交于
When the previous commit introduced the branch_get_upstream helper, there was one call-site that could not be converted: the one in sha1_name.c, which gives detailed error messages for each possible failure. Let's teach the helper to optionally report these specific errors. This lets us convert another callsite, and means we can use the helper in other locations that want to give the same error messages. The logic and error messages come straight from sha1_name.c, with the exception that we start each error with a lowercase letter, as is our usual style (note that a few tests need updated as a result). Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
All of the information needed to find the @{upstream} of a branch is included in the branch struct, but callers have to navigate a series of possible-NULL values to get there. Let's wrap that logic up in an easy-to-read helper. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 04 5月, 2015 1 次提交
-
-
由 Alex Henrie 提交于
Earlier, 9c9b4f2f (standardize usage info string format, 2015-01-13) tried to make usage-string in line with the documentation by - Placing angle brackets around fill-in-the-blank parameters - Putting dashes in multiword parameter names - Adding spaces to [-f|--foobar] to make [-f | --foobar] - Replacing <foobar>* with [<foobar>...] but it missed a few places. Signed-off-by: NAlex Henrie <alexhenrie24@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 15 1月, 2015 1 次提交
-
-
由 Alex Henrie 提交于
This patch puts the usage info strings that were not already in docopt- like format into docopt-like format, which will be a litle easier for end users and a lot easier for translators. Changes include: - Placing angle brackets around fill-in-the-blank parameters - Putting dashes in multiword parameter names - Adding spaces to [-f|--foobar] to make [-f | --foobar] - Replacing <foobar>* with [<foobar>...] Signed-off-by: NAlex Henrie <alexhenrie24@gmail.com> Reviewed-by: NMatthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 08 1月, 2015 1 次提交
-
-
由 Doug Kelly 提交于
diff.submodule when set to log produces output which git-am cannot handle. Ignore this setting when generating patch output. Signed-off-by: NDoug Kelly <dougk.ff7@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 07 1月, 2015 1 次提交
-
-
由 Kyle J. McKay 提交于
The parse_options API expects an array of alternative usage lines to which it automatically ads the language-appropriate "or" when displaying. Each of these options is marked for translation with N_ and then later translated when gettext is called on each element of the array. Since the N_ macro just expands to its argument, if two N_-marked strings appear next to each other without being separated by anything else such as a comma, the preprocessor will join them into one string. In that case two separate strings get marked for translation, but at runtime they have been joined into a single string passed to gettext which then fails to get translated because the combined string was never marked for translation. Fix this by properly separating the two N_ marked strings with a comma and removing the embedded "\n" and " or:" that are properly supplied by the parse_options API. Signed-off-by: NKyle J. McKay <mackyle@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 02 12月, 2014 1 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
This allows the callback to use 'base' as a temporary buffer to quickly assemble full path "without" extra allocation. The callback has to restore it afterwards of course. Helped-by: NEric Sunshine <sunshine@sunshineco.com> Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 16 10月, 2014 1 次提交
-
-
由 Ronnie Sahlberg 提交于
resolve_ref_unsafe takes a boolean argument for reading (a nonexistent ref resolves successfully for writing but not for reading). Change this to be a flags field instead, and pass the new constant RESOLVE_REF_READING when we want this behaviour. While at it, swap two of the arguments in the function to put output arguments at the end. As a nice side effect, this ensures that we can catch callers that were unaware of the new API so they can be audited. Give the wrapper functions resolve_refdup and read_ref_full the same treatment for consistency. Signed-off-by: NRonnie Sahlberg <sahlberg@google.com> Signed-off-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 15 10月, 2014 1 次提交
-
-
由 Jonathan Nieder 提交于
Many config-parsing helpers, like parse_branch_color_slot, take the name of a config variable and an offset to the "slot" name (e.g., "color.branch.plain" is passed along with "13" to effectively pass "plain"). This is leftover from the time that these functions would die() on error, and would want the full variable name for error reporting. These days they do not use the full variable name at all. Passing a single pointer to the slot name is more natural, and lets us more easily adjust the callers to use skip_prefix to avoid manually writing offset numbers. This is effectively a continuation of 9e1a5ebe, which did the same for parse_diff_color_slot. This patch covers all of the remaining similar constructs. Signed-off-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 08 10月, 2014 1 次提交
-
-
由 René Scharfe 提交于
Continue where ae021d87 (use skip_prefix to avoid magic numbers) left off and use skip_prefix() in more places for determining the lengths of prefix strings to avoid using dependent constants and other indirect methods. Signed-off-by: NRene Scharfe <l.s.r@web.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-