summaryrefslogtreecommitdiff
path: root/builtin
AgeCommit message (Collapse)AuthorFilesLines
2013-07-15Merge branch 'tr/maint-apply-non-git-patch-parsefix' into maintLibravatar Junio C Hamano1-1/+1
"git apply" parsed patches that add new files, generated by programs other than Git, incorrectly. This is an old breakage in v1.7.11. * tr/maint-apply-non-git-patch-parsefix: apply: carefully strdup a possibly-NULL name
2013-07-03Merge branch 'vv/help-unknown-ref' into maintLibravatar Junio C Hamano1-1/+2
* vv/help-unknown-ref: merge: use help_unknown_ref() help: add help_unknown_ref()
2013-06-28Merge branch 'nd/clone-connectivity-shortcut' (early part) into maintLibravatar Junio C Hamano1-0/+4
Cloning with "git clone --depth N" while fetch.fsckobjects (or transfer.fsckobjects) is set to true did not tell the cut-off points of the shallow history to the process that validates the objects and the history received, causing the validation to fail. * 'nd/clone-connectivity-shortcut' (early part): fetch-pack: prepare updated shallow file before fetching the pack clone: let the user know when check_everything_connected is run
2013-06-27Merge branch 'rr/push-head' into maintLibravatar Junio C Hamano1-7/+14
* rr/push-head: push: make push.default = current use resolved HEAD push: fail early with detached HEAD and current push: factor out the detached HEAD error message
2013-06-27Merge branch 'rs/commit-m-no-edit' into maintLibravatar Junio C Hamano1-4/+6
* rs/commit-m-no-edit: commit: don't start editor if empty message is given with -m
2013-06-27Merge branch 'jh/checkout-auto-tracking' into maintLibravatar Junio C Hamano1-20/+22
* 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-06-21apply: carefully strdup a possibly-NULL nameLibravatar Thomas Rast1-1/+1
2901bbe (apply: free patch->{def,old,new}_name fields, 2012-03-21) cleaned up the memory management of filenames in the patches, but forgot that find_name_traditional() can return NULL as a way of saying "I couldn't find a name". That NULL unfortunately gets passed into xstrdup() next, resulting in a segfault. Use null_strdup() so as to safely propagate the null, which will let us emit the correct error message. Reported-by: DevHC on #git Signed-off-by: Thomas Rast <trast@inf.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-09Merge branch 'jn/config-ignore-inaccessible' into maintLibravatar Junio C Hamano1-2/+2
A git daemon that starts as "root" and then drops privilege often leaves $HOME set to that of the root user, which is unreadable by the daemon process, which was diagnosed as a configuration error. Make per-user configuration files that are inaccessible due to EACCES as though these files do not exist to avoid this issue, as the tightening which was originally meant as an additional security has annoyed enough sysadmins. * jn/config-ignore-inaccessible: config: allow inaccessible configuration under $HOME
2013-05-29push: make push.default = current use resolved HEADLibravatar Ramkumar Ramachandra1-1/+1
With this change, the output of the push (with push.default set to current) changes subtly from: $ git push ... * [new branch] HEAD -> push-current-head to: $ git push ... * [new branch] push-current-head -> push-current-head This patch was written with a different motivation. There is a problem unique to push.default = current: # on branch push-current-head $ git push # on another terminal $ git checkout master # return to the first terminal # the push tried to push master! This happens because the 'git checkout' on the second terminal races with the 'git push' on the first terminal. Although this patch does not solve the core problem (there is still no guarantee that 'git push' on the first terminal will resolve HEAD before 'git checkout' changes HEAD on the second), it works in practice. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-29push: fail early with detached HEAD and currentLibravatar Ramkumar Ramachandra1-0/+5
Setting push.default to current adds the refspec "HEAD" for the transport layer to handle. If "HEAD" doesn't resolve to a branch (and since no refspec rhs is specified), the push fails after some time with a cryptic error message: $ git push error: unable to push to unqualified destination: HEAD The destination refspec neither matches an existing ref on the remote nor begins with refs/, and we are unable to guess a prefix based on the source ref. error: failed to push some refs to 'git@github.com:artagnon/git' Fail early with a nicer error message: $ git push fatal: You are not currently on a branch. To push the history leading to the current (detached HEAD) state now, use git push ram HEAD:<name-of-remote-branch> Just like in the upstream and simple cases. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-29push: factor out the detached HEAD error messageLibravatar Ramkumar Ramachandra1-6/+8
With push.default set to upstream or simple, and a detached HEAD, git push prints the following error: $ git push fatal: You are not currently on a branch. To push the history leading to the current (detached HEAD) state now, use git push ram HEAD:<name-of-remote-branch> This error is not unique to upstream or simple: current cannot push with a detached HEAD either. So, factor out the error string in preparation for using it in current. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-28commit: don't start editor if empty message is given with -mLibravatar René Scharfe1-4/+6
If an empty message is specified with the option -m of git commit then the editor is started. That's unexpected and unnecessary. Instead of using the length of the message string for checking if the user specified one, directly remember if the option -m was given. Reported-by: Mislav Marohnić <mislav.marohnic@gmail.com> Signed-off-by: René Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-11clone: let the user know when check_everything_connected is runLibravatar Nguyễn Thái Ngọc Duy1-0/+4
check_everything_connected could take a long time, especially in the clone case where the whole DAG is traversed. The user deserves to know what's going on. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-08merge: use help_unknown_ref()Libravatar Vikrant Varma1-1/+2
Use help.c:help_unknown_ref() instead of die() to provide a friendlier error message before exiting, when one of the refs specified in a merge is unknown. Signed-off-by: Vikrant Varma <vikrant.varma94@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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-03Merge branch 'tr/remote-tighten-commandline-parsing' into maintLibravatar 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-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-26Merge branch 'jk/receive-pack-deadlocks-with-early-failure' into maintLibravatar Junio C Hamano1-1/+4
* jk/receive-pack-deadlocks-with-early-failure: receive-pack: close sideband fd on early pack errors
2013-04-26Merge branch 'jk/chopped-ident' into maintLibravatar Junio C Hamano2-74/+8
* 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-26Merge branch 'rt/commentchar-fmt-merge-msg' into maintLibravatar Junio C Hamano1-7/+11
* rt/commentchar-fmt-merge-msg: t6200: avoid path mangling issue on Windows fmt-merge-msg: use core.commentchar in tag signatures completely fmt-merge-msg: respect core.commentchar in people credits
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>