summaryrefslogtreecommitdiff
path: root/builtin
AgeCommit message (Collapse)AuthorFilesLines
2016-10-27Merge branch 'nd/ita-empty-commit'Libravatar Junio C Hamano1-4/+9
When new paths were added by "git add -N" to the index, it was enough to circumvent the check by "git commit" to refrain from making an empty commit without "--allow-empty". The same logic prevented "git status" to show such a path as "new file" in the "Changes not staged for commit" section. * nd/ita-empty-commit: commit: don't be fooled by ita entries when creating initial commit commit: fix empty commit creation when there's no changes but ita entries diff: add --ita-[in]visible-in-index diff-lib: allow ita entries treated as "not yet exist in index"
2016-10-27Merge branch 'js/prepare-sequencer'Libravatar Junio C Hamano2-25/+23
Update of the sequencer codebase to make it reusable to reimplement "rebase -i" continues. * js/prepare-sequencer: (27 commits) sequencer: mark all error messages for translation sequencer: start error messages consistently with lower case sequencer: quote filenames in error messages sequencer: mark action_name() for translation sequencer: remove overzealous assumption in rebase -i mode sequencer: teach write_message() to append an optional LF sequencer: refactor write_message() to take a pointer/length sequencer: roll back lock file if write_message() failed sequencer: stop releasing the strbuf in write_message() sequencer: left-trim lines read from the script sequencer: support cleaning up commit messages sequencer: support amending commits sequencer: allow editing the commit message on a case-by-case basis sequencer: introduce a helper to read files written by scripts sequencer: prepare for rebase -i's commit functionality sequencer: remember the onelines when parsing the todo file sequencer: get rid of the subcommand field sequencer: avoid completely different messages for different actions sequencer: strip CR from the todo script sequencer: completely revamp the "todo" script parsing ...
2016-10-27Merge branch 'sb/submodule-ignore-trailing-slash'Libravatar Junio C Hamano1-2/+6
A minor regression fix for "git submodule". * sb/submodule-ignore-trailing-slash: t0060: sidestep surprising path mangling results on Windows submodule: ignore trailing slash in relative url submodule: ignore trailing slash on superproject URL
2016-10-27Merge branch 'jk/no-looking-at-dotgit-outside-repo'Libravatar Junio C Hamano2-16/+11
Update "git diff --no-index" codepath not to try to peek into .git/ directory that happens to be under the current directory, when we know we are operating outside any repository. * jk/no-looking-at-dotgit-outside-repo: diff: handle sha1 abbreviations outside of repository diff_aligned_abbrev: use "struct oid" diff_unique_abbrev: rename to diff_aligned_abbrev find_unique_abbrev: use 4-buffer ring test-*-cache-tree: setup git dir read info/{attributes,exclude} only when in repository
2016-10-27Merge branch 'jc/abbrev-auto'Libravatar Junio C Hamano1-16/+21
"git push" and "git fetch" reports from what old object to what new object each ref was updated, using abbreviated refnames, and they attempt to align the columns for this and other pieces of information. The way these codepaths compute how many display columns to allocate for the object names portion of this output has been updated to match the recent "auto scale the default abbreviation length" change. * jc/abbrev-auto: transport: compute summary-width dynamically transport: allow summary-width to be computed dynamically fetch: pass summary_width down the callchain transport: pass summary_width down the callchain
2016-10-27Merge branch 'lt/abbrev-auto'Libravatar Junio C Hamano2-2/+6
Allow the default abbreviation length, which has historically been 7, to scale as the repository grows. The logic suggests to use 12 hexdigits for the Linux kernel, and 9 to 10 for Git itself. * lt/abbrev-auto: abbrev: auto size the default abbreviation abbrev: prepare for new world order abbrev: add FALLBACK_DEFAULT_ABBREV to prepare for auto sizing
2016-10-26find_unique_abbrev: use 4-buffer ringLibravatar Jeff King2-16/+11
Some code paths want to format multiple abbreviated sha1s in the same output line. Because we use a single static buffer for our return value, they have to either break their output into several calls or allocate their own arrays and use find_unique_abbrev_r(). Intead, let's mimic sha1_to_hex() and use a ring of several buffers, so that the return value stays valid through multiple calls. This shortens some of the callers, and makes it harder to for them to make a silly mistake. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-26Merge branch 'jk/diff-submodule-diff-inline'Libravatar Junio C Hamano1-1/+1
A recently graduated topic regressed "git rev-list --header" output, breaking "gitweb". This has been fixed. * jk/diff-submodule-diff-inline: rev-list: use hdr_termination instead of a always using a newline
2016-10-26Merge branch 'jk/fetch-quick-tag-following'Libravatar Junio C Hamano1-4/+7
When fetching from a remote that has many tags that are irrelevant to branches we are following, we used to waste way too many cycles when checking if the object pointed at by a tag (that we are not going to fetch!) exists in our repository too carefully. * jk/fetch-quick-tag-following: fetch: use "quick" has_sha1_file for tag following
2016-10-26Merge branch 'jk/merge-base-fork-point-without-reflog'Libravatar Junio C Hamano1-0/+3
"git rebase" immediately after "git clone" failed to find the fork point from the upstream. * jk/merge-base-fork-point-without-reflog: merge-base: handle --fork-point without reflog
2016-10-26Merge branch 'bw/ls-files-recurse-submodules'Libravatar Junio C Hamano1-40/+141
"git ls-files" learned "--recurse-submodules" option that can be used to get a listing of tracked files across submodules (i.e. this only works with "--cached" option, not for listing untracked or ignored files). This would be a useful tool to sit on the upstream side of a pipe that is read with xargs to work on all working tree files from the top-level superproject. * bw/ls-files-recurse-submodules: ls-files: add pathspec matching for submodules ls-files: pass through safe options for --recurse-submodules ls-files: optionally recurse into submodules git: make super-prefix option
2016-10-26Merge branch 'js/libify-require-clean-work-tree'Libravatar Junio C Hamano1-68/+3
The require_clean_work_tree() helper was recreated in C when "git pull" was rewritten from shell; the helper is now made available to other callers in preparation for upcoming "rebase -i" work. * js/libify-require-clean-work-tree: wt-status: begin error messages with lower-case wt-status: teach has_{unstaged,uncommitted}_changes() about submodules wt-status: export also the has_un{staged,committed}_changes() functions wt-status: make the require_clean_work_tree() function reusable pull: make code more similar to the shell script again pull: drop confusing prefix parameter of die_on_unclean_work_tree()
2016-10-24commit: don't be fooled by ita entries when creating initial commitLibravatar Nguyễn Thái Ngọc Duy1-3/+8
ita entries are dropped at tree generation phase. If the entire index consists of just ita entries, the result would be a a commit with no entries, which should be caught unless --allow-empty is specified. The test "!!active_nr" is not sufficient to catch this. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-24commit: fix empty commit creation when there's no changes but ita entriesLibravatar Nguyễn Thái Ngọc Duy1-1/+1
If i-t-a entries are present and there is no change between the index and HEAD i-t-a entries, index_differs_from() still returns "dirty, new entries" (aka, the resulting commit is not empty), but cache-tree will skip i-t-a entries and produce the exact same tree of current commit. index_differs_from() is supposed to catch this so we can abort git-commit (unless --no-empty is specified). Update it to optionally ignore i-t-a entries when doing a diff between the index and HEAD so that it would return "no change" in this case and abort commit. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21transport: allow summary-width to be computed dynamicallyLibravatar Junio C Hamano1-2/+2
Now we have identified three callchains that have a set of refs that they want to show their <old, new> object names in an aligned output, we can replace their reference to the constant TRANSPORT_SUMMARY_WIDTH with a helper function call to transport_summary_width() that takes the set of ref as a parameter. This step does not yet iterate over the refs and compute, which is left as an exercise to the readers. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21fetch: pass summary_width down the callchainLibravatar Junio C Hamano1-16/+21
The leaf function on the "fetch" side that uses TRANSPORT_SUMMARY_WIDTH constant is builtin/fetch.c::format_display() and it has two distinct callchains. The one that reports the primary result of fetch originates at store_updated_refs(); the other one that reports the pruning of the remote-tracking refs originates at prune_refs(). Teach these two places to pass summary_width down the callchain, just like we did for the "push" side in the previous commit. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21sequencer: get rid of the subcommand fieldLibravatar Johannes Schindelin1-20/+16
The subcommands are used exactly once, at the very beginning of sequencer_pick_revisions(), to determine what to do. This is an unnecessary level of indirection: we can simply call the correct function to begin with. So let's do that. While at it, ensure that the subcommands return an error code so that they do not have to die() all over the place (bad practice for library functions...). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-21sequencer: plug memory leaks for the option valuesLibravatar Johannes Schindelin1-0/+4
The sequencer is our attempt to lib-ify cherry-pick. Yet it behaves like a one-shot command when it reads its configuration: memory is allocated and released only when the command exits. This is kind of okay for git-cherry-pick, which *is* a one-shot command. All the work to make the sequencer its work horse was done to allow using the functionality as a library function, though, including proper clean-up after use. To remedy that, take custody of the option values in question, allocating and duping literal constants as needed and freeing them at end. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-20rev-list: use hdr_termination instead of a always using a newlineLibravatar Jacob Keller1-1/+1
When adding support for prefixing output of log and other commands using --line-prefix, commit 660e113ce118 ("graph: add support for --line-prefix on all graph-aware output", 2016-08-31) accidentally broke rev-list --header output. In order to make the output appear with a line-prefix, the flow was changed to always use the graph subsystem for display. Unfortunately the graph flow in rev-list did not use info->hdr_termination as it was assumed that graph output would never need to putput NULs. Since we now always use the graph code in order to handle the case of line-prefix, simply replace putchar('\n') with putchar(info->hdr_termination) which will correct this issue. Add a test for the --header case to make sure we don't break it in the future. Reported-by: Dennis Kaarsemaker <dennis@kaarsemaker.net> Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-17Merge branch 'js/reset-usage'Libravatar Junio C Hamano1-1/+1
* js/reset-usage: reset: fix usage
2016-10-17Merge branch 'jk/quarantine-received-objects'Libravatar Junio C Hamano1-1/+40
In order for the receiving end of "git push" to inspect the received history and decide to reject the push, the objects sent from the sending end need to be made available to the hook and the mechanism for the connectivity check, and this was done traditionally by storing the objects in the receiving repository and letting "git gc" to expire it. Instead, store the newly received objects in a temporary area, and make them available by reusing the alternate object store mechanism to them only while we decide if we accept the check, and once we decide, either migrate them to the repository or purge them immediately. * jk/quarantine-received-objects: tmp-objdir: do not migrate files starting with '.' tmp-objdir: put quarantine information in the environment receive-pack: quarantine objects until pre-receive accepts tmp-objdir: introduce API for temporary object directories check_connected: accept an env argument
2016-10-17Merge branch 'jk/alt-odb-cleanup'Libravatar Junio C Hamano3-16/+17
Codepaths involved in interacting alternate object store have been cleaned up. * jk/alt-odb-cleanup: alternates: use fspathcmp to detect duplicates sha1_file: always allow relative paths to alternates count-objects: report alternates via verbose mode fill_sha1_file: write into a strbuf alternates: store scratch buffer as strbuf fill_sha1_file: write "boring" characters alternates: use a separate scratch space alternates: encapsulate alt->base munging alternates: provide helper for allocating alternate alternates: provide helper for adding to alternates list link_alt_odb_entry: refactor string handling link_alt_odb_entry: handle normalize_path errors t5613: clarify "too deep" recursion tests t5613: do not chdir in main process t5613: whitespace/style cleanups t5613: use test_must_fail t5613: drop test_valid_repo function t5613: drop reachable_via function
2016-10-17Merge branch 'jk/clone-copy-alternates-fix'Libravatar Junio C Hamano1-2/+5
"git clone" of a local repository can be done at the filesystem level, but the codepath did not check errors while copying and adjusting the file that lists alternate object stores. * jk/clone-copy-alternates-fix: clone: detect errors in normalize_path_copy
2016-10-17sequencer: use memoized sequencer directory pathLibravatar Johannes Schindelin1-1/+1
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-17sequencer: use static initializers for replay_optsLibravatar Johannes Schindelin1-4/+2
This change is not completely faithful: instead of initializing all fields to 0, we choose to initialize command and subcommand to -1 (instead of defaulting to REPLAY_REVERT and REPLAY_NONE, respectively). Practically, it makes no difference at all, but future-proofs the code to require explicit assignments for both fields. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-14fetch: use "quick" has_sha1_file for tag followingLibravatar Jeff King1-4/+7
When we auto-follow tags in a fetch, we look at all of the tags advertised by the remote and fetch ones where we don't already have the tag, but we do have the object it peels to. This involves a lot of calls to has_sha1_file(), some of which we can reasonably expect to fail. Since 45e8a74 (has_sha1_file: re-check pack directory before giving up, 2013-08-30), this may cause many calls to reprepare_packed_git(), which is potentially expensive. This has gone unnoticed for several years because it requires a fairly unique setup to matter: 1. You need to have a lot of packs on the client side to make reprepare_packed_git() expensive (the most expensive part is finding duplicates in an unsorted list, which is currently quadratic). 2. You need a large number of tag refs on the server side that are candidates for auto-following (i.e., that the client doesn't have). Each one triggers a re-read of the pack directory. 3. Under normal circumstances, the client would auto-follow those tags and after one large fetch, (2) would no longer be true. But if those tags point to history which is disconnected from what the client otherwise fetches, then it will never auto-follow, and those candidates will impact it on every fetch. So when all three are true, each fetch pays an extra O(nr_tags * nr_packs^2) cost, mostly in string comparisons on the pack names. This was exacerbated by 47bf4b0 (prepare_packed_git_one: refactor duplicate-pack check, 2014-06-30) which uses a slightly more expensive string check, under the assumption that the duplicate check doesn't happen very often (and it shouldn't; the real problem here is how often we are calling reprepare_packed_git()). This patch teaches fetch to use HAS_SHA1_QUICK to sacrifice accuracy for speed, in cases where we might be racy with a simultaneous repack. This is similar to the fix in 0eeb077 (index-pack: avoid excessive re-reading of pack directory, 2015-06-09). As with that case, it's OK for has_sha1_file() occasionally say "no I don't have it" when we do, because the worst case is not a corruption, but simply that we may fail to auto-follow a tag that points to it. Here are results from the included perf script, which sets up a situation similar to the one described above: Test HEAD^ HEAD ---------------------------------------------------------- 5550.4: fetch 11.21(10.42+0.78) 0.08(0.04+0.02) -99.3% Reported-by: Vegard Nossum <vegard.nossum@oracle.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-12merge-base: handle --fork-point without reflogLibravatar Jeff King1-0/+3
The --fork-point option looks in the reflog to try to find where a derived branch forked from a base branch. However, if the reflog for the base branch is totally empty (as it commonly is right after cloning, which does not write a reflog entry), then our for_each_reflog call will not find any entries, and we will come up with no merge base, even though there may be one with the current tip of the base. We can fix this by just adding the current tip to our list of collected entries. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-11reset: fix usageLibravatar Johannes Schindelin1-1/+1
The <tree-ish> parameter is actually optional (see man page). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-10Merge branch 'jc/blame-reverse'Libravatar Junio C Hamano1-2/+40
It is a common mistake to say "git blame --reverse OLD path", expecting that the command line is dwimmed as if asking how lines in path in an old revision OLD have survived up to the current commit. * jc/blame-reverse: blame: dwim "blame --reverse OLD" as "blame --reverse OLD.." blame: improve diagnosis for "--reverse NEW"
2016-10-10Merge branch 'nd/shallow-deepen'Libravatar Junio C Hamano3-16/+85
The existing "git fetch --depth=<n>" option was hard to use correctly when making the history of an existing shallow clone deeper. A new option, "--deepen=<n>", has been added to make this easier to use. "git clone" also learned "--shallow-since=<date>" and "--shallow-exclude=<tag>" options to make it easier to specify "I am interested only in the recent N months worth of history" and "Give me only the history since that version". * nd/shallow-deepen: (27 commits) fetch, upload-pack: --deepen=N extends shallow boundary by N commits upload-pack: add get_reachable_list() upload-pack: split check_unreachable() in two, prep for get_reachable_list() t5500, t5539: tests for shallow depth excluding a ref clone: define shallow clone boundary with --shallow-exclude fetch: define shallow boundary with --shallow-exclude upload-pack: support define shallow boundary by excluding revisions refs: add expand_ref() t5500, t5539: tests for shallow depth since a specific date clone: define shallow clone boundary based on time with --shallow-since fetch: define shallow boundary with --shallow-since upload-pack: add deepen-since to cut shallow repos based on time shallow.c: implement a generic shallow boundary finder based on rev-list fetch-pack: use a separate flag for fetch in deepening mode fetch-pack.c: mark strings for translating fetch-pack: use a common function for verbose printing fetch-pack: use skip_prefix() instead of starts_with() upload-pack: move rev-list code out of check_non_tip() upload-pack: make check_non_tip() clean things up on error upload-pack: tighten number parsing at "deepen" lines ...
2016-10-10Merge branch 'jk/pack-objects-optim-mru'Libravatar Junio C Hamano2-5/+92
"git pack-objects" in a repository with many packfiles used to spend a lot of time looking for/at objects in them; the accesses to the packfiles are now optimized by checking the most-recently-used packfile first. * jk/pack-objects-optim-mru: pack-objects: use mru list when iterating over packs pack-objects: break delta cycles before delta-search phase sha1_file: make packed_object_info public provide an initializer for "struct object_info"
2016-10-10Merge branch 'rs/qsort'Libravatar Junio C Hamano10-31/+19
We call "qsort(array, nelem, sizeof(array[0]), fn)", and most of the time third parameter is redundant. A new QSORT() macro lets us omit it. * rs/qsort: show-branch: use QSORT use QSORT, part 2 coccicheck: use --all-includes by default remove unnecessary check before QSORT use QSORT add QSORT
2016-10-10receive-pack: quarantine objects until pre-receive acceptsLibravatar Jeff King1-1/+40
When a client pushes objects to us, index-pack checks the objects themselves and then installs them into place. If we then reject the push due to a pre-receive hook, we cannot just delete the packfile; other processes may be depending on it. We have to do a normal reachability check at this point via `git gc`. But such objects may hang around for weeks due to the gc.pruneExpire grace period. And worse, during that time they may be exploded from the pack into inefficient loose objects. Instead, this patch teaches receive-pack to put the new objects into a "quarantine" temporary directory. We make these objects available to the connectivity check and to the pre-receive hook, and then install them into place only if it is successful (and otherwise remove them as tempfiles). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-10alternates: use fspathcmp to detect duplicatesLibravatar Jeff King1-0/+2
On a case-insensitive filesystem, we should realize that "a/objects" and "A/objects" are the same path. We already use fspathcmp() to check against the main object directory, but until recently we couldn't use it for comparing against other alternates (because their paths were not NUL-terminated strings). But now we can, so let's do so. Note that we also need to adjust count-objects to load the config, so that it can see the setting of core.ignorecase (this is required by the test, but is also a general bugfix for users of count-objects). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-10count-objects: report alternates via verbose modeLibravatar Jeff King1-0/+10
There's no way to get the list of alternates that git computes internally; our tests only infer it based on which objects are available. In addition to testing, knowing this list may be helpful for somebody debugging their alternates setup. Let's add it to the "count-objects -v" output. We could give it a separate flag, but there's not really any need. "count-objects -v" is already a debugging catch-all for the object database, its output is easily extensible to new data items, and printing the alternates is not expensive (we already had to find them to count the objects). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-10alternates: use a separate scratch spaceLibravatar Jeff King2-16/+5
The alternate_object_database struct uses a single buffer both for storing the path to the alternate, and as a scratch buffer for forming object names. This is efficient (since otherwise we'd end up storing the path twice), but it makes life hard for callers who just want to know the path to the alternate. They have to remember to stop reading after "alt->name - alt->base" bytes, and to subtract one for the trailing '/'. It would be much simpler if they could simply access a NUL-terminated path string. We could encapsulate this in a function which puts a NUL in the scratch buffer and returns the string, but that opens up questions about the lifetime of the result. The first time another caller uses the alternate, the scratch buffer may get other data tacked onto it. Let's instead just store the root path separately from the scratch buffer. There aren't enough alternates being stored for the duplicated data to matter for performance, and this keeps things simple and safe for the callers. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-10submodule: ignore trailing slash in relative urlLibravatar Stefan Beller1-0/+2
This is similar to the previous patch, though no user reported a bug and I could not find a regressive behavior. However it is a good thing to be strict on the output and for that we always omit a trailing slash. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-10submodule: ignore trailing slash on superproject URLLibravatar Stefan Beller1-2/+4
Before 63e95beb0 (2016-04-15, submodule: port resolve_relative_url from shell to C), it did not matter if the superprojects URL had a trailing slash or not. It was just chopped off as one of the first steps (The "remoteurl=${remoteurl%/}" near the beginning of resolve_relative_url(), which was removed in said commit). When porting this to the C version, an off-by-one error was introduced and we did not check the actual last character to be a slash, but the NULL delimiter. Reintroduce the behavior from before 63e95beb0, to ignore the trailing slash. Reported-by: <venv21@gmail.com> Helped-by: Dennis Kaarsemaker <dennis@kaarsemaker.net> Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-10ls-files: add pathspec matching for submodulesLibravatar Brandon Williams1-6/+21
Pathspecs can be a bit tricky when trying to apply them to submodules. The main challenge is that the pathspecs will be with respect to the superproject and not with respect to paths in the submodule. The approach this patch takes is to pass in the identical pathspec from the superproject to the submodule in addition to the submodule-prefix, which is the path from the root of the superproject to the submodule, and then we can compare an entry in the submodule prepended with the submodule-prefix to the pathspec in order to determine if there is a match. This patch also permits the pathspec logic to perform a prefix match against submodules since a pathspec could refer to a file inside of a submodule. Due to limitations in the wildmatch logic, a prefix match is only done literally. If any wildcard character is encountered we'll simply punt and produce a false positive match. More accurate matching will be done once inside the submodule. This is due to the superproject not knowing what files could exist in the submodule. Signed-off-by: Brandon Williams <bmwill@google.com> Reviewed-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-10ls-files: pass through safe options for --recurse-submodulesLibravatar Brandon Williams1-3/+27
Pass through some known-safe options when recursing into submodules. (--cached, -v, -t, -z, --debug, --eol) Signed-off-by: Brandon Williams <bmwill@google.com> Reviewed-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-10ls-files: optionally recurse into submodulesLibravatar Brandon Williams1-38/+100
Allow ls-files to recognize submodules in order to retrieve a list of files from a repository's submodules. This is done by forking off a process to recursively call ls-files on all submodules. Use top-level --super-prefix option to pass a path to the submodule which it can use to prepend to output or pathspec matching logic. Signed-off-by: Brandon Williams <bmwill@google.com> Reviewed-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-07wt-status: teach has_{unstaged,uncommitted}_changes() about submodulesLibravatar Johannes Schindelin1-1/+1
Sometimes we are *actually* interested in those changes... For example when an interactive rebase wants to continue with a staged submodule update. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-07wt-status: make the require_clean_work_tree() function reusableLibravatar Johannes Schindelin1-76/+1
The function used by "git pull" to stop the user when the working tree has changes is useful in other places. Let's move it into a more prominent (and into an actually reusable) spot: wt-status.[ch]. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-07pull: make code more similar to the shell script againLibravatar Johannes Schindelin1-10/+20
When converting the pull command to a builtin, the require_clean_work_tree() function was renamed and the pull-specific parts hard-coded. This makes it impossible to reuse the code, so let's modify the code to make it more similar to the original shell script again. Note: when the hint "Please commit or stash them" was introduced first, Git did not have the convention of continuing error messages in lower case, but now we do have that convention, therefore we reintroduce this hint down-cased, obeying said convention. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-07pull: drop confusing prefix parameter of die_on_unclean_work_tree()Libravatar Johannes Schindelin1-8/+8
In cmd_pull(), when verifying that there are no changes preventing a rebasing pull, we diligently pass the prefix parameter to the die_on_unclean_work_tree() function which in turn diligently passes it to the has_unstaged_changes() and has_uncommitted_changes() functions. The casual reader might now be curious (as this developer was) whether that means that calling `git pull --rebase` in a subdirectory will ignore unstaged changes in other parts of the working directory. And be puzzled that `git pull --rebase` (correctly) complains about those changes outside of the current directory. The puzzle is easily resolved: while we take pains to pass around the prefix and even pass it to init_revisions(), the fact that no paths are passed to init_revisions() ensures that the prefix is simply ignored. That, combined with the fact that we will *always* want a *full* working directory check before running a rebasing pull, is reason enough to simply do away with the actual prefix parameter and to pass NULL instead, as if we were running this from the top-level working directory anyway. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-06Merge branch 'rs/cocci'Libravatar Junio C Hamano1-1/+1
Code clean-up with help from coccinelle tool continues. * rs/cocci: coccicheck: make transformation for strbuf_addf(sb, "...") more precise use strbuf_add_unique_abbrev() for adding short hashes, part 2 use strbuf_addstr() instead of strbuf_addf() with "%s", part 2 gitignore: ignore output files of coccicheck make target
2016-10-06Merge branch 'jc/blame-abbrev'Libravatar Junio C Hamano1-1/+1
Almost everybody uses DEFAULT_ABBREV to refer to the default setting for the abbreviation, but "git blame" peeked into underlying variable bypassing the macro for no good reason. * jc/blame-abbrev: blame: use DEFAULT_ABBREV macro
2016-10-06Merge branch 'vn/revision-shorthand-for-side-branch-log'Libravatar Junio C Hamano1-13/+41
"git log rev^..rev" is an often-used revision range specification to show what was done on a side branch merged at rev. This has gained a short-hand "rev^-1". In general "rev^-$n" is the same as "^rev^$n rev", i.e. what has happened on other branches while the history leading to nth parent was looking the other way. * vn/revision-shorthand-for-side-branch-log: revision: new rev^-n shorthand for rev^n..rev
2016-10-06Merge branch 'jk/ambiguous-short-object-names'Libravatar Junio C Hamano2-2/+4
When given an abbreviated object name that is not (or more realistically, "no longer") unique, we gave a fatal error "ambiguous argument". This error is now accompanied by hints that lists the objects that begins with the given prefix. During the course of development of this new feature, numerous minor bugs were uncovered and corrected, the most notable one of which is that we gave "short SHA1 xxxx is ambiguous." twice without good reason. * jk/ambiguous-short-object-names: get_short_sha1: make default disambiguation configurable get_short_sha1: list ambiguous objects on error for_each_abbrev: drop duplicate objects sha1_array: let callbacks interrupt iteration get_short_sha1: mark ambiguity error for translation get_short_sha1: NUL-terminate hex prefix get_short_sha1: refactor init of disambiguation code get_short_sha1: parse tags when looking for treeish get_sha1: propagate flags to child functions get_sha1: avoid repeating ourselves via ONLY_TO_DIE get_sha1: detect buggy calls with multiple disambiguators
2016-10-05clone: detect errors in normalize_path_copyLibravatar Jeff King1-2/+5
When we are copying the alternates from the source repository, if we find a relative path that is too deep for the source (e.g., "../../../objects" from "/repo.git/objects"), then normalize_path_copy will report an error and leave trash in the buffer, which we will add to our new alternates file. Instead, let's detect the error, print a warning, and skip copying that alternate. There's no need to die. The relative path is probably just broken cruft in the source repo. If it turns out to have been important for accessing some objects, we rely on other parts of the clone to detect that, just as they would with a missing object in the source repo itself (though note that clones with "-s" are inherently local, which may do fewer object-quality checks in the first place). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>