summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2009-01-21chain kill signals for cleanup functionsLibravatar Jeff King1-0/+22
If a piece of code wanted to do some cleanup before exiting (e.g., cleaning up a lockfile or a tempfile), our usual strategy was to install a signal handler that did something like this: do_cleanup(); /* actual work */ signal(signo, SIG_DFL); /* restore previous behavior */ raise(signo); /* deliver signal, killing ourselves */ For a single handler, this works fine. However, if we want to clean up two _different_ things, we run into a problem. The most recently installed handler will run, but when it removes itself as a handler, it doesn't put back the first handler. This patch introduces sigchain, a tiny library for handling a stack of signal handlers. You sigchain_push each handler, and use sigchain_pop to restore whoever was before you in the stack. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-10t7501-commit.sh: explicitly check that -F prevents invoking the editorLibravatar Adeodato Simó2-4/+21
The "--signoff" test case in t7500-commit.sh was setting VISUAL while using -F -, which indeed tested that the editor is not spawned with -F. However, having it there was confusing, since there was no obvious reason to the casual reader for it to be there. This commits removes the setting of VISUAL from the --signoff test, and adds in t7501-commit.sh a dedicated test case, where the rest of tests for -F are. Signed-off-by: Adeodato Simó <dato@net.com.org.es> Okay-then-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-10filter-branch: add git_commit_non_empty_tree and --prune-empty.Libravatar Pierre Habouzit1-0/+8
git_commit_non_empty_tree is added to the functions that can be run from commit filters. Its effect is to commit only commits actually touching the tree and that are not merge points either. The option --prune-empty is added. It defaults the commit-filter to 'git_commit_non_empty_tree "$@"', and can be used with any other combination of filters, except --commit-hook that must used 'git_commit_non_empty_tree "$@"' where one puts 'git commit-tree "$@"' usually to achieve the same result. Signed-off-by: Pierre Habouzit <madcoder@debian.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-07Merge branch 'rs/diff-ihc'Libravatar Junio C Hamano1-0/+92
* rs/diff-ihc: diff: add option to show context between close hunks Conflicts: Documentation/diff-options.txt
2009-01-07Merge branch 'js/maint-merge-recursive-r-d-conflict'Libravatar Junio C Hamano1-0/+23
* js/maint-merge-recursive-r-d-conflict: merge-recursive: mark rename/delete conflict as unmerged
2009-01-07Merge branch 'cb/merge-recursive-fix'Libravatar Junio C Hamano1-0/+87
* cb/merge-recursive-fix: merge-recursive: do not clobber untracked working tree garbage modify/delete conflict resolution overwrites untracked file
2009-01-03Merge branch 'jc/maint-do-not-switch-to-non-commit'Libravatar 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-03Merge branch 'ap/maint-apply-modefix'Libravatar Junio C Hamano1-0/+62
* ap/maint-apply-modefix: builtin-apply: prevent non-explicit permission changes
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>
2008-12-29Merge branch 'np/auto-thread'Libravatar Junio C Hamano1-0/+1
* np/auto-thread: Force t5302 to use a single thread pack-objects: don't use too many threads with few objects autodetect number of CPUs by default when using threads
2008-12-29diff: add option to show context between close hunksLibravatar René Scharfe1-0/+92
Merge two hunks if there is only the specified number of otherwise unshown context between them. For --inter-hunk-context=1, the resulting patch has the same number of lines but shows uninterrupted context instead of a context header line in between. Patches generated with this option are easier to read but are also more likely to conflict if the file to be patched contains other changes. This patch keeps the default for this option at 0. It is intended to just make the feature available in order to see its advantages and downsides. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-12-27Merge branch 'sp/maint-describe-all-tag-warning' into maintLibravatar Junio C Hamano1-0/+6
* sp/maint-describe-all-tag-warning: describe: Avoid unnecessary warning when using --all
2008-12-26describe: Avoid unnecessary warning when using --allLibravatar Shawn O. Pearce1-0/+6
In 212945d4 ("Teach git-describe to verify annotated tag names before output") git-describe learned how to output a warning if an annotated tag object was matched but its internal name doesn't match the local ref name. However, "git describe --all" causes the local ref name to be prefixed with "tags/", so we need to skip over this prefix before comparing the local ref name with the name recorded inside of the tag object. Patch-by: René Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-12-24merge-recursive: mark rename/delete conflict as unmergedLibravatar Johannes Schindelin1-0/+23
When a file was renamed in one branch, but deleted in the other, one should expect the index to contain an unmerged entry, namely the target of the rename. Make it so. Noticed by Constantine Plotnikov. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-12-24Merge branch 'js/rebase-i-p'Libravatar Junio C Hamano1-11/+45
* js/rebase-i-p: rebase -i -p: leave a --cc patch when a merge could not be redone rebase -i -p: Fix --continue after a merge could not be redone Show a failure of rebase -p if the merge had a conflict
2008-12-24rebase -i -p: leave a --cc patch when a merge could not be redoneLibravatar Johannes Schindelin1-0/+1
The result is easier to review this way, and the merge resolution has to be done inside the work tree, not by adjusting "the patch" anyway.
2008-12-22t9129: skip the last three tests if UTF-8 locale is not availableLibravatar Miklos Vajna1-13/+17
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-12-21Make sure lockfiles are unlocked when dying on SIGPIPELibravatar Junio C Hamano1-0/+17
We cleaned up lockfiles upon receiving the usual suspects HUP, TERM, QUIT but a wicked user could kill us of asphyxiation by piping our output to a pipe that does not read. Protect ourselves by catching SIGPIPE and clean up the lockfiles as well in such a case. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-12-21git-sh-setup: Fix scripts whose PWD is a symlink into a git work-dirLibravatar Marcel M. Cary2-0/+115
I want directories of my working tree to be linked to from various paths on my filesystem where third-party components expect them, both in development and production environments. A build system's install step could solve this, but I develop scripts and web pages that don't need to be built. Git's submodule system could solve this, but we tend to develop, branch, and test those directories all in unison, so one big repository feels more natural. We prefer to edit and commit on the symlinked paths, not the canonical ones, and in that setting, "git pull" fails to find the top-level directory of the repository while other commands work fine. "git pull" fails because POSIX shells have a notion of current working directory that is different from getcwd(). The shell stores this path in PWD. As a result, "cd ../" can be interpreted differently in a shell script than chdir("../") in a C program. The shell interprets "../" by essentially stripping the last textual path component from PWD, whereas C chdir() follows the ".." link in the current directory on the filesystem. When PWD is a symlink, these are different destinations. As a result, Git's C commands find the correct top-level working tree, and shell scripts do not. Changes: * When interpreting a relative upward (../) path in cd_to_toplevel, prepend the cwd without symlinks, given by /bin/pwd * Add tests for cd_to_toplevel and "git pull" in a symlinked directory that failed before this fix, plus contrasting scenarios that already worked Signed-off-by: Marcel M. Cary <marcel@oak.homeunix.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-12-21rebase -i -p: Fix --continue after a merge could not be redoneLibravatar Johannes Sixt1-1/+1
When a merge that has a conflict was rebased, then rebase stopped to let the user resolve the conflicts. However, thereafter --continue failed because the author-script was not saved. (This is rebase -i's way to preserve a commit's authorship.) This fixes it by doing taking the same failure route after a merge that is also taken after a normal cherry-pick. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-12-21Show a failure of rebase -p if the merge had a conflictLibravatar Johannes Sixt1-11/+44
This extends t3409-rebase-preserve-merges by a case where the merge that is rebased has a conflict. Therefore, the rebase stops and expects that the user resolves the conflict. However, currently rebase --continue fails because .git/rebase-merge/author-script is missing. The test script had allocated two identical clones, but only one of them (clone2) was used. Now we use both as indicated in the comment. Also, two instances of && was missing in the setup part. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-12-19Merge branch 'maint' to sync with GIT 1.6.0.6Libravatar Junio C Hamano2-0/+38
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-12-19fast-import: make tagger information optionalLibravatar Junio C Hamano1-0/+18
Even though newer Porcelain tools always record the tagger information when creating new tags, export/import pair should be able to faithfully reproduce ancient tag objects that lack tagger information. Signed-off-by: Junio C Hamano <gitster@pobox.com> Acked-by: Shawn O. Pearce <spearce@spearce.org>
2008-12-19fast-export: deal with tag objects that do not have a taggerLibravatar Johannes Schindelin1-0/+20
When no tagger was found (old Git produced tags like this), no "tagger" line is printed (but this is incompatible with the current git fast-import). Alternatively, you can pass the option --fake-missing-tagger, forcing fast-export to fake a tagger Unspecified Tagger <no-tagger> with a tag date of the beginning of (Unix) time in the case of a missing tagger, so that fast-import is still able to import the result. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-12-18test overlapping ignore patternsLibravatar Michael J Gruber1-0/+6
Add a test which checks that negated patterns such as "!foo.html" can override previous patterns such as "*.html". This is documented behaviour but had not been tested so far. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-12-15Merge branch 'maint'Libravatar Junio C Hamano1-0/+20
* maint: fast-import: close pack before unlinking it pager: do not dup2 stderr if it is already redirected git-show: do not segfault when showing a bad tag
2008-12-15Force t5302 to use a single threadLibravatar Johannes Schindelin1-0/+1
If the packs are made using multiple threads, they are no longer identical on the 4-core Xeon I tested on. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Acked-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-12-15Merge branch 'cb/maint-merge-recursive-fix' into cb/merge-recursive-fixLibravatar 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
2008-12-15merge-recursive: do not clobber untracked working tree garbageLibravatar Junio C Hamano1-1/+1
When merge-recursive wanted to create a new file in the work tree (either as the final result, or a hint for reference purposes while delete/modify conflicts), it unconditionally overwrote an untracked file in the working tree. Be careful not to lose whatever the user has that is not tracked. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-12-15modify/delete conflict resolution overwrites untracked fileLibravatar Clemens Buchacher1-0/+87
If a file was removed in HEAD, but modified in MERGE_HEAD, recursive merge will result in a "CONFLICT (delete/modify)". If the (now untracked) file already exists and was not added to the index, it is overwritten with the conflict resolution contents. In similar situations (cf. test 2), the merge would abort with "error: Untracked working tree 'file' would be overwritten by merge." The same should happen in this case. Signed-off-by: Clemens Buchacher <drizzd@aon.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-12-15git-show: do not segfault when showing a bad tagLibravatar Junio C Hamano1-0/+20
When a tag points at a bad or nonexistent object, we should diagnose the breakage and exit. An earlier commit 4f3dcc2 (Fix 'git show' on signed tag of signed tag of commit, 2008-07-01) lost this check and made it segfault instead; not good. This fixes it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-12-14Get rid of the last remnants of GIT_CONFIG_LOCALLibravatar Johannes Schindelin2-2/+1
In dc871831(Only use GIT_CONFIG in "git config", not other programs), GIT_CONFIG_LOCAL was rested in peace, in favor of not reading /etc/gitconfig and $HOME/.gitconfig at all when GIT_CONFIG is set. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-12-12git-branch: display sha1 on branch deletionLibravatar Brandon Casey1-1/+2
Make it easier to recover from a mistaken branch deletion by displaying the sha1 of the branch's tip commit. Update t3200 test to match the change in output. Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-12-10Fix t4031Libravatar Junio C Hamano1-1/+1
When I tweaked the patch to use $SHELL_PATH instead of a hard-coded "#!/bin/sh" to produce 3aa1f7c (diff: respect textconv in rewrite diffs, 2008-12-09), I screwed up. This should fix it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-12-09Merge branch 'maint'Libravatar Junio C Hamano1-0/+42
* maint: work around Python warnings from AsciiDoc git-svn: Make following parents atomic
2008-12-09diff: respect textconv in rewrite diffsLibravatar Jeff King1-1/+23
Currently we just skip rewrite diffs for binary files; this patch makes an exception for files which will be textconv'd, and actually performs the textconv before generating the diff. Conceptually, rewrite diffs should be in the exact same format as the a non-rewrite diff, except that we refuse to share any context. Thus it makes very little sense for "git diff" to show a textconv'd diff, but for "git diff -B" to show "Binary files differ". Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-12-09diff: fix handling of binary rewrite diffsLibravatar Jeff King1-0/+45
The current emit_rewrite_diff code always writes a text patch without checking whether the content is binary. This means that if you end up with a rewrite diff for a binary file, you get lots of raw binary goo in your patch. Instead, if we have binary files, then let's just skip emit_rewrite_diff altogether. We will already have shown the "dissimilarity index" line, so it is really about the diff contents. If binary diffs are turned off, the "Binary files a/file and b/file differ" message should be the same in either case. If we do have binary patches turned on, there isn't much point in making a less-efficient binary patch that does a total rewrite; no human is going to read it, and since binary patches don't apply with any fuzz anyway, the result of application should be the same. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-12-08git-svn: Make following parents atomicLibravatar Deskin Miller1-0/+42
find_parent_branch generates branch@rev type branches when one has to look back through SVN history to properly get the history for a branch copied from somewhere not already being tracked by git-svn. If in the process of fetching this history, git-svn is interrupted, then when one fetches again, it will use whatever was last fetched as the parent commit and fail to fetch any more history which it didn't get to before being terminated. This is especially troubling in that different git-svn copies of the same SVN repository can end up with different commit sha1s, incorrectly showing the history as divergent and precluding easy collaboration using git push and fetch. To fix this, when we initialise the Git::SVN object $gs to search for and perhaps fetch history, we check if there are any commits in SVN in the range between the current revision $gs is at, and the top revision for which we were asked to fill history. If there are commits we're missing in that range, we continue the fetch from the current revision to the top, properly getting all history before using it as the parent for the branch we're trying to create. Signed-off-by: Deskin Miller <deskinm@umich.edu> Acked-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-12-08gitweb: Fix bug in insert_file() subroutineLibravatar Jakub Narebski1-0/+10
In insert_file() subroutine (which is used to insert HTML fragments as custom header, footer, hometext (for projects list view), and per project README.html (for summary view)) we used: map(to_utf8, <$fd>); This doesn't work, and other form has to be used: map { to_utf8($_) } <$fd>; Now with test for t9600 added, for $GIT_DIR/README.html. Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-12-07"git diff <tree>{3,}": do not reverse order of argumentsLibravatar Matt McCutchen2-0/+30
According to the message of commit 0fe7c1de16f71312e6adac4b85bddf0d62a47168, "git diff" with three or more trees expects the merged tree first followed by the parents, in order. However, this command reversed the order of its arguments, resulting in confusing diffs. A comment /* Again, the revs are all reverse */ suggested there was a reason for this, but I can't figure out the reason, so I removed the reversal of the arguments. Test case included. Signed-off-by: Matt McCutchen <matt@mattmccutchen.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-12-05git-am: rename apply_opt_extra file to apply-optLibravatar Junio C Hamano1-1/+0
All other state files use dash in their names, not underscores. Also, there is no reason to call this "extra". Drop it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-12-04Test that git-am does not lose -C/-p/--whitespace optionsLibravatar Junio C Hamano11-0/+229
These tests make sure that "git am" does not lose command line options specified when it was started, after it is interrupted by a patch that does not apply earlier in the series. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-12-03Merge branch 'dm/svn-remote'Libravatar Junio C Hamano1-0/+19
* dm/svn-remote: git-svn: Make branch use correct svn-remote
2008-12-03git-svn: Make branch use correct svn-remoteLibravatar Deskin Miller1-0/+19
The 'branch' subcommand incorrectly had the svn-remote to use hardcoded as 'svn', the default remote name. This meant that branches derived from other svn-remotes would try to use the branch and tag configuration for the 'svn' remote, potentially copying would-be branches to the wrong place in SVN, into the branch namespace for another project. Fix this by using the remote name extracted from the svn info for the specified git ref. Add a testcase for this behaviour. [jc: squashed in a fix to test from Michael J Gruber for older svn (1.4)] Signed-off-by: Deskin Miller <deskinm@umich.edu> Acked-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-12-03Merge branch 'jc/rm-i-t-a'Libravatar Junio C Hamano2-2/+30
* jc/rm-i-t-a: git add --intent-to-add: do not let an empty blob be committed by accident git add --intent-to-add: fix removal of cached emptiness builtin-rm.c: explain and clarify the "local change" logic Extend index to save more flags
2008-12-02Merge branch 'jk/maint-commit-v-strip' into maintLibravatar Junio C Hamano1-0/+73
* jk/maint-commit-v-strip: commit: Fix stripping of patch in verbose mode.
2008-12-02Merge branch 'bc/maint-keep-pack' into maintLibravatar Junio C Hamano2-3/+88
* bc/maint-keep-pack: repack: only unpack-unreachable if we are deleting redundant packs t7700: test that 'repack -a' packs alternate packed objects pack-objects: extend --local to mean ignore non-local loose objects too sha1_file.c: split has_loose_object() into local and non-local counterparts t7700: demonstrate mishandling of loose objects in an alternate ODB builtin-gc.c: use new pack_keep bitfield to detect .keep file existence repack: do not fall back to incremental repacking with [-a|-A] repack: don't repack local objects in packs with .keep file pack-objects: new option --honor-pack-keep packed_git: convert pack_local flag into a bitfield and add pack_keep t7700: demonstrate mishandling of objects in packs with a .keep file
2008-12-02t4030-diff-textconv: Make octal escape sequence more portableLibravatar Johannes Sixt1-1/+1
There are printfs around that do not grok '\1', but need '\01'. Discovered on AIX 4.3.x. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-12-02bisect: fix "git bisect skip <commit>" and add tests casesLibravatar Christian Couder1-1/+18
The patch that allows "git bisect skip" to be passed a range of commits using the "<commit1>..<commit2>" notation is flawed because it introduces a regression when it was passed a simple rev or commit. "git bisect skip <commit>" doesn't work any more, because <commit> is quoted but not properly unquoted. This patch fixes that and add tests cases to better check when it is passed commits and range of commits. While at it, this patch also properly quotes the non range arguments using the "sq" function. Signed-off-by: Christian Couder <chriscool@tuxfamily.org>