summaryrefslogtreecommitdiff
path: root/builtin
AgeCommit message (Collapse)Author
2019-01-04Merge branch 'nd/i18n'Junio C Hamano
More _("i18n") markings. * nd/i18n: fsck: mark strings for translation fsck: reduce word legos to help i18n parse-options.c: mark more strings for translation parse-options.c: turn some die() to BUG() parse-options: replace opterror() with optname() repack: mark more strings for translation remote.c: mark messages for translation remote.c: turn some error() or die() to BUG() reflog: mark strings for translation read-cache.c: add missing colon separators read-cache.c: mark more strings for translation read-cache.c: turn die("internal error") to BUG() attr.c: mark more string for translation archive.c: mark more strings for translation alias.c: mark split_cmdline_strerror() strings for translation git.c: mark more strings for translation
2019-01-02checkout: factor out mark_cache_entry_for_checkout functionThomas Gummerer
Factor out the code that marks a cache entry as matched for checkout into a separate function. We are going to introduce a new mode in 'git checkout' in a subsequent commit, that is going to have a slightly different logic. This would make this code unnecessarily complex. Moving that complexity into separate functions will make the code in the subsequent step easier to follow. Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-02checkout: clarify commentThomas Gummerer
The key point for the if statement is that read_tree_some did not update the entry, because either it doesn't exist in tree-ish or doesn't match the pathspec. Clarify that. Suggested-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-02rebase: run post-checkout hook on checkoutOrgad Shaneh
The scripted version of rebase used to run this hook on the initial checkout. The transition to built-in introduced a regression. Signed-off-by: Orgad Shaneh <orgads@gmail.com> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-02pack-protocol.txt: accept error packets in any contextMasaya Suzuki
In the Git pack protocol definition, an error packet may appear only in a certain context. However, servers can face a runtime error (e.g. I/O error) at an arbitrary timing. This patch changes the protocol to allow an error packet to be sent instead of any packet. Without this protocol spec change, when a server cannot process a request, there's no way to tell that to a client. Since the server cannot produce a valid response, it would be forced to cut a connection without telling why. With this protocol spec change, the server can be more gentle in this situation. An old client may see these error packets as an unexpected packet, but this is not worse than having an unexpected EOF. Following this protocol spec change, the error packet handling code is moved to pkt-line.c. Implementation wise, this implementation uses pkt-line to communicate with a subprocess. Since this is not a part of Git protocol, it's possible that a packet that is not supposed to be an error packet is mistakenly parsed as an error packet. This error packet handling is enabled only for the Git pack protocol parsing code considering this. Signed-off-by: Masaya Suzuki <masayasuzuki@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-02Use packet_reader instead of packet_read_lineMasaya Suzuki
By using and sharing a packet_reader while handling a Git pack protocol request, the same reader option is used throughout the code. This makes it easy to set a reader option to the request parsing code. Signed-off-by: Masaya Suzuki <masayasuzuki@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-02bisect--helper: `bisect_start` shell function partially in CPranit Bauva
Reimplement the `bisect_start` shell function partially in C and add `bisect-start` subcommand to `git bisect--helper` to call it from git-bisect.sh . The last part is not converted because it calls another shell function. `bisect_start` shell function will be completed after the `bisect_next` shell function is ported in C. Using `--bisect-start` subcommand is a temporary measure to port shell function in C so as to use the existing test suite. As more functions are ported, this subcommand will be retired and will be called by some other methods. Also introduce a method `bisect_append_log_quoted` to keep things short and crisp. Note that we are a bit lax about command-line parsing because the helper is not supposed to be called by the user directly (but only from the git bisect script). Helped-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Helped-by: Stephan Beyer <s-beyer@gmx.net> Mentored-by: Lars Schneider <larsxschneider@gmail.com> Mentored-by: Christian Couder <chriscool@tuxfamily.org> Mentored-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com> Signed-off-by: Tanushree Tumane <tanushreetumane@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-02bisect--helper: `get_terms` & `bisect_terms` shell function in CPranit Bauva
Reimplement the `get_terms` and `bisect_terms` shell function in C and add `bisect-terms` subcommand to `git bisect--helper` to call it from git-bisect.sh . Using `--bisect-terms` subcommand is a temporary measure to port shell function in C so as to use the existing test suite. As more functions are ported, this subcommand will be retired but its implementation will be called by some other methods. Also use error() to report "no terms defined" and accordingly change the test in t6030. We need to use PARSE_OPT_KEEP_UNKNOWN here to allow for parameters that look like options (e.g --term-good) but should not be parsed by cmd_bisect__helper(). This change is safe because all other cmdmodes have strict argc checks already. Mentored-by: Lars Schneider <larsxschneider@gmail.com> Mentored-by: Christian Couder <chriscool@tuxfamily.org> Mentored-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com> Signed-off-by: Tanushree Tumane <tanushreetumane@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-02bisect--helper: `bisect_next_check` shell function in CPranit Bauva
Reimplement `bisect_next_check` shell function in C and add `bisect-next-check` subcommand to `git bisect--helper` to call it from git-bisect.sh . `bisect_voc` shell function is no longer useful now and is replaced by using a char *[] of "new|bad" and "good|old" values. Using `--bisect-next-check` is a temporary measure to port shell function to C so as to use the existing test suite. As more functions are ported, this subcommand will be retired but its implementation will be called by some other methods. Helped-by: Stephan Beyer <s-beyer@gmx.net> Mentored-by: Lars Schneider <larsxschneider@gmail.com> Mentored-by: Christian Couder <chriscool@tuxfamily.org> Mentored-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com> Signed-off-by: Tanushree Tumane <tanushreetumane@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-02bisect--helper: `check_and_set_terms` shell function in CPranit Bauva
Reimplement the `check_and_set_terms` shell function in C and add `check-and-set-terms` subcommand to `git bisect--helper` to call it from git-bisect.sh Using `--check-and-set-terms` subcommand is a temporary measure to port shell function in C so as to use the existing test suite. As more functions are ported, this subcommand will be retired but its implementation will be called by some other methods. check_and_set_terms() sets and receives two global variables namely TERM_GOOD and TERM_BAD in the shell script. Luckily the file BISECT_TERMS also contains the value of those variables so its appropriate to evoke the method get_terms() after calling the subcommand so that it retrieves the value of TERM_GOOD and TERM_BAD from the file BISECT_TERMS. The two global variables are passed as arguments to the subcommand. Mentored-by: Lars Schneider <larsxschneider@gmail.com> Mentored-by: Christian Couder <chriscool@tuxfamily.org> Mentored-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com> Signed-off-by: Tanushree Tumane <tanushreetumane@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-02wrapper: move is_empty_file() and rename it as is_empty_or_missing_file()Pranit Bauva
is_empty_file() can help to refactor a lot of code. This will be very helpful in porting "git bisect" to C. Suggested-by: Torsten Bögershausen <tboegi@web.de> Mentored-by: Lars Schneider <larsxschneider@gmail.com> Mentored-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-02bisect--helper: `bisect_write` shell function in CPranit Bauva
Reimplement the `bisect_write` shell function in C and add a `bisect-write` subcommand to `git bisect--helper` to call it from git-bisect.sh Using `--bisect-write` subcommand is a temporary measure to port shell function in C so as to use the existing test suite. As more functions are ported, this subcommand will be retired but its implementation will be called by some other methods. Note: bisect_write() uses two variables namely TERM_GOOD and TERM_BAD from the global shell script thus we need to pass it to the subcommand using the arguments. We then store them in a struct bisect_terms and pass the memory address around functions. Add a log_commit() helper function to write the contents of the commit message header to a file which will be re-used in future parts of the code as well. Also introduce a function free_terms() to free the memory of `struct bisect_terms` and set_terms() to set the values of members in `struct bisect_terms`. Helped-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Mentored-by: Lars Schneider <larsxschneider@gmail.com> Mentored-by: Christian Couder <chriscool@tuxfamily.org> Mentored-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com> Signed-off-by: Tanushree Tumane <tanushreetumane@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-02bisect--helper: `bisect_reset` shell function in CPranit Bauva
Reimplement `bisect_reset` shell function in C and add a `--bisect-reset` subcommand to `git bisect--helper` to call it from git-bisect.sh . Using `bisect_reset` subcommand is a temporary measure to port shell functions to C so as to use the existing test suite. As more functions are ported, this subcommand would be retired but its implementation will be called by some other method. Note: --bisect-clean-state subcommand has not been retired as there are still a function namely `bisect_start()` which still uses this subcommand. Mentored-by: Lars Schneider <larsxschneider@gmail.com> Mentored-by: Christian Couder <chriscool@tuxfamily.org> Mentored by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com> Signed-off-by: Tanushree Tumane <tanushreetumane@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-12-28git-rebase, sequencer: extend --quiet option for the interactive machineryElijah Newren
While 'quiet' and 'interactive' may sound like antonyms, the interactive machinery actually has logic that implements several interactive_rebase=implied cases (--exec, --keep-empty, --rebase-merges) which won't pop up an editor. The rewrite of interactive rebase in C added a quiet option, though it only turns stats off. Since we want to make the interactive machinery also take over for git-rebase--merge, it should fully implement the --quiet option. git-rebase--interactive was already somewhat quieter than git-rebase--merge and git-rebase--am, possibly because cherry-pick has just traditionally been quieter. As such, we only drop a few informational messages -- "Rebasing (n/m)" and "Successfully rebased..." Also, for simplicity, remove the differences in how quiet and verbose options were recorded. Having one be signalled by the presence of a "verbose" file in the state_dir, while the other was signalled by the contents of a "quiet" file was just weirdly inconsistent. (This inconsistency pre-dated the rewrite into C.) Make them consistent by having them both key off the presence of the file. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-12-28am, rebase--merge: do not overlook --skip'ed commits with post-rewriteElijah Newren
The post-rewrite hook is supposed to be invoked for each rewritten commit. The fact that a commit was selected and processed by the rebase operation (even though when we hit an error a user said it had no more useful changes), suggests we should write an entry for it. In particular, let's treat it as an empty commit trivially squashed into its parent. This brings the rebase--am and rebase--merge backends in sync with the behavior of the interactive rebase backend. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-12-28rebase: fix incompatible options error messageElijah Newren
In commit f57696802c30 ("rebase: really just passthru the `git am` options", 2018-11-14), the handling of `git am` options was simplified dramatically (and an option parsing bug was fixed), but it introduced a small regression in the error message shown when options only understood by separate backends were used: $ git rebase --keep --ignore-whitespace fatal: cannot combine interactive options (--interactive, --exec, --rebase-merges, --preserve-merges, --keep-empty, --root + --onto) with am options (.git/rebase-apply/applying) $ git rebase --merge --ignore-whitespace fatal: cannot combine merge options (--merge, --strategy, --strategy-option) with am options (.git/rebase-apply/applying) Note that in both cases, the list of "am options" is ".git/rebase-apply/applying", which makes no sense. Since the lists of backend-specific options is documented pretty thoroughly in the rebase man page (in the "Incompatible Options" section, with multiple links throughout the document), and since I expect this list to change over time, just simplify the error message. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-12-28rebase: make builtin and legacy script error messages the sameElijah Newren
The conversion of the script version of rebase took messages that were prefixed with "error:" and passed them along to die(), which adds a "fatal:" prefix, thus resulting in messages of the form: fatal: error: cannot combine... which seems redundant. Remove the "error:" prefix from the builtin version of rebase, and change the prefix from "error:" to "fatal:" in the legacy script to match. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-12-28Merge branch 'sb/more-repo-in-api' into md/list-objects-filter-by-depthJunio C Hamano
2018-12-28commit: prepare free_commit_buffer and release_commit_memory for any repoStefan Beller
Pass the object pool to free_commit_buffer and release_commit_memory, such that we can eliminate access to 'the_repository'. Also remove the TODO in release_commit_memory, as commit->util was removed in 9d2c97016f (commit.h: delete 'util' field in struct commit, 2018-05-19) Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-12-26stripspace: allow -s/-c outside git repositoryJonathan Nieder
v2.11.0-rc3~3^2~1 (stripspace: respect repository config, 2016-11-21) improved stripspace --strip-comments / --comentlines by teaching them to read repository config, but it went a little too far: when running stripspace outside any repository, the result is $ git stripspace --strip-comments <test-input fatal: not a git repository (or any parent up to mount point /tmp) That makes experimenting with the stripspace command unnecessarily fussy. Fix it by discovering the git directory gently, as intended all along. Reported-by: Han-Wen Nienhuys <hanwen@google.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-12-26submodule deinit: unset core.worktreeStefan Beller
When a submodule is deinit'd, the working tree is gone, so the setting of core.worktree is bogus. Unset it. As we covered the only other case in which a submodule loses its working tree in the earlier step (i.e. switching branches of top-level project to move to a commit that did not have the submodule), this makes the code always maintain core.worktree correctly unset when there is no working tree for a submodule. This re-introduces 984cd77ddb (submodule deinit: unset core.worktree, 2018-06-18), which was reverted as part of f178c13fda (Revert "Merge branch 'sb/submodule-core-worktree'", 2018-09-07) The whole series was reverted as the offending commit e98317508c (submodule: ensure core.worktree is set after update, 2018-06-18) was relied on by other commits such as 984cd77ddb. Keep the offending commit reverted, but its functionality came back via 4d6d6ef1fc (Merge branch 'sb/submodule-update-in-c', 2018-09-17), such that we can reintroduce 984cd77ddb now. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-12-26submodule--helper: fix BUG message in ensure_core_worktreeStefan Beller
74d4731da1 (submodule--helper: replace connect-gitdir-workingtree by ensure-core-worktree, 2018-08-13) missed to update the BUG message. Fix it. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-12-15Merge branch 'nd/show-gitcomp-compilation-fix' into maintJunio C Hamano
Portability fix for a recent update to parse-options API. * nd/show-gitcomp-compilation-fix: parse-options: fix SunCC compiler warning
2018-12-14submodule update: run at most one fetch job unless otherwise setJunio C Hamano
In a028a1930c (fetching submodules: respect `submodule.fetchJobs` config option, 2016-02-29), we made sure to keep the default behavior of fetching at most one submodule at once when not setting the newly introduced `submodule.fetchJobs` config. This regressed in 90efe595c5 (builtin/submodule--helper: factor out submodule updating, 2018-08-03). Fix it. Reported-by: Sjon Hortensius <sjon@parse.nl> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-12-12parse-options: fix SunCC compiler warningNguyễn Thái Ngọc Duy
The compiler reports this because show_gitcomp() never actually returns a value: "parse-options.c", line 520: warning: Function has no return statement : show_gitcomp We could shut the compiler up. But instead let's not bury exit() too deep. Do the same as internal -h handling, return a special error code and handle the exit() in parse_options() (and other parse_options_step() callers) instead. Reported-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-12-11rebase: introduce a shortcut for --reschedule-failed-execJohannes Schindelin
It is a bit cumbersome to write out the `--reschedule-failed-exec` option before `-x <cmd>` all the time; let's introduce a convenient option to do both at the same time: `-y <cmd>`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-12-11rebase: add a config option to default to --reschedule-failed-execJohannes Schindelin
It would be cumbersome to type out that option all the time, so let's offer the convenience of a config setting: rebase.rescheduleFailedExec. Besides, this opens the door to changing the default in a future version of Git: it does make some sense to reschedule failed `exec` commands by default (and if we could go back in time when the `exec` command was invented, we probably would change that default right from the start). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-12-11rebase: introduce --reschedule-failed-execJohannes Schindelin
A common use case for the `--exec` option is to verify that each commit in a topic branch compiles cleanly, via `git rebase -x make <base>`. However, when an `exec` in such a rebase fails, it is not re-scheduled, which in this instance is not particularly helpful. Let's offer a flag to reschedule failed `exec` commands. Based on an idea by Paul Morelle. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-12-10style: the opening '{' of a function is in a separate lineNguyễn Thái Ngọc Duy
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-12-09Indent code with TABsNguyễn Thái Ngọc Duy
We indent with TABs and sometimes for fine alignment, TABs followed by spaces, but never all spaces (unless the indentation is less than 8 columns). Indenting with spaces slips through in some places. Fix them. Imported code and compat/ are left alone on purpose. The former should remain as close as upstream as possible. The latter pretty much has separate maintainers, it's up to them to decide. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-12-09fetch: ensure submodule objects fetchedStefan Beller
Currently when git-fetch is asked to recurse into submodules, it dispatches a plain "git-fetch -C <submodule-dir>" (with some submodule related options such as prefix and recusing strategy, but) without any information of the remote or the tip that should be fetched. But this default fetch is not sufficient, as a newly fetched commit in the superproject could point to a commit in the submodule that is not in the default refspec. This is common in workflows like Gerrit's. When fetching a Gerrit change under review (from refs/changes/??), the commits in that change likely point to submodule commits that have not been merged to a branch yet. Fetch a submodule object by id if the object that the superproject points to, cannot be found. For now this object is fetched from the 'origin' remote as we defer getting the default remote to a later patch. A list of new submodule commits are already generated in certain conditions (by check_for_new_submodule_commits()); this new feature invokes that function in more situations. The submodule checks were done only when a ref in the superproject changed, these checks were extended to also be performed when fetching into FETCH_HEAD for completeness, and add a test for that too. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-12-06revision.c: put promisor option in specialized structMatthew DeVore
Put the allow_exclude_promisor_objects flag in setup_revision_opt. When it was in rev_info, it was unclear when it was used, since rev_info is passed to functions that don't use the flag. This resulted in unnecessary setting of the flag in prune.c, so fix that as well. Signed-off-by: Matthew DeVore <matvore@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-12-05repository: repo_submodule_init to take a submodule structStefan Beller
When constructing a struct repository for a submodule for some revision of the superproject where the submodule is not contained in the index, it may not be present in the working tree currently either. In that situation giving a 'path' argument is not useful. Upgrade the repo_submodule_init function to take a struct submodule instead. The submodule struct can be obtained via submodule_from_{path, name} or an artificial submodule struct can be passed in. While we are at it, rename the repository struct in the repo_submodule_init function, which is to be initialized, to a name that is not confused with the struct submodule as easily. Perform such renames in similar functions as well. Also move its documentation into the header file. Reviewed-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-12-04Merge branch 'es/format-patch-range-diff-fix-fix'Junio C Hamano
* es/format-patch-range-diff-fix-fix: range-diff: always pass at least minimal diff options
2018-12-04range-diff: always pass at least minimal diff optionsMartin Ågren
Commit d8981c3f88 ("format-patch: do not let its diff-options affect --range-diff", 2018-11-30) taught `show_range_diff()` to accept a NULL-pointer as an indication that it should use its own "reasonable default". That fixed a regression from a5170794 ("Merge branch 'ab/range-diff-no-patch'", 2018-11-18), but unfortunately it introduced a regression of its own. In particular, it means we forget the `file` member of the diff options, so rather than placing a range-diff in the cover-letter, we write it to stdout. In order to fix this, rewrite the two callers adjusted by d8981c3f88 to instead create a "dummy" set of diff options where they only fill in the fields we absolutely require, such as output file and color. Modify and extend the existing tests to try and verify that the right contents end up in the right place. Don't revert `show_range_diff()`, i.e., let it keep accepting NULL. Rather than removing what is dead code and figuring out it isn't actually dead and we've broken 2.20, just leave it for now. [es: retain diff coloring when going to stdout] Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-12-01Merge branch 'ab/push-example-in-doc'Junio C Hamano
An error message that sugggests how to give correct arguments to "git push" has been updated. * ab/push-example-in-doc: push: change needlessly ambiguous example in error
2018-12-01Merge branch 'rt/rebase-in-c-message-fix'Junio C Hamano
* rt/rebase-in-c-message-fix: builtin/rebase.c: remove superfluous space in messages
2018-12-01Merge branch 'ab/replace-graft-with-replace-advice'Junio C Hamano
The advice message to tell the user to migrate an existing graft file to the replace system when a graft file was read was shown even when "git replace --convert-graft-file" command, which is the way the message suggests to use, was running, which made little sense. * ab/replace-graft-with-replace-advice: advice: don't pointlessly suggest --convert-graft-file
2018-12-01Merge branch 'js/rebase-stat-unrelated-fix'Junio C Hamano
"git rebase --stat" to transplant a piece of history onto a totally unrelated history were not working before and silently showed wrong result. With the recent reimplementation in C, it started to instead die with an error message, as the original logic was not prepared to cope with this case. This has now been fixed. * js/rebase-stat-unrelated-fix: rebase --stat: fix when rebasing to an unrelated history
2018-12-01Merge branch 'js/rebase-reflog-action-fix'Junio C Hamano
"git rebase" reimplemented recently in C accidentally changed the way reflog entries are recorded (earlier "rebase -i" identified the entries it leaves with "rebase -i", but the new version always marks them with "rebase"). This has been corrected. * js/rebase-reflog-action-fix: rebase: fix GIT_REFLOG_ACTION regression
2018-12-01builtin/rebase.c: remove superfluous space in messagesRalf Thielow
The whitespace breakages in these messages were introduced while reimplementing the subcommand in C. Match these messages to those in the original scripted version. Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com> Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-30rebase --stat: fix when rebasing to an unrelated historyJohannes Schindelin
When rebasing to a commit history that has no common commits with the current branch, there is no merge base. In diffstat mode, this means that we cannot compare to the merge base, but we have to compare to the empty tree instead. Also, if running in verbose diffstat mode, we should not output Changes from <merge-base> to <onto> as that does not make sense without any merge base. Note: neither scripted nor built-in versoin of `git rebase` were prepared for this situation well. We use this opportunity not only to fix the bug(s), but also to make both versions' output consistent in this instance. And add a regression test to keep this working in all eternity. Reported-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-30rebase: fix GIT_REFLOG_ACTION regressionJohannes Schindelin
The scripted version of "rebase" honored the `GIT_REFLOG_ACTION`, and some automation scripts expected the reflog entries to be prefixed with "rebase -i", not "rebase", after running "rebase -i". This regressed in the reimplementation in C. Fix that, and add a regression test, both with `GIT_REFLOG_ACTION` set and unset. Note: the reflog message for "rebase finished" did *not* honor GIT_REFLOG_ACTION, and as we are very late in the v2.20.0-rcN phase, we leave that bug for later (as it seems that that bug has been with us from the very beginning). Reported by Ian Jackson. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-30format-patch: do not let its diff-options affect --range-diffJunio C Hamano
Stop leaking how the primary output of format-patch is customized to the range-diff machinery and instead let the latter use its own "reasonable default", in order to correct the breakage introduced by a5170794 ("Merge branch 'ab/range-diff-no-patch'", 2018-11-18) on the 'master' front. "git format-patch --range-diff..." without any weird diff option started to include the "range-diff --stat" output, which is rather useless right now, that made the whole thing unusable and this is probably the least disruptive way to whip the codebase into a shippable shape. We may want to later make the range-diff driven by format-patch more configurable, but that would have to wait until we have a good design. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-29advice: don't pointlessly suggest --convert-graft-fileÆvar Arnfjörð Bjarmason
The advice to run 'git replace --convert-graft-file' added in f9f99b3f7d ("Deprecate support for .git/info/grafts", 2018-04-29) didn't add an exception for the 'git replace --convert-graft-file' codepath itself. As a result we'd suggest running --convert-graft-file while the user was running --convert-graft-file, which makes no sense. Before: $ git replace --convert-graft-file hint: Support for <GIT_DIR>/info/grafts is deprecated hint: and will be removed in a future Git version. hint: hint: Please use "git replace --convert-graft-file" hint: to convert the grafts into replace refs. hint: hint: Turn this message off by running hint: "git config advice.graftFileDeprecated false" Add a check for that case and skip printing the advice while the user is busy following our advice. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-21Merge branch 'tq/branch-style-fix' into maintJunio C Hamano
Code clean-up. * tq/branch-style-fix: branch: trivial style fix
2018-11-21Merge branch 'tq/branch-create-wo-branch-get' into maintJunio C Hamano
Code clean-up. * tq/branch-create-wo-branch-get: builtin/branch.c: remove useless branch_get
2018-11-21Merge branch 'jk/check-everything-connected-is-long-gone' into maintJunio C Hamano
Comment fix. * jk/check-everything-connected-is-long-gone: receive-pack: update comment with check_everything_connected
2018-11-21Merge branch 'en/double-semicolon-fix' into maintJunio C Hamano
Code clean-up. * en/double-semicolon-fix: Remove superfluous trailing semicolons
2018-11-21Merge branch 'tb/void-check-attr' into maintJunio C Hamano
Code clean-up. * tb/void-check-attr: Make git_check_attr() a void function