summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2009-02-18Skip timestamp differences for diff --no-indexLibravatar Michael Spang2-0/+7
We display empty diffs for files whose timestamps have changed. Usually, refreshing the index makes those empty diffs go away. However, when not using the index they are not very useful and there is no option to suppress them. This forces on the skip_stat_unmatch option for diff --no-index, suppressing any empty diffs. This option is also used for diffs against the index when "diff.autorefreshindex" is set, but that option does not apply to diff --no-index. Signed-off-by: Michael Spang <mspang@uwaterloo.ca> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-11Merge branch 'maint-1.5.6' into maintLibravatar Junio C Hamano1-0/+39
* maint-1.5.6: revision traversal and pack: notice and die on missing commit
2009-02-11Merge branch 'maint-1.5.5' into maint-1.5.6Libravatar Junio C Hamano1-0/+39
* maint-1.5.5: revision traversal and pack: notice and die on missing commit Conflicts: revision.c
2009-02-11Merge branch 'maint-1.5.4' into maint-1.5.5Libravatar Junio C Hamano1-0/+39
* maint-1.5.4: revision traversal and pack: notice and die on missing commit
2009-02-11revision traversal and pack: notice and die on missing commitLibravatar Junio C Hamano1-0/+39
cc0e6c5 (Handle return code of parse_commit in revision machinery, 2007-05-04) attempted to tighten error checking in the revision machinery, but it wasn't enough. When get_revision_1() was asked for the next commit to return, it tries to read and simplify the parents of the commit to be returned, but an error while doing so was silently ignored and reported as a truncated history to the caller instead. This resulted in an early end of "git log" output or a pack that lacks older commits from "git pack-objects", without any error indication in the exit status from these commands, even though the underlying parse_commit() issues an error message to the end user. Note that the codepath in add_parents_list() that paints parents of an UNINTERESTING commit UNINTERESTING silently ignores the error when parse_commit() fails; this is deliberate and in line with aeeae1b (revision traversal: allow UNINTERESTING objects to be missing, 2009-01-27). Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-05Merge branch 'sg/maint-gitdir-in-subdir' into maintLibravatar Junio C Hamano1-0/+7
* sg/maint-gitdir-in-subdir: Fix gitdir detection when in subdir of gitdir
2009-02-05Merge branch 'jc/maint-split-diff-metainfo' into maintLibravatar Junio C Hamano2-1/+19
* jc/maint-split-diff-metainfo: diff.c: output correct index lines for a split diff
2009-02-05Merge branch 'js/maint-all-implies-HEAD' into maintLibravatar Junio C Hamano2-2/+40
* js/maint-all-implies-HEAD: bundle: allow the same ref to be given more than once revision walker: include a detached HEAD in --all
2009-02-05Merge branch 'kc/maint-diff-bwi-fix' into maintLibravatar Junio C Hamano1-0/+27
* kc/maint-diff-bwi-fix: Fix combined use of whitespace ignore options to diff test more combinations of ignore-whitespace options to diff
2009-02-04Merge branch 'maint-1.6.0' into maintLibravatar Junio C Hamano1-1/+9
* maint-1.6.0: builtin-mv.c: check for unversionned files before looking at the destination. Add a testcase for "git mv -f" on untracked files. Missing && in t/t7001.sh.
2009-02-04builtin-mv.c: check for unversionned files before looking at the destination.Libravatar Matthieu Moy1-1/+1
The previous code was failing in the case where one moves an unversionned file to an existing destination, with mv -f: the "existing destination" was checked first, and the error was cancelled by the force flag. We now check the unrecoverable error first, which fixes the bug. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-04Add a testcase for "git mv -f" on untracked files.Libravatar Matthieu Moy1-0/+8
This currently fails with: git: builtin-mv.c:217: cmd_mv: Assertion `pos >= 0' failed. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-04Missing && in t/t7001.sh.Libravatar Matthieu Moy1-1/+1
Without this, the exit status is only the one of the last line. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-28Merge branch 'jc/maint-format-patch-o-relative' into maintLibravatar Junio C Hamano1-1/+51
* jc/maint-format-patch-o-relative: Teach format-patch to handle output directory relative to cwd Conflicts: t/t4014-format-patch.sh
2009-01-28Merge branch 'nd/grep-assume-unchanged' into maintLibravatar Junio C Hamano1-0/+7
* nd/grep-assume-unchanged: grep: grep cache entries if they are "assume unchanged" grep: support --no-ext-grep to test builtin grep
2009-01-28Merge branch 'mc/cd-p-pwd' into maintLibravatar Junio C Hamano1-2/+2
* mc/cd-p-pwd: git-sh-setup: Fix scripts whose PWD is a symlink to a work-dir on OS X
2009-01-27send-pack: do not send unknown object name from ".have" to pack-objectsLibravatar Junio C Hamano1-0/+106
v1.6.1 introduced ".have" extension to the protocol to allow the receiving side to advertise objects that are reachable from refs in the repositories it borrows from. This was meant to be used by the sending side to avoid sending such objects; they are already available through the alternates mechanism. The client side implementation in v1.6.1, which was introduced with 40c155f (push: prepare sender to receive extended ref information from the receiver, 2008-09-09) aka v1.6.1-rc1~203^2~1, were faulty in that it did not consider the possiblity that the repository receiver borrows from might have objects it does not know about. This fixes it by refraining from passing missing commits to underlying pack-objects. Revision machinery may need to be tightened further to treat missing uninteresting objects as non-error events, but this is an obvious and safe fix for a maintenance release that is almost good enough. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-27Merge branch 'jc/maint-1.6.0-split-diff-metainfo' into ↵Libravatar Junio C Hamano2-1/+19
jc/maint-split-diff-metainfo This is an evil merge, as a test added since 1.6.0 expects an incorrect behaviour the merged commit fixes. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-27diff.c: output correct index lines for a split diffLibravatar Junio C Hamano1-0/+18
A patch that changes the filetype (e.g. regular file to symlink) of a path must be split into a deletion event followed by a creation event, which means that we need to have two independent metainfo lines for each. However, the code reused the single set of metainfo lines. As the blob object names recorded on the index lines are usually not used nor validated on the receiving end, this is not an issue with normal use of the resulting patch. However, when accepting a binary patch to delete a blob, git-apply verified that the postimage blob object name on the index line is 0{40}, hence a patch that deletes a regular file blob that records binary contents to create a blob with different filetype (e.g. a symbolic link) failed to apply. "git am -3" also uses the blob object names recorded on the index line, so it would also misbehave when synthesizing a preimage tree. This moves the code to generate metainfo lines around, so that two independent sets of metainfo lines are used for the split halves. Additional tests by Jeff King. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-23Merge branch 'cb/maint-unpack-trees-absense' into maintLibravatar Junio C Hamano1-0/+51
* cb/maint-unpack-trees-absense: unpack-trees: remove redundant path search in verify_absent unpack-trees: fix path search bug in verify_absent unpack-trees: handle failure in verify_absent
2009-01-23Merge branch 'tr/maint-no-index-fixes' into maintLibravatar Junio C Hamano2-0/+4
* tr/maint-no-index-fixes: diff --no-index -q: fix endless loop diff --no-index: test for pager after option parsing diff: accept -- when using --no-index
2009-01-23Merge branch 'js/add-not-submodule' into maintLibravatar Junio C Hamano1-0/+25
* js/add-not-submodule: git add: do not add files from a submodule
2009-01-21Rename diff.suppress-blank-empty to diff.suppressBlankEmptyLibravatar Johannes Schindelin1-4/+4
All the other config variables use CamelCase. This config variable should not be an exception. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-19Fix combined use of whitespace ignore options to diffLibravatar Keith Cascio1-4/+4
The code used to misbehave when options to ignore certain whitespaces (-w -b and --ignore-at-eol) were combined. Signed-off-by: Keith Cascio <keith@cs.ucla.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-19test more combinations of ignore-whitespace options to diffLibravatar Keith Cascio1-0/+27
There are three flags involved (-w -b and --ignore-space-at-eol) which makes 8 combinations possible in total, but only 3 cases are tested (none, -w alone and -b alone). This adds the other 5 cases. Signed-off-by: Keith Cascio <keith@cs.ucla.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-17bundle: allow the same ref to be given more than onceLibravatar Junio C Hamano1-1/+1
"git bundle create x master master" used to create a bundle that lists the same branch (master) twice. Cloning from such a bundle resulted in a needless warning "warning: Duplicated ref: refs/remotes/origin/master". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-17revision walker: include a detached HEAD in --allLibravatar Johannes Schindelin2-2/+40
When HEAD is detached, --all should list it, too, logically, as a detached HEAD is by definition a temporary, unnamed branch. It is especially necessary to list it when garbage collecting, as the detached HEAD would be trashed. Noticed by Thomas Rast. Note that this affects creating bundles with --all; I contend that it is a good change to add the HEAD, so that cloning from such a bundle will give you a current branch. However, I had to fix t5701 as it assumed that --all does not imply HEAD. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-17Fix gitdir detection when in subdir of gitdirLibravatar SZEDER Gábor1-0/+7
If the current working directory is a subdirectory of the gitdir (e.g. <repo>/.git/refs/), then setup_git_directory_gently() will climb its parent directories until it finds itself in a gitdir. However, no matter how many parent directories it climbs, it sets 'GIT_DIR_ENVIRONMENT' to ".", which is obviously wrong. This behaviour affected at least 'git rev-parse --git-dir' and hence caused some errors in bash completion (e.g. customized command prompt when on a detached head and completion of refs). To fix this, we set the absolute path of the found gitdir instead. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-17t5540: clarify that http-push does not handle packed-refs on the remoteLibravatar Johannes Schindelin1-3/+15
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-17http-push: when making directories, have a trailing slash in the path nameLibravatar Johannes Schindelin2-0/+8
The function lock_remote() sends MKCOL requests to make leading directories; However, if it does not put a forward slash '/' at the end of the path, the server sends a 301 redirect. By leaving the '/' in place, we can avoid this additional step. Incidentally, at least one version of Curl (7.16.3) does not resend credentials when it follows a 301 redirect, so this commit also fixes a bug. Original patch by Tay Ray Chuan <rctay89@gmail.com>. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-15Merge branch 'maint-1.6.0' into maintLibravatar Junio C Hamano2-0/+34
* maint-1.6.0: t3404: Add test case for auto-amending only edited commits after "edit" t3404: Add test case for aborted --continue after "edit" t3501: check that commits are actually done
2009-01-15t3404: Add test case for auto-amending only edited commits after "edit"Libravatar Stephan Beyer1-0/+17
Add a test case for the bugfix introduced by commit c14c3c82d "git-rebase--interactive: auto amend only edited commit". Signed-off-by: Stephan Beyer <s-beyer@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-15t3404: Add test case for aborted --continue after "edit"Libravatar Stephan Beyer1-0/+15
Add a test case for the bugfix introduced by commit 8beb1f33d "git-rebase-interactive: do not squash commits on abort". Signed-off-by: Stephan Beyer <s-beyer@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-15t3501: check that commits are actually doneLibravatar Stephan Beyer1-0/+2
The basic idea of t3501 is to check whether revert and cherry-pick works on renamed files. But as there is no pure cherry-pick/revert test, it is good to also check if commits are actually done in that scenario. Signed-off-by: Stephan Beyer <s-beyer@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-14Merge branch 'maint-1.6.0' into maintLibravatar Junio C Hamano1-0/+25
* maint-1.6.0: fix handling of multiple untracked files for git mv -k add test cases for "git mv -k"
2009-01-14Make t3411 executableLibravatar Miklos Vajna1-0/+0
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-14fix handling of multiple untracked files for git mv -kLibravatar Michael J Gruber1-1/+1
The "-k" option to "git mv" should allow specifying multiple untracked files. Currently, multiple untracked files raise an assertion if they appear consecutively as arguments. Fix this by decrementing the loop index after removing one entry from the array of arguments. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-14add test cases for "git mv -k"Libravatar Michael J Gruber1-0/+25
Add test cases for ignoring nonexisting and untracked files using the -k option to "git mv". There is one known breakage related to multiple untracked files specfied as consecutive arguments. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-13Merge branch 'js/maint-merge-recursive-r-d-conflict' into maintLibravatar Junio C Hamano1-0/+23
* js/maint-merge-recursive-r-d-conflict: merge-recursive: mark rename/delete conflict as unmerged
2009-01-13Merge branch 'cb/maint-merge-recursive-fix' into maintLibravatar Junio C Hamano1-0/+87
* cb/maint-merge-recursive-fix: merge-recursive: do not clobber untracked working tree garbage modify/delete conflict resolution overwrites untracked file Conflicts: builtin-merge-recursive.c
2009-01-13Merge branch 'ap/maint-apply-modefix' into maintLibravatar Junio C Hamano1-0/+62
* ap/maint-apply-modefix: builtin-apply: prevent non-explicit permission changes
2009-01-12Teach format-patch to handle output directory relative to cwdLibravatar Junio C Hamano1-1/+51
Without any explicit -o parameter, we correctly avoided putting the resulting patch output to the toplevel. We should do the same when the user gave a relative pathname to be consistent with this case. Noticed by Cesar Eduardo Barros. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-11Merge branch 'jc/maint-do-not-switch-to-non-commit' into maintLibravatar Junio C Hamano1-0/+4
* jc/maint-do-not-switch-to-non-commit: git checkout: do not allow switching to a tree-ish that is not a commit
2009-01-06diff: accept -- when using --no-indexLibravatar Thomas Rast2-0/+4
Accept -- as an "end of options" marker even when using --no-index. Previously, the -- triggered a "normal" index/tree diff and subsequently failed because of the unrecognized (in that mode) --no-index. Note that the second loop can treat '--' as a normal option, because the preceding checks ensure it is the third-to-last argument. While at it, fix the parsing of "-q" option in --no-index mode as well. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-05unpack-trees: fix path search bug in verify_absentLibravatar Clemens Buchacher1-0/+27
Commit 0cf73755 (unpack-trees.c: assume submodules are clean during check-out) changed an argument to verify_absent from 'path' to 'ce', which is however shadowed by a local variable of the same name. The bug triggers if verify_absent is used on a tree entry, for which the index contains one or more subsequent directories of the same length. The affected subdirectories are removed from the index. The testcase included in this commit bisects to 55218834 (checkout: do not lose staged removal), which reveals the bug in this case, but is otherwise unrelated. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-05unpack-trees: handle failure in verify_absentLibravatar Clemens Buchacher1-0/+24
Commit 203a2fe1 (Allow callers of unpack_trees() to handle failure) changed the "die on error" behavior to "return failure code". verify_absent did not handle errors returned by verify_clean_subdirectory, however. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-05git-sh-setup: Fix scripts whose PWD is a symlink to a work-dir on OS XLibravatar Marcel M. Cary1-2/+2
On Mac OS X and possibly BSDs, /bin/pwd reads PWD from the environment if available and shows the logical path by default rather than the physical one. Unset PWD before running /bin/pwd in both cd_to_toplevel and its test. Still use the external /bin/pwd because in my Bash on Linux, the builtin pwd prints the same result whether or not PWD is set. Signed-off-by: Marcel M. Cary <marcel@oak.homeunix.org> Tested-by: Wincent Colaiuta <win@wincent.com> (on Mac OS X 10.5.5) Tested-by: Marcel Koeppen <git-dev@marzelpan.de> (on Mac OS X 10.5.6) Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-05git add: do not add files from a submoduleLibravatar Johannes Schindelin1-0/+25
It comes quite as a surprise to an unsuspecting Git user that calling "git add submodule/file" (which is a mistake, alright) _removes_ the submodule in the index, and adds the file. Instead, complain loudly. While at it, be nice when the user said "git add submodule/" which is most likely the consequence of tab-completion, and stage the submodule, instead of trying to add the contents of that directory. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-03git checkout: do not allow switching to a tree-ish that is not a commitLibravatar Junio C Hamano1-0/+4
"git checkout -b newbranch $commit^{tree}" mistakenly created a new branch rooted at the current HEAD, because in that case, the two structure fields used to see if the command was invoked without any argument (hence it needs to default to checking out the HEAD) were populated incorrectly. Upon seeing a command line argument that we took as a rev, we should store that string in new.name, even if that does not name a commit. This will correctly trigger the existing safety logic. Signed-off-by: Junio C Hamano <gitster@pobox.com> Acked-by: Daniel Barkalow <barkalow@iabervon.org>
2009-01-02builtin-apply: prevent non-explicit permission changesLibravatar Junio C Hamano1-0/+62
A git patch that does not change the executable bit records the mode bits on its "index" line. "git apply" used to interpret this mode exactly the same way as it interprets the mode recorded on "new mode" line, as the wish by the patch submitter to set the mode to the one recorded on the line. The reason the mode does not agree between the submitter and the receiver in the first place is because there is _another_ commit that only appears on one side but not the other since their histories diverged, and that commit changes the mode. The patch has "index" line but not "new mode" line because its change is about updating the contents without affecting the mode. The application of such a patch is an explicit wish by the submitter to only cherry-pick the commit that updates the contents without cherry-picking the commit that modifies the mode. Viewed this way, the current behaviour is problematic, even though the command does warn when the mode of the path being patched does not match this mode, and a careful user could detect this inconsistencies between the patch submitter and the patch receiver. This changes the semantics of the mode recorded on the "index" line; instead of interpreting it as the submitter's wish to set the mode to the recorded value, it merely informs what the mode submitter happened to have, and the presense of the "index" line is taken as submitter's wish to keep whatever the mode is on the receiving end. This is based on the patch originally done by Alexander Potashev with a minor fix; the tests are mine. Signed-off-by: Junio C Hamano <gitster@pobox.com>