summaryrefslogtreecommitdiffstats
path: root/pack-check.c (unfollow)
Commit message (Collapse)AuthorFilesLines
2009-11-21describe: do not use unannotated tag even if exact matchThomas Rast2-1/+7
4d23660 (describe: when failing, tell the user about options that work, 2009-10-28) forgot to update the shortcut path where the code detected and used a possible exact match. This means that an unannotated tag on HEAD would be used by 'git describe'. Guard this code path against the new circumstances, where unannotated tags can be present in ->util even if we're not actually planning to use them. While there, also add some tests for --all. Reported by 'yashi' on IRC. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-21submodule.c: Squelch a "use before assignment" warningDavid Aguilar1-1/+1
i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5493) compiler (and probably others) mistakenly thinks variable 'right' is used before assigned. Work around it by giving it a fake initialization. Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-18ls-tree: migrate to parse-optionsStephen Boyd1-60/+40
Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-17Document git-svn's first-parent ruleThomas Rast1-0/+10
git-svn has the following rule to detect the SVN base for its operations: find the first git-svn-id line reachable through first-parent ancestry. IOW, git log --grep=^git-svn-id: --first-parent -1 Document this, as it is very important when using merges with git-svn. Signed-off-by: Thomas Rast <trast@student.ethz.ch>
2009-11-17t3101: test more ls-tree optionsStephen Boyd1-2/+87
Add tests for --full-name, --full-tree, --abbrev, and --name-only. Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-16Update draft release notes to 1.6.6Junio C Hamano1-27/+27
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-16Git 1.6.5.3v1.6.5.3Junio C Hamano4-3/+67
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-16git svn: attempt to create empty dirs on clone+rebaseEric Wong4-2/+139
We parse unhandled.log files for empty_dir statements and make a best effort attempt to recreate empty directories on fresh clones and rebase. This should cover the majority of cases where users work off a single branch or for projects where branches do not differ in empty directories. Since this cannot affect "normal" git commands like "checkout" or "reset", so users switching between branches in a single working directory should use the new "git svn mkdirs" command after switching branches. Signed-off-by: Eric Wong <normalperson@yhbt.net>
2009-11-15remote: fix use-after-free error detected by glibc in ref_remove_duplicatesJulian Phillips2-0/+13
In ref_remove_duplicates, when we encounter a duplicate and remove it from the list we need to make sure that the prev pointer stays pointing at the last entry and also skip over adding the just freed entry to the string_list. Previously fetch could crash with: *** glibc detected *** git: corrupted double-linked list: ... Also add a test to try and catch problems with duplicate removal in the future. Acked-by: Nicolas Pitre <nico@fluxnic.net> Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-15Makefile: Ensure rpm packages can be read by older rpm versionsTodd Zullinger1-1/+4
The kernel.org hosts where the packages are built are now using Fedora 11, which defaults to sha256 for file digests instead of md5. Older versions of rpm can not handle these packages. Tell rpmbuild to use md5 file digests for better compatibility. Signed-off-by: Todd Zullinger <tmz@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-15bash: add the merge option --ff-onlyBjörn Gustavsson1-1/+1
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-15gitweb: Make 'history' view (re)use git_log_generic()Jakub Narebski1-89/+57
Make git_history use git_log_generic, passing git_history_body as one of its paramaters. This required changes to git_log_generic, in particular passing more things as parameters. While refactoring common code of 'log', 'shortlog' and 'history' view, we did unify pagination, using always the form used by 'history' view, namely first * prev * next in place of HEAD * prev * next used by 'log' and 'shortlog' views. The 'history' view now supports commit limiting via 'hpb' parameter, similarly to 'shortlog' (and 'log') view. Performance of 'history' view got improved a bit, as it doesn't run git_get_hash_by_path for "current" version in a loop. Error detection and reporting for 'history' view changed a bit. Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-15gitweb: Refactor common parts of 'log' and 'shortlog' viewsJakub Narebski1-52/+20
Put the common parts of git_log and git_shortlog into git_log_generic subroutine: git_log and git_shortlog are now thin wrappers calling git_log_generic with appropriate arguments. The unification of code responsible for 'log' and 'shorlog' actions lead to the following changes in gitweb output * 'tree' link in page_nav now uses $hash parameter, as was the case for 'shortlog' but not for 'log' * 'log' view now respect $hash_parent limiting, like 'shortlog' did * 'log' view doesn't have special case for empty list anymore, and it always uses page_header linking to summary view, like 'shortlog' did. Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-15gitweb: Refactor 'log' action generation, adding git_log_body()Jakub Narebski1-33/+48
Put the main part of 'log' view generation into git_log_body, similarly how it is done for 'shortlog' and 'history' views (and also for 'tags' and 'heads' views). This is preparation for extracting common code between 'log', 'shortlog' and 'history' actions. Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-14git svn: add authorsfile test case for ~/.gitconfigEric Wong1-0/+23
The commit for: git svn: read global+system config for clone+init Initially lacked a test case because the author was unable to reproduce it under his test environment, this adds it. Signed-off-by: Eric Wong <normalperson@yhbt.net>
2009-11-14git svn: read global+system config for clone+initEric Wong1-3/+2
Since $GIT_DIR does not exist when initializing new repositories, we can follow back to the global and system config files for git. The logic for this was originally introduced when $GIT_DIR/config was the only config file git could read (back when "git config" was "git repo-config"), so the function is renamed to "read_git_config" instead of "read_repo_config". Signed-off-by: Eric Wong <normalperson@yhbt.net>
2009-11-14git svn: handle SVN merges from revisions past the tip of the branchToby Allsopp4-60/+371
When recording the revisions that it has merged, SVN sets the top revision to be the latest revision in the repository, which is not necessarily a revision on the branch that is being merged from. When it is not on the branch, git-svn fails to add the extra parent to represent the merge because it relies on finding the commit on the branch that corresponds to the top of the SVN merge range. In order to correctly handle this case, we look for the maximum revision less than or equal to the top of the SVN merge range that is actually on the branch being merged from. [ew: This includes the following (squashed) commit to prevent errors during bisect:] Author: Toby Allsopp <toby.allsopp@navman.co.nz> Date: Fri Nov 13 09:48:39 2009 +1300 git-svn: add (failing) test for SVN 1.5+ merge with intervening commit This test exposes a bug in git-svn's handling of SVN 1.5+ mergeinfo properties. The problematic case is when there is some commit on an unrelated branch after the last commit on the merged-from branch. When SVN records the mergeinfo property, it records the latest revision in the whole repository, which, in the problematic case, is not on the branch it is merging from. To trigger the git-svn bug, we modify t9151 to include two SVN merges, the second of which has an intervening commit. The SVN dump was generated using SVN 1.6.6 (on Debian squeeze amd64). Signed-off-by: Toby Allsopp <toby.allsopp@navman.co.nz> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-11-14git-add.txt: fix formatting of --patch sectionStephen Boyd1-4/+4
Extra paragraphs should be prefixed with a plus sign. Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-13give priority to progress messagesNicolas Pitre2-23/+23
In theory it is possible for sideband channel #2 to be delayed if pack data is quick to come up for sideband channel #1. And because data for channel #2 is read only 128 bytes at a time while pack data is read 8192 bytes at a time, it is possible for many pack blocks to be sent to the client before the progress message fifo is emptied, making the situation even worse. This would result in totally garbled progress display on the client's console as local progress gets mixed with partial remote progress lines. Let's prevent such situations by giving transmission priority to progress messages over pack data at all times. Signed-off-by: Nicolas Pitre <nico@fluxnic.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-13Provide a build time default-pager settingJunio C Hamano2-1/+16
Provide a DEFAULT_PAGER knob so packagers can set the fallback pager to something appropriate during the build. Examples: On (old) solaris systems, /usr/bin/less (typically the first less found) doesn't understand the default arguments (FXRS), which forces users to alter their environment (PATH, GIT_PAGER, LESS, etc) or have a local or global gitconfig before paging works as expected. On Debian systems, by policy packages must fall back to the 'pager' command, so that changing the target of the /usr/bin/pager symlink changes the default pager for all packages at once. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-13Provide a build time default-editor settingJonathan Nieder3-13/+47
Provide a DEFAULT_EDITOR knob to allow setting the fallback editor to use instead of vi (when VISUAL, EDITOR, and GIT_EDITOR are unset). The value can be set at build time according to a system’s policy. For example, on Debian systems, the default editor should be the 'editor' command. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-13am -i, git-svn: use "git var GIT_PAGER"Jonathan Nieder2-5/+6
Use the new "git var GIT_PAGER" command to ask what pager to use. Without this change, the core.pager configuration is ignored by these commands. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-13add -i, send-email, svn, p4, etc: use "git var GIT_EDITOR"Jonathan Nieder8-29/+16
Use the new "git var GIT_EDITOR" feature to decide what editor to use, instead of duplicating its logic elsewhere. This should make the behavior of commands in edge cases (e.g., editor names with spaces) a little more consistent. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-13Teach git var about GIT_PAGERJonathan Nieder4-3/+32
Expose the command found by setup_pager() for scripts to use. Scripts can use this to avoid repeating the logic to look for a proper pager in each command. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-13Teach git var about GIT_EDITORJonathan Nieder4-3/+36
Expose the command used by launch_editor() for scripts to use. This should allow one to avoid searching for a proper editor separately in each command. git_editor(void) uses the logic to decide which editor to use that used to live in launch_editor(). The function returns NULL if there is no suitable editor; the caller is expected to issue an error message when appropriate. launch_editor() uses git_editor() and gives the error message the same way as before when EDITOR is not set. "git var GIT_EDITOR" gives the editor name, or an error message when there is no appropriate one. "git var -l" gives GIT_EDITOR=name only if there is an appropriate editor. Originally-submitted-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-13Suppress warnings from "git var -l"Jonathan Nieder2-2/+2
For scripts using "git var -l" to read all logical variables at once, not all per-variable warnings will be relevant. So suppress them. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-13Do not use VISUAL editor on dumb terminalsJonathan Nieder4-14/+24
Refuse to use $VISUAL and fall back to $EDITOR if TERM is unset or set to "dumb". Traditionally, VISUAL is set to a screen editor and EDITOR to a line-based editor, which should be more useful in that situation. vim, for example, is happy to assume a terminal supports ANSI sequences even if TERM is dumb (e.g., when running from a text editor like Acme). git already refuses to fall back to vi on a dumb terminal if GIT_EDITOR, core.editor, VISUAL, and EDITOR are unset, but without this patch, that check is suppressed by VISUAL=vi. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-13Update packfile transfer protocol documentationScott Chacon3-41/+777
The current technical documentation for the packfile protocol is both sparse and incorrect. This documents the fetch-pack/upload-pack and send-pack/ receive-pack protocols much more fully. Add documentation from Shawn's upcoming http-protocol docs that is shared by the packfile protocol. protocol-common.txt describes ABNF notation amendments, refname rules and the packet line format. Add documentation on the various capabilities supported by the upload-pack and receive-pack protocols. protocol-capabilities.txt describes multi-ack, thin-pack, side-band[-64k], shallow, no-progress, include-tag, ofs-delta, delete-refs and report-status. Signed-off-by: Scott Chacon <schacon@gmail.com> Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-13filter-branch: nearest-ancestor rewriting outside subdir filterThomas Rast3-6/+43
Since a0e4639 (filter-branch: fix ref rewriting with --subdirectory-filter, 2008-08-12) git-filter-branch has done nearest-ancestor rewriting when using a --subdirectory-filter. However, that rewriting strategy is also a useful building block in other tasks. For example, if you want to split out a subset of files from your history, you would typically call git filter-branch -- <refs> -- <files> But this fails for all refs that do not point directly to a commit that affects <files>, because their referenced commit will not be rewritten and the ref remains untouched. The code was already there for the --subdirectory-filter case, so just introduce an option that enables it independently. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-13filter-branch: stop special-casing $filter_subdir argumentThomas Rast1-7/+15
Handling $filter_subdir in the usual way requires a separate case at every use, because the variable is empty when unused. Furthermore, --subdirectory-filter supplies its own '--', and if the user provided one himself, such as in git filter-branch --subdirectory-filter subdir -- --all -- subdir/file an extra '--' was used as path filter in the call to git-rev-list that determines the commits that shall be rewritten. To keep the argument handling sane, we filter $@ to contain only the non-revision arguments, and store all revisions in $ref_args. The $ref_args are easy to handle since only the SHA1s are needed; the actual branch names have already been stored in $tempdir/heads at this point. An extra separating -- is only required if the user did not provide any non-revision arguments, as the latter disambiguate the $filter_subdir following after them (or fail earlier because they are ambiguous themselves). Thanks to Johannes Sixt for suggesting this solution. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-11check-ref-format -h: it does not know the --print option yetJunio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-10git-describe.txt: formatting fixJunio C Hamano1-0/+1
A multi-line SYNOPSIS description must be marked as [verse] Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-10diff --no-index: make the usage string less scaryJonathan Nieder1-2/+2
Start the diff --no-index usage string with "usage:" instead of "fatal:". Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-10merge-{recursive,subtree}: use usagef() to print usageJonathan Nieder1-1/+1
Usage messages (for example, from "git merge-recursive -h") are friendlier when not preceded by "fatal". Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-10Introduce usagef() that takes a printf-style formatJonathan Nieder2-4/+14
Some new callers would want to use printf-like formatting, when issuing their usage messages. An option is to change usage() itself also be like printf(), which would make it similar to die() and warn(). But usage() is typically fixed, as opposed to die() and warn() that gives diagnostics depending on the situation. Indeed, the majority of strings given by existing callsites to usage() are fixed strings. If we were to make usage() take printf-style format, they all need to be changed to have "%s" as their first argument. So instead, introduce usagef() so that limited number of callers can use it. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-10Let 'git <command> -h' show usage without a git dirJonathan Nieder8-15/+36
There is no need for "git <command> -h" to depend on being inside a repository. Reported by Gerfried Fuchs through http://bugs.debian.org/462557 Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-10Show usage string for 'git http-push -h'Jonathan Nieder1-2/+4
http-push already knows how to dump usage if it is given no options, but it interprets '-h' as the URL to a remote repository: $ git http-push -h error: Cannot access URL -h/, return code 6 Dump usage instead. Humans wanting to pass the URL -h/ to curl for some reason can use 'git http-push -h/' explicitly. Scripts expecting to access an HTTP repository at URL '-h' will break, though. Also delay finding a git directory until after option parsing, so "http-push -h" can be used outside any git repository. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Acked-by: Tay Ray Chuan <rctay89@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-10format-patch: Add "--no-stat" as a synonym for "-p"Björn Gustavsson2-2/+4
"-p" means "generate patch" in 'git log' and 'git diff', so it's quite surprising that it means "suppress diffstat" in 'git format-patch'. Keep the "-p" option for backward compatibility, but add "--no-stat" as a more intuitive synonym. For backward compatibility with scripts, we must allow combinations of --stat and --no-stat. Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-10format-patch documentation: Fix formattingBjörn Gustavsson2-41/+41
Format git commands and options consistently using back quotes (i.e. a fixed font in the resulting HTML document). Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-10format-patch documentation: Remove diff options that are not usefulBjörn Gustavsson1-2/+12
To simplify reading the documentation for format-patch, remove the description of common diff options that are not useful for the purpose of the command (i.e. "Prepare patches for e-mail submission"). Specifically, this removes the description of the following options: --raw -z --color --no-color --color-words --diff-filter -S --pickaxe-all --pickaxe-regex -R --relative --exit-code --quiet Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-10format-patch: Always generate a patchBjörn Gustavsson3-10/+47
Jeff King recently reinstated -p to suppress the default diffstat (as -p used to work before 68daa64, about 14 months ago). However, -p is also needed in combination with certain options (e.g. --stat or --numstat) in order to produce any patch at all. The documentation does not mention this. Since the purpose of format-patch is to produce a patch that can be emailed, it does not make sense that certain combination of options will suppress the generation of the patch itself. Therefore: * Update 'git format-patch' to always generate a patch. * Since the --name-only, --name-status, and --check suppresses the generation of the patch, disallow those options, and remove the description of them in the documentation. * Remove the reference to -p in the description of -U. * Remove the descriptions of the options that are synonyms for -p plus another option (--patch-with-raw and --patch-with-stat). * While at it, slightly tweak the description of -p itself to say that it generates "plain patches", so that you can think of -p as "plain patch" as an mnemonic aid. Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-10Let 'git http-fetch -h' show usage outside any git repositoryJonathan Nieder1-6/+12
Delay search for a git directory until option parsing has finished. None of the functions used in option parsing look for or read any files other than stdin, so this is safe. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-10Show usage string for 'git stripspace -h'Jonathan Nieder1-1/+3
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-10Show usage string for 'git unpack-file -h'Jonathan Nieder1-1/+1
"unpack-file -h" could be asking to save the contents of a blob named "-h". Strictly speaking, such a pathological ref name is possible, but the user would have to had said something like "tags/-h" to name such a pathological ref already. When used in scripts, unpack-file is typically not passed a user-supplied tag name directly. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-10Show usage string for 'git show-index -h'Jonathan Nieder1-0/+5
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-10Show usage string for 'git rev-parse -h'Jonathan Nieder1-0/+10
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-10Show usage string for 'git merge-one-file -h'Jonathan Nieder1-0/+12
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-10Show usage string for 'git mailsplit -h'Jonathan Nieder1-0/+2
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-10Show usage string for 'git imap-send -h'Jonathan Nieder1-0/+5
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-10Show usage string for 'git get-tar-commit-id -h'Jonathan Nieder1-0/+6
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>