summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2015-09-17ref-filter: add support for %(contents:lines=X)Libravatar Karthik Nayak5-6/+103
In 'tag.c' we can print N lines from the annotation of the tag using the '-n<num>' option. Copy code from 'tag.c' to 'ref-filter' and modify it to support appending of N lines from the annotation of tags to the given strbuf. Implement %(contents:lines=X) where X lines of the given object are obtained. While we're at it, remove unused "contents:<suboption>" atoms from the `valid_atom` array. Add documentation and test for the same. Mentored-by: Christian Couder <christian.couder@gmail.com> Mentored-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr> Signed-off-by: Karthik Nayak <karthik.188@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-17ref-filter: add option to filter out tags, branches and remotesLibravatar Karthik Nayak4-7/+81
Add a function called 'for_each_fullref_in()' to refs.{c,h} which iterates through each ref for the given path without trimming the path and also accounting for broken refs, if mentioned. Add 'filter_ref_kind()' in ref-filter.c to check the kind of ref being handled and return the kind to 'ref_filter_handler()', where we discard refs which we do not need and assign the kind to needed refs. Mentored-by: Christian Couder <christian.couder@gmail.com> Mentored-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr> Signed-off-by: Karthik Nayak <karthik.188@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-17ref-filter: implement an `align` atomLibravatar Karthik Nayak3-1/+202
Implement an `align` atom which left-, middle-, or right-aligns the content between %(align:...) and %(end). The "align:" is followed by `<width>` and `<position>` in any order separated by a comma, where the `<position>` is either left, right or middle, default being left and `<width>` is the total length of the content with alignment. If the contents length is more than the width then no alignment is performed. e.g. to align a refname atom to the middle with a total width of 40 we can do: --format="%(align:middle,40)%(refname)%(end)". We introduce an `at_end` function for each element of the stack which is to be called when the `end` atom is encountered. Using this we implement end_align_handler() for the `align` atom, this aligns the final strbuf by calling `strbuf_utf8_align()` from utf8.c. Ensure that quote formatting is performed on the whole of %(align:...)...%(end) rather than individual atoms inside. We skip quote formatting for individual atoms when the current stack element is handling an %(align:...) atom and perform quote formatting at the end when we encounter the %(end) atom of the second element of then stack. Add documentation and tests for the same. Mentored-by: Christian Couder <christian.couder@gmail.com> Mentored-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Karthik Nayak <karthik.188@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-17ref-filter: introduce match_atom_name()Libravatar Karthik Nayak2-2/+25
Introduce match_atom_name() which helps in checking if a particular atom is the atom we're looking for and if it has a value attached to it or not. Use it instead of starts_with() for checking the value of %(color:...) atom. Write a test for the same. Mentored-by: Christian Couder <christian.couder@gmail.com> Mentored-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr> Thanks-to: Junio C Hamano <gitster@pobox.com> Signed-off-by: Karthik Nayak <karthik.188@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-17ref-filter: introduce handler function for each atomLibravatar Karthik Nayak1-24/+30
Introduce a handler function for each atom, which is called when the atom is processed in show_ref_array_item(). In this context make append_atom() as the default handler function and extract quote_formatting() out of append_atom(). Bump this to the top. Mentored-by: Christian Couder <christian.couder@gmail.com> Mentored-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr> Signed-off-by: Karthik Nayak <karthik.188@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-17utf8: add function to align a string into given strbufLibravatar Karthik Nayak2-0/+36
Add strbuf_utf8_align() which will align a given string into a strbuf as per given align_type and width. If the width is greater than the string length then no alignment is performed. Helped-by: Eric Sunshine <sunshine@sunshineco.com> Mentored-by: Christian Couder <christian.couder@gmail.com> Mentored-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr> Signed-off-by: Karthik Nayak <karthik.188@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-17ref-filter: introduce ref_formatting_state and ref_formatting_stackLibravatar Karthik Nayak1-19/+59
Introduce ref_formatting_state which will hold the formatted output strbuf instead of directly printing to stdout. This will help us in creating modifier atoms which modify the format specified before printing to stdout. Implement a stack machinery for ref_formatting_state, this allows us to push and pop elements onto the stack. Whenever we pop an element from the stack, the strbuf from that element is appended to the strbuf of the next element on the stack, this will allow us to support nesting of modifier atoms. Rename some functions to reflect the changes made: print_value() -> append_atom() emit() -> append_literal() Mentored-by: Christian Couder <christian.couder@gmail.com> Mentored-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr> Signed-off-by: Karthik Nayak <karthik.188@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-17ref-filter: move `struct atom_value` to ref-filter.cLibravatar Karthik Nayak2-4/+6
Since atom_value is only required for the internal working of ref-filter it doesn't belong in the public header. Helped-by: Eric Sunshine <sunshine@sunshineco.com> Mentored-by: Christian Couder <christian.couder@gmail.com> Mentored-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr> Signed-off-by: Karthik Nayak <karthik.188@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-17strtoul_ui: reject negative valuesLibravatar Matthieu Moy1-0/+3
strtoul_ui uses strtoul to get a long unsigned, then checks that casting to unsigned does not lose information and return the casted value. On 64 bits architecture, checking that the cast does not change the value catches most errors, but when sizeof(int) == sizeof(long) (e.g. i386), the check does nothing. Unfortunately, strtoul silently accepts negative values, and as a result strtoul_ui("-1", ...) raised no error. This patch catches negative values before it's too late, i.e. before calling strtoul. Reported-by: Max Kirillov <max@max630.net> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-24Merge 'jk/git-path' into kn/for-each-tagLibravatar Junio C Hamano30-363/+465
* jk/git-path: memoize common git-path "constant" files get_repo_path: refactor path-allocation find_hook: keep our own static buffer refs.c: remove_empty_directories can take a strbuf refs.c: avoid git_path assignment in lock_ref_sha1_basic refs.c: avoid repeated git_path calls in rename_tmp_log refs.c: simplify strbufs in reflog setup and writing path.c: drop git_path_submodule refs.c: remove extra git_path calls from read_loose_refs remote.c: drop extraneous local variable from migrate_file prefer mkpathdup to mkpath in assignments prefer git_pathdup to git_path in some possibly-dangerous cases add_to_alternates_file: don't add duplicate entries t5700: modernize style cache.h: complete set of git_path_submodule helpers cache.h: clarify documentation for git_path, et al
2015-08-24Merge 'kn/for-each-tag-branch' into kn/for-each-tagLibravatar Junio C Hamano9-51/+420
* kn/for-each-tag-branch: for-each-ref: add '--contains' option ref-filter: implement '--contains' option parse-options.h: add macros for '--contains' option parse-option: rename parse_opt_with_commit() for-each-ref: add '--merged' and '--no-merged' options ref-filter: implement '--merged' and '--no-merged' options ref-filter: add parse_opt_merge_filter() for-each-ref: add '--points-at' option ref-filter: implement '--points-at' option tag: libify parse_opt_points_at() t6302: for-each-ref tests for ref-filter APIs
2015-08-10memoize common git-path "constant" filesLibravatar Jeff King17-119/+151
One of the most common uses of git_path() is to pass a constant, like git_path("MERGE_MSG"). This has two drawbacks: 1. The return value is a static buffer, and the lifetime is dependent on other calls to git_path, etc. 2. There's no compile-time checking of the pathname. This is OK for a one-off (after all, we have to spell it correctly at least once), but many of these constant strings appear throughout the code. This patch introduces a series of functions to "memoize" these strings, which are essentially globals for the lifetime of the program. We compute the value once, take ownership of the buffer, and return the cached value for subsequent calls. cache.h provides a helper macro for defining these functions as one-liners, and defines a few common ones for global use. Using a macro is a little bit gross, but it does nicely document the purpose of the functions. If we need to touch them all later (e.g., because we learned how to change the git_dir variable at runtime, and need to invalidate all of the stored values), it will be much easier to have the complete list. Note that the shared-global functions have separate, manual declarations. We could do something clever with the macros (e.g., expand it to a declaration in some places, and a declaration _and_ a definition in path.c). But there aren't that many, and it's probably better to stay away from too-magical macros. Likewise, if we abandon the C preprocessor in favor of generating these with a script, we could get much fancier. E.g., normalizing "FOO/BAR-BAZ" into "git_path_foo_bar_baz". But the small amount of saved typing is probably not worth the resulting confusion to readers who want to grep for the function's definition. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-10get_repo_path: refactor path-allocationLibravatar Jeff King1-14/+29
The get_repo_path function calls mkpath() and then does some non-trivial operations on it, like calling is_git_directory() and read_gitfile(). These are actually OK (they do not use more pathname static buffers themselves), but it takes a fair bit of work to verify. Let's use our own strbuf to store the path, and we can simply reuse it for each iteration of the loop (we can even avoid rewriting the beginning part, since we are trying a series of suffixes). To make the strbuf cleanup easier, we split out a thin wrapper. As a bonus, this wrapper can factor out the canonicalization that happens in all of the early-return code paths. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-10find_hook: keep our own static bufferLibravatar Jeff King2-4/+11
The find_hook function returns the results of git_path, which is a static buffer shared by other path-related calls. Returning such a buffer is slightly dangerous, because it can be overwritten by seemingly unrelated functions. Let's at least keep our _own_ static buffer, so you can only get in trouble by calling find_hook in quick succession, which is less likely to happen and more obvious to notice. While we're at it, let's add some documentation of the function's limitations. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-10refs.c: remove_empty_directories can take a strbufLibravatar Jeff King1-19/+15
The first thing we do in this function is copy the input into a strbuf. Of the 4 callers, 3 of them already have a strbuf we could use. Let's just take the strbuf, and convert the remaining caller to use a strbuf, rather than a raw git_path. This is safer, anyway, as remove_dir_recursively is a non-trivial function that might use the pathname buffers itself (this is _probably_ OK, as the likely culprit would be calling resolve_gitlink_ref, but we do not pass the proper flags to ask it to avoid blowing away gitlinks). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-10refs.c: avoid git_path assignment in lock_ref_sha1_basicLibravatar Jeff King1-13/+19
Assigning the result of git_path is a bad pattern, because it's not immediately obvious how long you expect the content to stay valid (and it may be overwritten by subsequent calls). Let's use a function-local strbuf here instead, which we know is safe (we just have to remember to free it in all code paths). As a bonus, we get rid of a confusing variable-reuse ("ref_file" is used for two distinct purposes). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-10refs.c: avoid repeated git_path calls in rename_tmp_logLibravatar Jeff King1-7/+14
Because it's not safe to store the static-buffer results of git_path for a long time, we end up formatting the same filename over and over. We can fix this by using a function-local strbuf to store the formatted pathname and avoid repeating ourselves. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-10refs.c: simplify strbufs in reflog setup and writingLibravatar Jeff King1-23/+15
Commit 1a83c24 (git_snpath(): retire and replace with strbuf_git_path(), 2014-11-30) taught log_ref_setup and log_ref_write_1 to take a strbuf parameter, rather than a bare string. It then makes an alias to the strbuf's "buf" field under the original name. This made the original diff much shorter, but the resulting code is more complicated that it needs to be. Since we've aliased the pointer, we drop our reference to the strbuf to ensure we don't accidentally change it. But if we simply drop our alias and use "logfile.buf" directly, we do not have to worry about this aliasing. It's a larger diff, but the resulting code is simpler. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-10path.c: drop git_path_submoduleLibravatar Jeff King2-13/+2
There are no callers of the slightly-dangerous static-buffer git_path_submodule left. Let's drop it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-10refs.c: remove extra git_path calls from read_loose_refsLibravatar Jeff King1-10/+13
In iterating over the loose refs in "refs/foo/", we keep a running strbuf with "refs/foo/one", "refs/foo/two", etc. But we also need to access these files in the filesystem, as ".git/refs/foo/one", etc. For this latter purpose, we make a series of independent calls to git_path(). These are safe (we only use the result to call stat()), but assigning the result of git_path is a suspicious pattern that we'd rather avoid. This patch keeps a running buffer with ".git/refs/foo/", and we can just append/reset each directory element as we loop. This matches how we handle the refnames. It should also be more efficient, as we do not keep formatting the same ".git/refs/foo" prefix (which can be arbitrarily deep). Technically we are dropping a call to strbuf_cleanup() on each generated filename, but that's OK; it wasn't doing anything, as we are putting in single-level names we read from the filesystem (so it could not possibly be cleaning up cruft like "./" in this instance). A clever reader may also note that the running refname buffer ("refs/foo/") is actually a subset of the filesystem path buffer (".git/refs/foo/"). We could get by with one buffer, indexing the length of $GIT_DIR when we want the refname. However, having tried this, the resulting code actually ends up a little more confusing, and the efficiency improvement is tiny (and almost certainly dwarfed by the system calls we are making). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-10remote.c: drop extraneous local variable from migrate_fileLibravatar Jeff King1-5/+2
It's an anti-pattern to assign the result of git_path to a variable, since other calls may reuse our buffer. In this case, we feed the result to unlink_or_warn immediately afterwards, so it's OK. However, it's nice to avoid assignment entirely, which makes it more obvious that there's no bug. We can just pass the result directly to unlink_or_warn, which is a known-simple function. As a bonus, the code flow is a little more obvious, as we eliminate an extra conditional (a reader does not have to wonder any more "under which circumstances is 'path' set?"). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-10prefer mkpathdup to mkpath in assignmentsLibravatar Jeff King2-13/+17
As with the previous commit to git_path, assigning the result of mkpath is suspicious, since it is not clear whether we will still depend on the value after it may have been overwritten by subsequent calls. This patch converts low-hanging fruit to use mkpathdup instead of mkpath (with the downside that we must remember to free the result). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-10prefer git_pathdup to git_path in some possibly-dangerous casesLibravatar Jeff King6-11/+21
Because git_path uses a static buffer that is shared with calls to git_path, mkpath, etc, it can be dangerous to assign the result to a variable or pass it to a non-trivial function. The value may change unexpectedly due to other calls. None of the cases changed here has a known bug, but they're worth converting away from git_path because: 1. It's easy to use git_pathdup in these cases. 2. They use constructs (like assignment) that make it hard to tell whether they're safe or not. The extra malloc overhead should be trivial, as an allocation should be an order of magnitude cheaper than a system call (which we are clearly about to make, since we are constructing a filename). The real cost is that we must remember to free the result. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-10add_to_alternates_file: don't add duplicate entriesLibravatar Jeff King2-7/+45
The add_to_alternates_file function blindly uses hold_lock_file_for_append to copy the existing contents, and then adds the new line to it. This has two minor problems: 1. We might add duplicate entries, which are ugly and inefficient. 2. We do not check that the file ends with a newline, in which case we would bogusly append to the final line. This is quite unlikely in practice, though, as we call this function only from git-clone, so presumably we are the only writers of the file (and we always add a newline). Instead of using hold_lock_file_for_append, let's copy the file line by line, which ensures all records are properly terminated. If we see an extra line, we can simply abort the update (there is no point in even copying the rest, as we know that it would be identical to the original). As a bonus, we also get rid of some calls to the static-buffer mkpath and git_path functions. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-10t5700: modernize styleLibravatar Jeff King1-112/+81
The early part of this test is rather old, and does not follow our usual style guidelines. In particular: - the tests liberally chdir, and expect out-of-test "cd" commands to return them to a sane state - test commands aren't indented at all - there are a lot of minor formatting nits, like the opening quote of the test block on the wrong line, spaces after ">", etc This patch fixes the style issues, and uses a few helper functions, along with subshells and "git -C", to avoid changing the cwd of the main script. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-10cache.h: complete set of git_path_submodule helpersLibravatar Jeff King2-5/+35
The git_path function has "git_pathdup" and "strbuf_git_path" variants, but git_submodule_path only comes in the dangerous, static-buffer variant. That makes refactoring callers to use the safer functions hard (since they don't exist). Since we're already using a strbuf behind the scenes, it's easy to expose all three of these interfaces with thin wrappers. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-10cache.h: clarify documentation for git_path, et alLibravatar Jeff King1-5/+12
The comment above these functions actually describes sha1_file_name, and comes from the very first revision of git. Commit 723c31f (Add "git_path()" and "head_ref()" helper functions., 2005-07-05) added git_path, pushing the comment away from the function it describes; later commits added more functions in this block. Let's fix the comment to describe these related functions in more detail. Let's also make sure to point out their safer alternatives (and move those alternatives below, which makes more sense when reading the file). Note that we do not need to move the existing comment to sha1_file_name. Commit d40d535 (sha1_file.c: document a bunch of functions defined in the file, 2014-02-21) already added a much more descriptive comment to it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-03Sync with maintLibravatar Junio C Hamano3-4/+24
* maint: Git 2.4.8
2015-08-03First batch for 2.6Libravatar Junio C Hamano3-2/+156
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-03Merge branch 'es/doc-clean-outdated-tools'Libravatar Junio C Hamano2-117/+9
* es/doc-clean-outdated-tools: Documentation/git-tools: retire manually-maintained list Documentation/git-tools: drop references to defunct tools Documentation/git-tools: fix item text formatting Documentation/git-tools: improve discoverability of Git wiki Documentation/git: drop outdated Cogito reference
2015-08-03Merge branch 'jk/refspec-parse-wildcard'Libravatar Junio C Hamano5-30/+41
Allow an asterisk as a substring (as opposed to the entirety) of a path component for both side of a refspec, e.g. "refs/heads/o*:refs/remotes/heads/i*". * jk/refspec-parse-wildcard: refs: loosen restriction on wildcard "*" refspecs refs: cleanup comments regarding check_refname_component()
2015-08-03Merge branch 'da/subtree-date-confusion'Libravatar Junio C Hamano2-1/+5
"git subtree" (in contrib/) depended on "git log" output to be stable, which was a no-no. Apply a workaround to force a particular date format. * da/subtree-date-confusion: contrib/subtree: ignore log.date configuration
2015-08-03Merge branch 'jx/do-not-crash-receive-pack-wo-head'Libravatar Junio C Hamano1-1/+1
An attempt to delete a ref by pushing into a repositorywhose HEAD symbolic reference points at an unborn branch that cannot be created due to ref D/F conflict (e.g. refs/heads/a/b exists, HEAD points at refs/heads/a) failed. * jx/do-not-crash-receive-pack-wo-head: receive-pack: crash when checking with non-exist HEAD
2015-08-03Merge branch 'db/send-pack-user-signingkey'Libravatar Junio C Hamano1-0/+3
The low-level "git send-pack" did not honor 'user.signingkey' configuration variable when sending a signed-push. * db/send-pack-user-signingkey: builtin/send-pack.c: respect user.signingkey
2015-08-03Merge branch 'zb/userdiff-fountain'Libravatar Junio C Hamano4-0/+9
New userdiff pattern definition for fountain screenwriting markup format. * zb/userdiff-fountain: userdiff: add support for Fountain documents
2015-08-03Merge branch 'dt/refs-backend-preamble'Libravatar Junio C Hamano13-86/+239
In preparation for allowing different "backends" to store the refs in a way different from the traditional "one ref per file in $GIT_DIR or in a $GIT_DIR/packed-refs file" filesystem storage, reduce direct filesystem access to ref-like things like CHERRY_PICK_HEAD from scripts and programs. * dt/refs-backend-preamble: git-stash: use update-ref --create-reflog instead of creating files update-ref and tag: add --create-reflog arg refs: add REF_FORCE_CREATE_REFLOG flag git-reflog: add exists command refs: new public ref function: safe_create_reflog refs: break out check for reflog autocreation refs.c: add err arguments to reflog functions
2015-08-03Merge branch 'as/sparse-checkout-removal'Libravatar Junio C Hamano2-0/+56
"sparse checkout" misbehaved for a path that is excluded from the checkout when switching between branches that differ at the path. * as/sparse-checkout-removal: unpack-trees: don't update files with CE_WT_REMOVE set
2015-08-03Merge branch 'jk/date-mode-format'Libravatar Junio C Hamano28-78/+172
Teach "git log" and friends a new "--date=format:..." option to format timestamps using system's strftime(3). * jk/date-mode-format: strbuf: make strbuf_addftime more robust introduce "format" date-mode convert "enum date_mode" into a struct show-branch: use DATE_RELATIVE instead of magic number
2015-08-03Merge branch 'pt/am-tests'Libravatar Junio C Hamano4-0/+313
* pt/am-tests: t3901: test git-am encoding conversion t3418: non-interactive rebase --continue with rerere enabled t4150: tests for am --[no-]scissors t4150: am with post-applypatch hook t4150: am with pre-applypatch hook t4150: am with applypatch-msg hook t4150: am --resolved fails if index has unmerged entries t4150: am --resolved fails if index has no changes t4150: am refuses patches when paused t4151: am --abort will keep dirty index intact t4150: am fails if index is dirty t4150: am.messageid really adds the message id
2015-08-03Merge branch 'sg/bash-prompt-untracked-optim'Libravatar Junio C Hamano2-1/+26
Optimize computation of untracked status indicator by bash prompt script (in contrib/). * sg/bash-prompt-untracked-optim: bash prompt: faster untracked status indicator with untracked directories bash prompt: test untracked files status indicator with untracked dirs
2015-08-03Merge branch 'cb/uname-in-untracked'Libravatar Junio C Hamano1-1/+1
An experimental "untracked cache" feature used uname(2) in a slightly unportable way. * cb/uname-in-untracked: untracked: fix detection of uname(2) failure
2015-08-03Merge branch 'se/doc-checkout-ours-theirs'Libravatar Junio C Hamano1-0/+15
A "rebase" replays changes of the local branch on top of something else, as such they are placed in stage #3 and referred to as "theirs", while the changes in the new base, typically a foreign work, are placed in stage #2 and referred to as "ours". Clarify the "checkout --ours/--theirs". * se/doc-checkout-ours-theirs: checkout: document subtlety around --ours/--theirs
2015-08-03Merge branch 'ib/scripted-parse-opt-better-hint-string'Libravatar Junio C Hamano3-68/+92
The "rev-parse --parseopt" mode parsed the option specification and the argument hint in a strange way to allow '=' and other special characters in the option name while forbidding them from the argument hint. This made it impossible to define an option like "--pair <key>=<value>" with "pair=key=value" specification, which instead would have defined a "--pair=key <value>" option. * ib/scripted-parse-opt-better-hint-string: rev-parse --parseopt: allow [*=?!] in argument hints
2015-08-03Merge branch 'mh/fast-import-optimize-current-from'Libravatar Junio C Hamano1-12/+17
Often a fast-import stream builds a new commit on top of the previous commit it built, and it often unconditionally emits a "from" command to specify the first parent, which can be omitted in such a case. This caused fast-import to forget the tree of the previous commit and then re-read it from scratch, which was inefficient. Optimize for this common case. * mh/fast-import-optimize-current-from: fast-import: do less work when given "from" matches current branch head
2015-08-03Merge branch 'kn/tag-doc-fix'Libravatar Junio C Hamano1-1/+0
* kn/tag-doc-fix: Documentation/tag: remove double occurance of "<pattern>"
2015-08-03Merge branch 'mh/fast-import-get-mark'Libravatar Junio C Hamano3-10/+75
"git fast-import" learned to respond to the get-mark command via its cat-blob-fd interface. * mh/fast-import-get-mark: fast-import: add a get-mark command
2015-08-03Merge branch 'gr/rebase-i-drop-warn'Libravatar Junio C Hamano5-6/+338
Add "drop commit-object-name subject" command as another way to skip replaying of a commit in "rebase -i", and then punish those who do not use it (and instead just remove the lines) by throwing a warning. * gr/rebase-i-drop-warn: git rebase -i: add static check for commands and SHA-1 git rebase -i: warn about removed commits git-rebase -i: add command "drop" to remove a commit
2015-08-03Merge branch 'jc/commit-slab'Libravatar Junio C Hamano2-13/+49
Memory use reduction when commit-slab facility is used to annotate sparsely (which is not recommended in the first place). * jc/commit-slab: commit-slab: introduce slabname##_peek() function
2015-08-03Merge branch 'dt/log-follow-config'Libravatar Junio C Hamano5-2/+49
Add a new configuration variable to enable "--follow" automatically when "git log" is run with one pathspec argument. * dt/log-follow-config: log: add "log.follow" configuration variable
2015-08-03Merge branch 'gp/status-rebase-i-info'Libravatar Junio C Hamano2-31/+346
Teach "git status" to show a more detailed information regarding the "rebase -i" session in progress. * gp/status-rebase-i-info: status: add new tests for status during rebase -i status: give more information during rebase -i status: differentiate interactive from non-interactive rebases status: factor two rebase-related messages together