summaryrefslogtreecommitdiff
path: root/builtin
AgeCommit message (Collapse)AuthorFilesLines
2013-05-29Merge branch 'jn/config-ignore-inaccessible'Libravatar Junio C Hamano1-2/+2
When $HOME is misconfigured to point at an unreadable directory, we used to complain and die. This loosens the check. * jn/config-ignore-inaccessible: config: allow inaccessible configuration under $HOME
2013-05-29Merge branch 'mh/packed-refs-various'Libravatar Junio C Hamano2-2/+1
Update reading and updating packed-refs file, correcting corner case bugs. * mh/packed-refs-various: (33 commits) refs: handle the main ref_cache specially refs: change do_for_each_*() functions to take ref_cache arguments pack_one_ref(): do some cheap tests before a more expensive one pack_one_ref(): use write_packed_entry() to do the writing pack_one_ref(): use function peel_entry() refs: inline function do_not_prune() pack_refs(): change to use do_for_each_entry() refs: use same lock_file object for both ref-packing functions pack_one_ref(): rename "path" parameter to "refname" pack-refs: merge code from pack-refs.{c,h} into refs.{c,h} pack-refs: rename handle_one_ref() to pack_one_ref() refs: extract a function write_packed_entry() repack_without_ref(): write peeled refs in the rewritten file t3211: demonstrate loss of peeled refs if a packed ref is deleted refs: change how packed refs are deleted search_ref_dir(): return an index rather than a pointer repack_without_ref(): silence errors for dangling packed refs t3210: test for spurious error messages for dangling packed refs refs: change the internal reference-iteration API refs: extract a function peel_entry() ...
2013-05-29Merge branch 'as/check-ignore'Libravatar Junio C Hamano1-42/+50
Enhance "check-ignore" (1.8.2 update) to work more like "check-attr" over bidi-pipes. * as/check-ignore: t0008: use named pipe (FIFO) to test check-ignore streaming Documentation: add caveats about I/O buffering for check-{attr,ignore} check-ignore: allow incremental streaming of queries via --stdin check-ignore: move setup into cmd_check_ignore() check-ignore: add -n / --non-matching option t0008: remove duplicated test fixture data
2013-05-29Merge branch 'jh/checkout-auto-tracking'Libravatar Junio C Hamano1-20/+22
Update "git checkout foo" that DWIMs the intended "upstream" and turns it into "git checkout -t -b foo remotes/origin/foo" to correctly take existing remote definitions into account. The remote "origin" may be what uniquely map its own branch to remotes/some/where/foo but that some/where may not be "origin". * jh/checkout-auto-tracking: glossary: Update and rephrase the definition of a remote-tracking branch branch.c: Validate tracking branches with refspecs instead of refs/remotes/* t9114.2: Don't use --track option against "svn-remote"-tracking branches t7201.24: Add refspec to keep --track working t3200.39: tracking setup should fail if there is no matching refspec. checkout: Use remote refspecs when DWIMming tracking branches t2024: Show failure to use refspec when DWIMming remote branch names t2024: Add tests verifying current DWIM behavior of 'git checkout <branch>'
2013-05-29Merge branch 'jc/prune-all'Libravatar Junio C Hamano2-9/+9
We used the approxidate() parser for "--expire=<timestamp>" options of various commands, but it is better to treat --expire=all and --expire=now a bit more specially than using the current timestamp. Update "git gc" and "git reflog" with a new parsing function for expiry dates. * jc/prune-all: prune: introduce OPT_EXPIRY_DATE() and use it api-parse-options.txt: document "no-" for non-boolean options git-gc.txt, git-reflog.txt: document new expiry options date.c: add parse_expiry_date()
2013-05-06Merge branch 'jk/merge-tree-added-identically'Libravatar Junio C Hamano1-1/+5
* jk/merge-tree-added-identically: merge-tree: handle directory/empty conflict correctly
2013-05-06merge-tree: handle directory/empty conflict correctlyLibravatar John Keeping1-1/+5
git-merge-tree causes a null pointer dereference when a directory entry exists in only one or two of the three trees being compared with no corresponding entry in the other tree(s). When this happens, we want to handle the entry as a directory and not attempt to mark it as a file merge. Do this by setting the entries bit in the directory mask when the entry is missing or when it is a directory, only performing the file comparison when we know that a file entry exists. Reported-by: Andreas Jacobsen <andreas@andreasjacobsen.com> Signed-off-by: John Keeping <john@keeping.me.uk> Tested-by: Andreas Jacobsen <andreas@andreasjacobsen.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-01pack-refs: merge code from pack-refs.{c,h} into refs.{c,h}Libravatar Michael Haggerty2-2/+1
pack-refs.c doesn't contain much code, and the code it does contain is closely related to reference handling. Moreover, there is some duplication between pack_refs() and repack_without_ref(). Therefore, merge pack-refs.c into refs.c and pack-refs.h into refs.h. The code duplication will be addressed in future commits. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-01Merge branch 'tr/remote-tighten-commandline-parsing'Libravatar Junio C Hamano1-1/+1
* tr/remote-tighten-commandline-parsing: remote: 'show' and 'prune' can take more than one remote remote: check for superfluous arguments in 'git remote add' remote: add a test for extra arguments, according to docs
2013-04-28Merge branch 'jk/check-corrupt-objects-carefully'Libravatar Junio C Hamano1-1/+1
* jk/check-corrupt-objects-carefully: clone: Make the 'junk_mode' symbol a file static
2013-04-28clone: Make the 'junk_mode' symbol a file staticLibravatar Ramsay Jones1-1/+1
Sparse issues an "'junk_mode' not declared. Should it be static?" warning. In order to suppress the warning, since this symbol does not need more than file visibility, we simply add the static modifier to its declaration. Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-28Merge branch 'jk/merge-tree-added-identically'Libravatar Junio C Hamano1-1/+1
off-by-one fix. * jk/merge-tree-added-identically: merge-tree: fix typo in "both changed identically"
2013-04-28merge-tree: fix typo in "both changed identically"Libravatar John Keeping1-1/+1
Commit aacecc3 (merge-tree: don't print entries that match "local" - 2013-04-07) had a typo causing the "same in both" check to be incorrect and check if both the base and "their" versions are removed instead of checking that both the "our" and "their" versions are removed. Fix this. Reported-by: René Scharfe <rene.scharfe@lsrfire.ath.cx> Test-written-by: René Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-26Merge branch 'rr/shortlog-doc'Libravatar Junio C Hamano2-4/+2
Update documentation for "log" and "shortlog". * rr/shortlog-doc: builtin/shortlog.c: make usage string consistent with log builtin/log.c: make usage string consistent with doc git-shortlog.txt: make SYNOPSIS match log, update OPTIONS git-log.txt: rewrite note on why "--" may be required git-log.txt: generalize <since>..<until> git-log.txt: order OPTIONS properly; move <since>..<until> revisions.txt: clarify the .. and ... syntax git-shortlog.txt: remove (-h|--help) from OPTIONS
2013-04-26Merge branch 'jc/add-ignore-removal'Libravatar Junio C Hamano1-6/+17
Introduce "--ignore-removal" as a synonym to "--no-all" for "git add", and improve the 2.0 migration warning with it. * jc/add-ignore-removal: git add: rephrase -A/--no-all warning git add: --ignore-removal is a better named --no-all
2013-04-26Merge branch 'jc/warn-pathless-add-finishing-touches'Libravatar Junio C Hamano1-0/+2
* jc/warn-pathless-add-finishing-touches: git add: avoid "-u/-A without pathspec" warning on stat-dirty paths
2013-04-26git add: avoid "-u/-A without pathspec" warning on stat-dirty pathsLibravatar Junio C Hamano1-0/+2
In preparation for Git 2.0, "git add -u/-A" without pathspec checks all the working tree (not limited to the current directory) and issues a warning when it finds any path that we might add in Git 2.0, because that would mean the users' fingers need to be trained to explicitly say "." if they want to keep the current behaviour. However, the check was incomplete, because "git add" usually does not refresh the index, considers a path that is stat-dirty but has contents that is otherwise up-to-date in the index as "we might add", and relies on that it is a no-op to add the same thing again via the add_file_to_index() API (which also knows not to say "added" in verbose mode when this happens). We do not want to trigger the warning for a path that is outside the current directory is merely stat-dirty, as it won't be added in Git 2.0, either. Signed-off-by: Junio C Hamano <gitster@pobox.com> Acked-by: Jonathan Nieder <jrnieder@gmail.com>
2013-04-25prune: introduce OPT_EXPIRY_DATE() and use itLibravatar Junio C Hamano1-2/+2
Earlier we added support for --expire=all (or --expire=now) that considers all crufts, regardless of their age, as eligible for garbage collection by turning command argument parsers that use approxidate() to use parse_expiry_date(), but "git prune" used a built-in parse-options facility OPT_DATE() and did not benefit from the new function. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-24Merge branch 'jk/remote-helper-with-signed-tags'Libravatar Junio C Hamano1-1/+7
Allows remote-helpers to declare they can handle signed tags, and issue a warning when using those that don't. * jk/remote-helper-with-signed-tags: transport-helper: add 'signed-tags' capability transport-helper: pass --signed-tags=warn-strip to fast-export fast-export: add --signed-tags=warn-strip mode
2013-04-24Sync with maintLibravatar Junio C Hamano1-2/+2
* maint: Update draft release notes to 1.8.2.2 completion: remove duplicate block for "git commit -c" cherry-pick/revert: make usage say '<commit-ish>...'
2013-04-24Merge branch 'jc/merge-tag-object' into maintLibravatar Junio C Hamano1-0/+13
"git merge $(git rev-parse v1.8.2)" behaved quite differently from "git merge v1.8.2", as if v1.8.2 were written as v1.8.2^0 and did not pay much attention to the annotated tag payload. Make the code notice the type of the tag object, in addition to the dwim_ref() based classification the current code uses (i.e. the name appears in refs/tags/) to decide when to special case merging of tags. * jc/merge-tag-object: t6200: test message for merging of an annotated tag t6200: use test_config/test_unconfig merge: a random object may not necssarily be a commit
2013-04-24remote: check for superfluous arguments in 'git remote add'Libravatar Thomas Rast1-1/+1
The 'git remote add' subcommand did not check for superfluous command line arguments. Make it so. Signed-off-by: Thomas Rast <trast@inf.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-24cherry-pick/revert: make usage say '<commit-ish>...'Libravatar Kevin Bracey1-2/+2
The usage string for cherry-pick and revert has never been updated to reflect their ability to handle multiple commits. Other documentation is already correct. Signed-off-by: Kevin Bracey <kevin@bracey.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-23Merge branch 'nd/pretty-formats'Libravatar Junio C Hamano2-2/+2
pretty-printing body of the commit that is stored in non UTF-8 encoding did not work well. The early part of this series fixes it. And then it adds %C(auto) specifier that turns the coloring on when we are emitting to the terminal, and adds column-aligning format directives. * nd/pretty-formats: pretty: support %>> that steal trailing spaces pretty: support truncating in %>, %< and %>< pretty: support padding placeholders, %< %> and %>< pretty: add %C(auto) for auto-coloring pretty: split color parsing into a separate function pretty: two phase conversion for non utf-8 commits utf8.c: add reencode_string_len() that can handle NULs in string utf8.c: add utf8_strnwidth() with the ability to skip ansi sequences utf8.c: move display_mode_esc_sequence_len() for use by other functions pretty: share code between format_decoration and show_decorations pretty-formats.txt: wrap long lines pretty: get the correct encoding for --pretty:format=%e pretty: save commit encoding from logmsg_reencode if the caller needs it
2013-04-23Merge branch 'kb/status-ignored-optim-2'Libravatar Junio C Hamano3-21/+6
Fixes a handful of issues in the code to traverse working tree to find untracked and/or ignored files, cleans up and optimizes the codepath in general. * kb/status-ignored-optim-2: dir.c: git-status --ignored: don't scan the work tree twice dir.c: git-status --ignored: don't scan the work tree three times dir.c: git-status: avoid is_excluded checks for tracked files dir.c: replace is_path_excluded with now equivalent is_excluded API dir.c: unify is_excluded and is_path_excluded APIs dir.c: move prep_exclude dir.c: factor out parts of last_exclude_matching for later reuse dir.c: git-clean -d -X: don't delete tracked directories dir.c: make 'git-status --ignored' work within leading directories dir.c: git-status --ignored: don't list empty directories as ignored dir.c: git-ls-files --directories: don't hide empty directories dir.c: git-status --ignored: don't list empty ignored directories dir.c: git-status --ignored: don't list files in ignored directories dir.c: git-status --ignored: don't drop ignored directories
2013-04-23Merge branch 'jk/receive-pack-deadlocks-with-early-failure'Libravatar Junio C Hamano1-1/+4
When receive-pack detects error in the pack header it received in order to decide which of unpack-objects or index-pack to run, it returned without closing the error stream, which led to a hang sideband thread. * jk/receive-pack-deadlocks-with-early-failure: receive-pack: close sideband fd on early pack errors
2013-04-22git add: rephrase -A/--no-all warningLibravatar Junio C Hamano1-6/+6
Now we have a synonym --ignore-removal for --no-all, we can rephrase the Git 2.0 transition warning message in a more natural way. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-22git add: --ignore-removal is a better named --no-allLibravatar Junio C Hamano1-0/+11
In the historical context of "git add --all ." that pays attention to "all kinds of changes" (implying "without ignoring removals"), the option to countermand it "--no-all" may have made sense, but because we will be making "--all" the default when a pathspec is given, it makes more sense to rename the option to a more explicit "--ignore-removal". The "--all" option naturally becomes its negation, "--no-ignore-removal". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-22Merge branch 'jk/show-branch-strbuf' into maintLibravatar Junio C Hamano1-9/+8
* jk/show-branch-strbuf: show-branch: use strbuf instead of static buffer
2013-04-22Merge branch 'jc/apply-ws-fix-tab-in-indent' into maintLibravatar Junio C Hamano1-6/+10
* jc/apply-ws-fix-tab-in-indent: test: resurrect q_to_tab apply --whitespace=fix: avoid running over the postimage buffer
2013-04-22Merge branch 'as/clone-reference-with-gitfile'Libravatar Junio C Hamano1-3/+13
"git clone" did not work if a repository pointed at by the "--reference" option is a gitfile that points at another place. * as/clone-reference-with-gitfile: clone: Allow repo using gitfile as a reference clone: Fix error message for reference repository
2013-04-22Merge branch 'jc/add-2.0-delete-default' (early part)Libravatar Junio C Hamano1-28/+87
Preparatory steps to make "git add <pathspec>" take notice of removed paths that match <pathspec> by default in Git 2.0. * 'jc/add-2.0-delete-default' (early part): git add: rephrase the "removal will cease to be ignored" warning git add: rework the logic to warn "git add <pathspec>..." default change git add: start preparing for "git add <pathspec>..." to default to "-A" builtin/add.c: simplify boolean variables
2013-04-22Merge branch 'nd/checkout-keep-sparse'Libravatar Junio C Hamano1-0/+5
Make the initial "sparse" selection of the paths more sticky across "git checkout". * nd/checkout-keep-sparse: checkout: add --ignore-skip-worktree-bits in sparse checkout mode
2013-04-22Merge branch 'jk/chopped-ident'Libravatar Junio C Hamano2-74/+8
A commit object whose author or committer ident are malformed crashed some code that trusted that a name, an email and an timestamp can always be found in it. * jk/chopped-ident: blame: handle broken commit headers gracefully pretty: handle broken commit headers gracefully cat-file: print tags raw for "cat-file -p"
2013-04-22builtin/shortlog.c: make usage string consistent with logLibravatar Ramkumar Ramachandra1-3/+1
"--" is used to separate pathspecs from the rev specs, and not rev specs from the options, as the shortlog_usage string currently indicates. In correcting this usage string, make it consistent with the log_usage string. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-22builtin/log.c: make usage string consistent with docLibravatar Ramkumar Ramachandra1-1/+1
Replace '<since>..<until>' with '<revision range>', in accordance with the documentation. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-21git add: rephrase the "removal will cease to be ignored" warningLibravatar Junio C Hamano1-7/+14
Now the logic to decide when to warn has been tightened, we know the user is in a situation where the current and future behaviours will be different. Spell out what happens with these two versions and how to explicitly ask for the behaviour, and suggest "git status" as a way to inspect the current status. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-21checkout: Use remote refspecs when DWIMming tracking branchesLibravatar Johan Herland1-20/+22
The DWIM mode of checkout allows you to run "git checkout foo" when there is no existing local ref or path called "foo", and there is exactly _one_ remote with a remote-tracking branch called "foo". Git will automatically create a new local branch called "foo" using the remote-tracking "foo" as its starting point and configured upstream. For example, consider the following unconventional (but perfectly valid) remote setup: [remote "origin"] fetch = refs/heads/*:refs/remotes/origin/* [remote "frotz"] fetch = refs/heads/*:refs/remotes/frotz/nitfol/* Case 1: Assume both "origin" and "frotz" have remote-tracking branches called "foo", at "refs/remotes/origin/foo" and "refs/remotes/frotz/nitfol/foo" respectively. In this case "git checkout foo" should fail, because there is more than one remote with a "foo" branch. Case 2: Assume only "frotz" have a remote-tracking branch called "foo". In this case "git checkout foo" should succeed, and create a local branch "foo" from "refs/remotes/frotz/nitfol/foo", using remote branch "foo" from "frotz" as its upstream. The current code hardcodes the assumption that all remote-tracking branches must match the "refs/remotes/$remote/*" pattern (which is true for remotes with "conventional" refspecs, but not true for the "frotz" remote above). When running "git checkout foo", the current code looks for exactly one ref matching "refs/remotes/*/foo", hence in the above example, it fails to find "refs/remotes/frotz/nitfol/foo", which causes it to fail both case #1 and #2. The better way to handle the above example is to actually study the fetch refspecs to deduce the candidate remote-tracking branches for "foo"; i.e. assume "foo" is a remote branch being fetched, and then map "refs/heads/foo" through the refspecs in order to get the corresponding remote-tracking branches "refs/remotes/origin/foo" and "refs/remotes/frotz/nitfol/foo". Finally we check which of these happens to exist in the local repo, and if there is exactly one, we have an unambiguous match for "git checkout foo", and may proceed. This fixes most of the failing tests introduced in the previous patch. Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-19receive-pack: close sideband fd on early pack errorsLibravatar Jeff King1-1/+4
Since commit a22e6f8 (receive-pack: send pack-processing stderr over sideband, 2012-09-21), receive-pack will start an async sideband thread to copy the stderr from our index-pack or unpack-objects child to the client. We hand the thread's input descriptor to unpack(), which puts it in the "err" member of the "struct child_process". After unpack() returns, we use finish_async() to reap the sideband thread. The thread is only ready to die when it gets EOF on its pipe, which is connected to the err descriptor. So we expect all of the write ends of that pipe to be closed as part of unpack(). Normally, this works fine. After start_command forks, it closes the parent copy of the descriptor. Then once the child exits (whether it was successful or not), that closes the only remaining writer. However, there is one code-path in unpack() that does not handle this. Before we decide which of unpack-objects or index-pack to use, we read the pack header ourselves to see how many objects it contains. If there is an error here, we exit without running either sub-command, the pipe descriptor remains open, and we are in a deadlock, waiting for the sideband thread to die (which is in turn waiting for us to close the pipe). We can fix this by making sure that unpack() always closes the pipe before returning. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-19Merge branch 'jn/add-2.0-u-A-sans-pathspec' (early part)Libravatar Junio C Hamano1-40/+94
In Git 2.0, "git add -u" and "git add -A" without any pathspec will update the index for all paths, including those outside the current directory, making it more consistent with "commit -a". To help the migration pain, a warning is issued when the differences between the current behaviour and the upcoming behaviour matters, i.e. when the user has local changes outside the current directory. * 'jn/add-2.0-u-A-sans-pathspec' (early part): add -A: only show pathless 'add -A' warning when changes exist outside cwd add -u: only show pathless 'add -u' warning when changes exist outside cwd add: make warn_pathless_add() a no-op after first call add: add a blank line at the end of pathless 'add [-u|-A]' warning add: make pathless 'add [-u|-A]' warning a file-global function
2013-04-19Merge branch 'ap/strbuf-humanize'Libravatar Junio C Hamano1-8/+36
Teach "--human-readable" aka "-H" option to "git count-objects" to show various large numbers in Ki/Mi/GiB scaled as necessary. * ap/strbuf-humanize: count-objects: add -H option to humanize sizes strbuf: create strbuf_humanise_bytes() to show byte sizes
2013-04-19Merge branch 'fc/branch-upstream-color'Libravatar Junio C Hamano1-8/+28
Add more colors to "git branch -vv" output. * fc/branch-upstream-color: branch: colour upstream branches
2013-04-18pretty: save commit encoding from logmsg_reencode if the caller needs itLibravatar Nguyễn Thái Ngọc Duy2-2/+2
The commit encoding is parsed by logmsg_reencode, there's no need for the caller to re-parse it again. The reencoded message now has the new encoding, not the original one. The caller would need to read commit object again before parsing. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-18Merge branch 'jk/merge-tree-added-identically'Libravatar Junio C Hamano1-13/+13
The resolution of some corner cases by "git merge-tree" were inconsistent between top-of-the-tree and in a subdirectory. * jk/merge-tree-added-identically: merge-tree: don't print entries that match "local"
2013-04-18Merge branch 'fc/send-email-annotate'Libravatar Junio C Hamano1-81/+85
Allows format-patch --cover-letter to be configurable; the most notable is the "auto" mode to create cover-letter only for multi patch series. * fc/send-email-annotate: rebase-am: explicitly disable cover-letter format-patch: trivial cleanups format-patch: add format.coverLetter configuration variable log: update to OPT_BOOL format-patch: refactor branch name calculation format-patch: improve head calculation for cover-letter send-email: make annotate configurable
2013-04-18Merge branch 'kb/co-orphan-suggestion-short-sha1'Libravatar Junio C Hamano1-1/+1
Update the informational message when "git checkout" leaves the detached head state. * kb/co-orphan-suggestion-short-sha1: checkout: abbreviate hash in suggest_reattach
2013-04-17git add: rework the logic to warn "git add <pathspec>..." default changeLibravatar Junio C Hamano1-26/+38
The earlier logic to warn against "git add subdir" that is run without "-A" or "--no-all" was only to check any <pathspec> given exactly spells a directory name that (still) exists on the filesystem. This had number of problems: * "git add '*dir'" (note that the wildcard is hidden from the shell) would not trigger the warning. * "git add '*.py'" would behave differently between the current version of Git and Git 2.0 for the same reason as "subdir", but would not trigger the warning. * "git add dir" for a submodule "dir" would just update the index entry for the submodule "dir" without ever recursing into it, and use of "-A" or "--no-all" would matter. But the logic only checks the directory-ness of "dir" and gives an unnecessary warning. Rework the logic to detect the case where the behaviour will be different in Git 2.0, and issue a warning only when it matters. Even with the code before this warning, "git add subdir" will have to traverse the directory in order to find _new_ files the index does not know about _anyway_, so we can do this check without adding an extra pass to find if <pathspec> matches any removed file. This essentially updates the "add_files_to_cache()" public API to "update_files_in_cache()" API that is internal to "git add", because with the "--all" option, the function is no longer about "adding" paths to the cache, but is also used to remove them. There are other callers of the former from "checkout" (used when "checkout -m" prepares the temporary tree that represents the local modifications to be merged) and "commit" ("commit --include" that picks up local changes in addition to what is in the index). Since ADD_CACHE_IGNORE_ERRORS (aka "--no-all") is not used by either of them, once dust settles after Git 2.0 and the warning becomes unnecessary, we may want to unify these two functions again. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-17date.c: add parse_expiry_date()Libravatar Junio C Hamano1-7/+7
"git reflog --expire=all" tries to expire reflog entries up to the current second, because the approxidate() parser gives the current timestamp for anything it does not understand (and it does not know what time "all" means). When the user tells us to expire "all" (or set the expiration time to "now"), the user wants to remove all the reflog entries (no reflog entry should record future time). Just set it to ULONG_MAX and to let everything that is older that timestamp expire. While at it, allow "now" to be treated the same way for callers that parse expiry date timestamp with this function. Also use an error reporting version of approxidate() to report misspelled date. When the user says e.g. "--expire=mnoday" to delete entries two days or older on Wednesday, we wouldn't want the "unknown, default to now" logic to kick in. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-17blame: handle broken commit headers gracefullyLibravatar René Scharfe1-3/+8
split_ident_line() can leave us with the pointers date_begin, date_end, tz_begin and tz_end all set to NULL. Check them before use and supply the same fallback values as in the case of a negative return code from split_ident_line(). The "(unknown)" is not actually shown in the output, though, because it will be converted to a number (zero) eventually. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-17cat-file: print tags raw for "cat-file -p"Libravatar Jeff King1-71/+0
When "cat-file -p" prints commits, it shows them in their raw format, since git's format is already human-readable. For tags, however, we print the whole thing raw except for one thing: we convert the timestamp on the tagger line into a human-readable date. This dates all the way back to a0f15fa (Pretty-print tagger dates, 2006-03-01). At that time there was no other way to pretty-print a tag. These days, however, neither of those matters much. The normal way to pretty-print a tag is with "git show", which is much more flexible than "cat-file -p". Commit a0f15fa also built "verify-tag --verbose" (and subsequently "tag -v") around the "cat-file -p" output. However, that behavior was lost in commit 62e09ce (Make git tag a builtin, 2007-07-20), and we went back to printing the raw tag contents. Nobody seems to have noticed the bug since then (and it is arguably a saner behavior anyway, as it shows the actual bytes for which we verified the signature). Let's drop the tagger-date formatting for "cat-file -p". It makes us more consistent with cat-file's commit pretty-printer, and as a bonus, we can drop the hand-rolled tag parsing code in cat-file (which happened to behave inconsistently with the tag pretty-printing code elsewhere). This is a change of output format, so it's possible that some callers could considered this a regression. However, the original behavior was arguably a bug (due to the inconsistency with commits), likely nobody was relying on it (even we do not use it ourselves these days), and anyone relying on the "-p" pretty-printer should be able to expect a change in the output format (i.e., while "cat-file" is plumbing, the output format of "-p" was never guaranteed to be stable). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>