summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2009-02-18filter-branch -d: Export GIT_DIR earlierLibravatar Lars Noschinski2-6/+18
The improved error handling catches a bug in filter-branch when using -d pointing to a path outside any git repository: $ git filter-branch -d /tmp/foo master fatal: Not a git repository (or any of the parent directories): .git This error message comes from git for-each-ref in line 224. GIT_DIR is set correctly by git-sh-setup (to the foo.git repository), but not exported (yet). Signed-off-by: Lars Noschinski <lars@public.noschinski.de> Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-18disallow providing multiple upstream branches to rebase, pull --rebaseLibravatar Jay Soffian2-0/+6
It does not make sense to provide multiple upstream branches to either git pull --rebase, or to git rebase, so disallow both. Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-18git-svn: fix parsing of timestamp obtained from svnLibravatar Junio C Hamano1-1/+1
Ward Wouts reports that git-svn barfed like this: Unable to parse date: 2004-03-09T09:44:33.Z at /usr/bin/git-svn line 3995 The parse_svn_date sub expects there always are one or more digits after the decimal point to record fractional seconds, but this example does not and results in a failure like this. The fix is based on the original fix by the reporter, further cleaned up. Signed-off-by: Junio C Hamano <gitster@pobox.com> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-02-18gitweb: Fix warnings with override permitted but no repo overrideLibravatar Marcel M. Cary2-7/+27
When a feature like "blame" is permitted to be overridden in the repository configuration but it is not actually set in the repository, a warning is emitted due to the undefined value of the repository configuration, even though it's a perfectly normal condition. Emitting warning is grounds for test failure in the gitweb test script. This error was caused by rewrite of git_get_project_config from using "git config [<type>] <name>" for each individual configuration variable checked to parsing "git config --list --null" output in commit b201927 (gitweb: Read repo config using 'git config -z -l'). Earlier version of git_get_project_config was returning empty string if variable do not exist in config; newer version is meant to return undef in this case, therefore change in feature_bool was needed. Additionally config_to_* subroutines were meant to be invoked only if configuration variable exists; therefore we added early return to git_get_project_config: it now returns no value if variable does not exists in config. Otherwise config_to_* subroutines (config_to_bool in paryicular) wouldn't be able to distinguish between the case where variable does not exist and the case where variable doesn't have value (the "[section] noval" case, which evaluates to true for boolean). While at it fix bug in config_to_bool, where checking if $val is defined (if config variable has value) was done _after_ stripping leading and trailing whitespace, which lead to 'Use of uninitialized value' warning. Add test case for features overridable but not overriden in repo config, and case for no value boolean configuration variable. Signed-off-by: Marcel M. Cary <marcel@oak.homeunix.org> Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-18bash completion: only show 'log --merge' if mergingLibravatar Thomas Rast1-1/+6
The gitk completion only shows --merge if MERGE_HEAD is present. Do it the same way for git-log completion. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Acked-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-18bash completion: refactor common log, shortlog and gitk optionsLibravatar Thomas Rast1-15/+34
Refactor options that are useful for more than one of them into a variable used by the relevant completions. This has the effect of adding the following options to git-log: --branches --tags --remotes --first-parent --dense --sparse --simplify-merges --simplify-by-decoration --first-parent --no-merges The following to git-shortlog: --branches --tags --remotes --first-parent And the following to gitk: --branches --tags --remotes --first-parent --no-merges --max-count= --max-age= --since= --after= --min-age= --until= --before= --dense --sparse --full-history --simplify-merges --simplify-by-decoration --left-right Signed-off-by: Thomas Rast <trast@student.ethz.ch> Acked-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-16gitweb: fix wrong base URL when non-root DirectoryIndexLibravatar Giuseppe Bilotta2-8/+26
CGI::url() has some issues when rebuilding the script URL if the script is a DirectoryIndex. One of these issue is the inability to strip PATH_INFO, which is why we had to do it ourselves. Another issue is that the resulting URL cannot be used for the <base> tag: it works if we're the DirectoryIndex at the root level, but not otherwise. We fix this by building the proper base URL ourselves, and improve the comment about the need to strip PATH_INFO manually while we're at it. Additionally t/t9500-gitweb-standalone-no-errors.sh had to be modified to set SCRIPT_NAME variable (CGI standard states that it MUST be set, and now gitweb uses it if PATH_INFO is not empty, as is the case for some of tests in t9500). Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com> Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-16bash: update 'git svn' optionsLibravatar SZEDER Gábor1-6/+25
'git svn' got some new subcommands and otions in the last couple of months. This patch adds completion support for them. In particular: * 'fetch', 'clone', etc.: '--ignore-paths=' * 'init' and 'clone': '--prefix=', '--use-log-author', '--add-author-from' * 'dcommit': '--commit-url', '--revision' * 'log': '--color' * 'rebase': '--dry-run' * 'branch', 'tag', 'blame', 'migrate' subcommands and their options Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Acked-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-16bash: add missing 'git merge' optionsLibravatar SZEDER Gábor1-0/+1
Namely: '--commit', '--stat', '--no-squash', '--ff', '--no-ff'. One might wonder why add options that specify the default behaviour anyway (e.g. '--commit', '--no-squash', etc.). Users can override the default with config options (e.g. 'branch.<name>.mergeoptions', 'merge.log'), but sometimes might still need the default behaviour. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Acked-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-15git-svn: Fix for rewriteRoot URL containing username.Libravatar Dévai Tamás1-0/+1
If the new svn root URL given with the svn-remote.<repo>.rewriteRoot config option (or by the --rewrite-root option to 'git svn init') contains a username (such as 'svn+ssh://username@example.com/repo'), find_by_url() cannot find the repository URL, because the URL contained in the commit message does have the username removed. Signed-off-by: Dévai Tamás <devait@mailbox.sk> Acked-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-15builtin-receive-pack.c: fix compiler warnings about format stringLibravatar René Scharfe1-2/+2
While all of the strings passed to warning() are, in fact, literals, the compiler doesn't recognize them as such because it doesn't see through the loop used to iterate over them: builtin-receive-pack.c: In function 'warn_unconfigured_deny': builtin-receive-pack.c:247: warning: format not a string literal and no format arguments builtin-receive-pack.c: In function 'warn_unconfigured_deny_delete_current': builtin-receive-pack.c:273: warning: format not a string literal and no format arguments Calm the compiler by adding easily recognizable format string literals. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-15RelNotes UpdateLibravatar Junio C Hamano1-4/+26
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-15Merge branch 'mc/setup-cd-p'Libravatar Junio C Hamano2-23/+10
* mc/setup-cd-p: git-sh-setup: Use "cd" option, not /bin/pwd, for symlinked work tree
2009-02-15Merge branch 'ff/submodule-no-fetch'Libravatar Junio C Hamano2-4/+22
* ff/submodule-no-fetch: submodule: add --no-fetch parameter to update command
2009-02-15Merge branch 'ms/mailmap'Libravatar Junio C Hamano15-130/+644
* ms/mailmap: Move mailmap documentation into separate file Change current mailmap usage to do matching on both name and email of author/committer. Add map_user() and clear_mailmap() to mailmap Add find_insert_index, insert_at_index and clear_func functions to string_list Add mailmap.file as configurational option for mailmap location
2009-02-15Merge branch 'jn/gitweb-committag'Libravatar Junio C Hamano1-1/+1
* jn/gitweb-committag: gitweb: Better regexp for SHA-1 committag match
2009-02-15Merge branch 'rc/http-push'Libravatar Junio C Hamano2-2/+18
* rc/http-push: use a hash of the lock token as the suffix for PUT/MOVE
2009-02-15use a hash of the lock token as the suffix for PUT/MOVELibravatar Tay Ray Chuan2-2/+18
After 753bc91 ("Remove the requirement opaquelocktoken uri scheme"), lock tokens are in the URI forms in which they are received from the server, eg. 'opaquelocktoken:', 'urn:uuid:'. However, "start_put" (and consequently "start_move"), which attempts to create a unique temporary file using the UUID of the lock token, inadvertently uses the lock token in its URI form. These file operations on the server may not be successful (specifically, in Windows), due to the colon ':' character from the URI form of the lock token in the file path. This patch uses a hash of the lock token instead, guaranteeing only "safe" characters (a-f, 0-9) are used in the file path. The token's hash is generated when the lock token is received from the server in handle_new_lock_ctx, minimizing the number of times of hashing. Signed-off-by: Tay Ray Chuan <rctay89@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-15Merge branch 'js/gc-prune'Libravatar Junio C Hamano3-8/+59
* js/gc-prune: gc: make --prune useful again by accepting an optional parameter
2009-02-15Merge branch 'tr/abbrev-commit-no-ellipses'Libravatar Junio C Hamano16-21/+19
* tr/abbrev-commit-no-ellipses: log: do not print ellipses with --abbrev-commit
2009-02-15Merge branch 'jc/branch-previous'Libravatar Junio C Hamano4-20/+94
* jc/branch-previous: Teach @{-1} to git merge Teach the "@{-1} syntax to "git branch"
2009-02-14bash: fix misspelled 'git svn' optionLibravatar SZEDER Gábor1-1/+1
'--user-log-author' -> '--use-log-author' Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-14t1500: more 'git rev-parse --git-dir' testsLibravatar SZEDER Gábor1-3/+3
Extend t1500 with tests of 'git rev-parse --git-dir' when invoked from other directories of the repository or the work tree. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-14Move 'rev-parse --git-dir' test to t1500Libravatar SZEDER Gábor2-9/+9
Commit 72183cb2 (Fix gitdir detection when in subdir of gitdir, 2009-01-16) added a test to 't1501-worktree' to check the behaviour of 'git rev-parse --git-dir' in a special case. However, t1501 is about testing separate work tree setups, and not about basic 'rev-parse' functionality, which is tested in t1500-rev-parse. Therefore, this patch moves that test to t1500. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-14Documentation: pruning recipe for destructive filter-branchLibravatar Thomas Rast1-0/+41
Add a section about how to shrink a repository's size after running git-filter-branch to remove large blobs from history. This comes up every week or so on IRC, and the commands required to handle every case are not very newbie-friendly, so hopefully writing them down somewhere leads to fewer questions. It may seem contradictory to document fallbacks for older Gits in newer docs, but we want to point people at this as a FAQ answer, and they will frequently not have the newest version installed. Thanks to Björn Steinbrink and Junio C Hamano for comments and corrections. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-14gc: make --prune useful again by accepting an optional parameterLibravatar Johannes Schindelin3-8/+59
With this patch, "git gc --no-prune" will not prune any loose (and dangling) object, and "git gc --prune=5.minutes.ago" will prune all loose objects older than 5 minutes. This patch benefitted from suggestions by Thomas Rast and Jan Krï¿œger. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-13Teach @{-1} to git mergeLibravatar Junio C Hamano2-3/+35
1.6.2 will have @{-1} syntax advertised as "usable anywhere you can use a branch name". However, "git merge @{-1}" did not work. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-13Teach the "@{-1} syntax to "git branch"Libravatar Junio C Hamano3-17/+59
This teaches the new "@{-1} syntax to refer to the previous branch to "git branch". After looking at somebody's faulty patch series on a topic branch too long, if you decide it is not worth merging, you can just say: $ git checkout master $ git branch -D @{-1} to get rid of it without having to type the name of the topic you now hate so much for wasting a lot of your time. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-13symbolic-ref: allow refs/<whatever> in HEADLibravatar Jeff King2-7/+2
Commit afe5d3d5 introduced a safety valve to symbolic-ref to disallow installing an invalid HEAD. It was accompanied by b229d18a, which changed validate_headref to require that HEAD contain a pointer to refs/heads/ instead of just refs/. Therefore, the safety valve also checked for refs/heads/. As it turns out, topgit is using refs/top-bases/ in HEAD, leading us to re-loosen (at least temporarily) the validate_headref check made in b229d18a. This patch does the corresponding loosening for the symbolic-ref safety valve, so that the two are in agreement once more. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-13Remove redundant bit clears from diff_setup()Libravatar Keith Cascio1-3/+0
All bits already clear after memset(0). Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-13log: do not print ellipses with --abbrev-commitLibravatar Thomas Rast16-21/+19
'git log --abbrev-commit' added an ellipsis to all commit names that were abbreviated. This was particularly annoying if you wanted to cut&paste the sha1 from the terminal, since selecting by word would pick up '...' too. So use find_unique_abbrev() instead of diff_unique_abbrev() in all log-related commit sha1 printing routines, and also change the formatting of the 'Merge: parent1 parent2' line output via pretty_print_commit(). Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-13bash-completion: Complete the values of color.interactive, color.ui, color.pagerLibravatar Matt Kraai1-1/+5
Signed-off-by: Matt Kraai <kraai@ftbfs.org> Acked-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-12Install the default "master" branch configuration after cloning a voidLibravatar Junio C Hamano2-5/+33
After "cloning from an empty repository", we have a configuration to describe the remote's URL and the default ref mappings, but we lack the branch configuration for the default branch we create on our end, "master". It is likely that the empty repository we cloned from will point the default "master" branch with its HEAD, so prepare the local configuration to match. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-12Update documentation to add further information about using Thunderbird with ↵Libravatar Jeremy White2-0/+41
git-imap-send. Signed-off-by: Jeremy White <jwhite@codeweavers.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-12git-rebase.txt: --interactive does not work with --whitespaceLibravatar Mark Burton1-0/+1
Signed-off-by: Mark Burton <markb@ordern.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-12Add 'rm -f' equivalent to 'git rm' example of filter-branch --index-filterLibravatar Jacob Helwig1-0/+5
Signed-off-by: Jacob Helwig <jacob.helwig@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-12Revert "validate_headref: tighten ref-matching to just branches"Libravatar Junio C Hamano1-2/+2
This reverts commit b229d18a809c169314b7f0d048dc5a7632e8f916, at least until we figure out how to work better with TopGit that points HEAD to refs/top-bases/ hierarchy.
2009-02-12Bugfix: GIT_EXTERNAL_DIFF with more than one changed filesLibravatar Nazri Ramliy2-4/+12
When there is more than one file that are changed, running git diff with GIT_EXTERNAL_DIFF incorrectly diagnoses an programming error and dies. The check introduced in 479b0ae (diff: refactor tempfile cleanup handling, 2009-01-22) to detect a temporary file slot that forgot to remove its temporary file was inconsistent with the way the codepath to remove the temporary to mark the slot that it is done with it. This patch fixes this problem and adds a test case for it. Signed-off-by: Nazri Ramliy <ayiehere@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-11Merge branch 'maint'Libravatar Junio C Hamano4-20/+88
* maint: Prepare for 1.6.1.4. Make repack less likely to corrupt repository fast-export: ensure we traverse commits in topological order Clear the delta base cache if a pack is rebuilt Conflicts: RelNotes
2009-02-11Prepare for 1.6.1.4.Libravatar Junio C Hamano2-1/+20
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-11Merge branch 'maint-1.6.0' into maintLibravatar Junio C Hamano3-20/+69
* maint-1.6.0: Make repack less likely to corrupt repository fast-export: ensure we traverse commits in topological order Clear the delta base cache if a pack is rebuilt
2009-02-11Make repack less likely to corrupt repositoryLibravatar Junio C Hamano1-20/+67
Some platforms refuse to rename a file that is open. When repacking an already packed repository without adding any new object, the resulting pack will contain the same set of objects as an existing pack, and on such platforms, a newly created packfile cannot replace the existing one. The logic detected this issue but did not try hard enough to recover from it. Especially because the files that needs renaming come in pairs, there potentially are different failure modes that one can be renamed but the others cannot. Asking manual recovery to end users were error prone. This patch tries to make it more robust by first making sure all the existing files that need to be renamed have been renamed before continuing, and attempts to roll back if some failed to rename. This is based on an initial patch by Robin Rosenberg. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-11fast-export: ensure we traverse commits in topological orderLibravatar Elijah Newren1-0/+1
fast-export will only list as parents those commits which have already been traversed (making it appear as if merges have been squashed if not all parents have been traversed). To avoid this silent squashing of merge commits, we request commits in topological order. Signed-off-by: Elijah Newren <newren@gmail.com> Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-11filter-branch: Add more error-handlingLibravatar Eric Kidd2-12/+18
9273b56 (filter-branch: Fix fatal error on bare repositories, 2009-02-03) fixed a missing check of return status from an underlying command in git-filter-branch, but there still are places that do not check errors. For example, the command does not pay attention to the exit status of the command given by --commit-filter. It should abort in such a case. This attempts to fix all the remaining places that fails to checks errors. In two places, I've had to break apart pipelines in order to check the error code for the first stage of the pipeline, as discussed here: http://kerneltrap.org/mailarchive/git/2009/1/28/4835614 Feedback on this patch was provided by Johannes Sixt, Johannes Schindelin and Junio C Hamano. Thomas Rast helped with pipeline error handling. Signed-off-by: Eric Kidd <git@randomhacks.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-11Fix contrib/hooks/post-receive-email for new duplicate branchLibravatar Pat Notz1-1/+3
In the show_new_revisions function, the original code: git rev-parse --not --branches | grep -v $(git rev-parse $refname) | isn't quite right since one can create a new branch and push it without any new commits. In that case, two refs will have the same sha1 but both would get filtered by the 'grep'. In the end, we'll show ALL the history which is not what we want. Instead, we should list the branches by name and remove the branch being updated and THEN pass that list through rev-parse. Revised as suggested by Jakub Narebski and Junio C Hamano to use git-for-each-ref instead of git-branch. (Thanks!) Signed-off-by: Pat Notz <pknotz@sandia.gov> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-11Clear the delta base cache if a pack is rebuiltLibravatar Shawn O. Pearce1-0/+1
There is some risk that re-opening a regenerated pack file with different offsets could leave stale entries within the delta base cache that could be matched up against other objects using the same "struct packed_git*" and pack offset. Throwing away the entire delta base cache in this case is safer, as we don't have to worry about a recycled "struct packed_git*" matching to the wrong base object, resulting in delta apply errors while unpacking an object. Suggested-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-11Merge git://git.bogomips.org/git-svnLibravatar Junio C Hamano5-21/+279
* git://git.bogomips.org/git-svn: test case for regression caused by git-svn empty symlink fix git-svn: fix broken symlink workaround when switching branches git-svn: Print revision while searching for earliest use of path git-svn: abstract out a block into new method other_gs() git-svn: allow disabling expensive broken symlink checks
2009-02-11Squelch overzealous "ignoring dangling symref" in an empty repositoryLibravatar Junio C Hamano1-1/+2
057e713 (Warn use of "origin" when remotes/origin/HEAD is dangling, 2009-02-08) tried to warn dangling refs/remotes/origin/HEAD only when "origin" was used to refer to it. There was one corner case a symref is expected to be dangling and this warning is unwarranted: HEAD in an empty repository. This squelches the warning for this special case. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-11test case for regression caused by git-svn empty symlink fixLibravatar Anton Gyllenberg2-0/+208
Commit dbc6c74d0858d77e61e092a48d467e725211f8e9 "git-svn: handle empty files marked as symlinks in SVN" caused a regression in an unusual case where a branch has been created in SVN, later deleted and then created again from another branch point and the original branch point had empty files not in the new branch. In some cases git svn fetch will then fail while trying to fetch the empty file from the wrong SVN revision. This adds a test case that reproduces the issue. [ew: added additional test to ensure file was created correctly made test file executable ] Signed-off-by: Anton Gyllenberg <anton@iki.fi> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-02-11git-svn: fix broken symlink workaround when switching branchesLibravatar Eric Wong1-5/+6
Thanks to Anton Gyllenberg <anton@iki.fi> for the bug report (and testcase in the following commit): > Commit dbc6c74d0858d77e61e092a48d467e725211f8e9 "git-svn: > handle empty files marked as symlinks in SVN" caused a > regression in an unusual case where a branch has been created > in SVN, later deleted and then created again from another > branch point and the original branch point had empty files not > in the new branch. In some cases git svn fetch will then fail > while trying to fetch the empty file from the wrong SVN > revision. Signed-off-by: Eric Wong <normalperson@yhbt.net>