summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2007-09-14Merge branch 'jc/grep-c'Libravatar Junio C Hamano10-22/+116
* jc/grep-c: Split grep arguments in a way that does not requires to add /dev/null. Documentation/git-config.txt: AsciiDoc tweak to avoid leading dot Add test to check recent fix to "git add -u" Documentation/git-archive.txt: a couple of clarifications. Fix the rename detection limit checking diff --no-index: do not forget to run diff_setup_done()
2007-09-14Split grep arguments in a way that does not requires to add /dev/null.Libravatar Junio C Hamano2-14/+80
In order to (almost) always show the name of the file without relying on "-H" option of GNU grep, we used to add /dev/null to the argument list unless we are doing -l or -L. This caused "/dev/null:0" to show up when -c is given in the output. It is not enough to add -c to the set of options we do not pass /dev/null for. When we have too many files, we invoke grep multiple times and we need to avoid giving a widow filename to the last invocation -- otherwise we will not see the name. This keeps two filenames when the argv[] buffer is about to overflow and we have not finished iterating over the index, so that the last round will always have at least two paths to work with (and not require /dev/null). An obvious and the only exception is when there is only 1 file that is given to the underlying grep, and in that case we avoid passing /dev/null and let the external "grep -c" report only the number of matches. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-14Documentation/git-config.txt: AsciiDoc tweak to avoid leading dotLibravatar Junio C Hamano1-1/+1
Bram Schoenmakers noticed that git-config document was formatted incorrectly. Depending on the version of AsciiDoc and docbook toolchain, it is sometimes taken as a numbered example by AsciiDoc, some other times passed intact to roff format to confuse "man". Since we refer to the repository metadata directory as $GIT_DIR elsewhere, work it around by using that symbolic name. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-14Add test to check recent fix to "git add -u"Libravatar Benoit Sigoure2-2/+11
An earlier commit fixed type-change case in "git add -u". This adds a test to make sure we do not introduce regression. At the same time, it fixes a stupid typo in the error message. Signed-off-by: Benoit Sigoure <tsuna@lrde.epita.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-14Documentation/git-archive.txt: a couple of clarifications.Libravatar Jari Aalto1-2/+3
The description of the option gave impression that there were several formats available by using three dots. There are no other formats than tar and gzip currently supported. Clarify that the archive goes to the standard output. Signed-off-by: Jari Aalto <jari.aalto@cante.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-14Fix the rename detection limit checkingLibravatar Linus Torvalds3-3/+19
This adds more proper rename detection limits. Instead of just checking the limit against the number of potential rename destinations, we verify that the rename matrix (which is what really matters) doesn't grow ridiculously large, and we also make sure that we don't overflow when doing the matrix size calculation. This also changes the default limits from unlimited, to a rename matrix that is limited to 100 entries on a side. You can raise it with the config entry, or by using the "-l<n>" command line flag, but at least the default is now a sane number that avoids spending lots of time (and memory) in situations that likely don't merit it. The choice of default value is of course very debatable. Limiting the rename matrix to a 100x100 size will mean that even if you have just one obvious rename, but you also create (or delete) 10,000 files, the rename matrix will be so big that we disable the heuristics. Sounds reasonable to me, but let's see if people hit this (and, perhaps more importantly, actually *care*) in real life. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-14diff --no-index: do not forget to run diff_setup_done()Libravatar Junio C Hamano1-0/+2
Code inspection by Linus found this. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-14Merge branch 'maint'Libravatar Junio C Hamano5-8/+37
* maint: git-format-patch --in-reply-to: accept <message@id> with angle brackets git-add -u: do not barf on type changes Remove duplicate note about removing commits with git-filter-branch git-clone: improve error message if curl program is missing or not executable hooks--update: Explicitly check for all zeros for a deleted ref.
2007-09-14git-format-patch --in-reply-to: accept <message@id> with angle bracketsLibravatar Junio C Hamano1-1/+30
This will allow RFC-literate users to say: format-patch --in-reply-to='<message.id@site.name>' without forcing them to strip the surrounding angle brackets like this: format-patch --in-reply-to='message.id@site.name' We accept both forms, and the latter gets necessary < and > around it as before. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-14git-add -u: do not barf on type changesLibravatar Junio C Hamano1-0/+1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-13Remove duplicate note about removing commits with git-filter-branchLibravatar Ulrik Sverdrup1-5/+0
A duplicate of an already existing section in the documentation of git-filter-branch was added in commit f95eef15f2f8a336b9a42749f5458c841a5a5d63. This patch removes that redundant section. Signed-off-by: Ulrik Sverdrup <ulrik.sverdrup@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-13git-clone: improve error message if curl program is missing or not executableLibravatar Gerrit Pape1-1/+5
If the curl program is not available (or not executable), and git clone is started to clone a repository through http, this is the output Initialized empty Git repository in /tmp/puppet/.git/ /usr/bin/git-clone: line 37: curl: command not found Cannot get remote repository information. Perhaps git-update-server-info needs to be run there? This patch improves the error message by checking the return code when running curl to exit immediately if it's 126 or 127; the error output now is Initialized empty Git repository in /tmp/puppet/.git/ /usr/bin/git-clone: line 37: curl: command not found Adrian Bridgett noticed this and reported through http://bugs.debian.org/440976 Signed-off-by: Gerrit Pape <pape@smarden.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-13git.el: Allow the add and remove commands to be applied to ignored files.Libravatar Alexandre Julliard1-2/+2
Signed-off-by: Alexandre Julliard <julliard@winehq.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-13git.el: Allow selecting whether to display uptodate/unknown/ignored files.Libravatar Alexandre Julliard1-15/+77
The default behavior for each state can be customized, and it can also be toggled directly from the status buffer. Signed-off-by: Alexandre Julliard <julliard@winehq.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-13git.el: Keep the status buffer sorted by filename.Libravatar Alexandre Julliard1-38/+65
This makes insertions and updates much more efficient. Signed-off-by: Alexandre Julliard <julliard@winehq.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-13hooks--update: Explicitly check for all zeros for a deleted ref.Libravatar Alexandre Julliard1-1/+1
The previous check caused the hook to reject as unannotated any tag whose SHA1 starts with a zero. Signed-off-by: Alexandre Julliard <julliard@winehq.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-12Merge branch 'maint'Libravatar Junio C Hamano4-8/+17
* maint: stash: end index commit log with a newline git-commit: Disallow amend if it is going to produce an empty non-merge commit git-send-email.perl: Add angle brackets to In-Reply-To if necessary Fix a test failure (t9500-*.sh) on cygwin
2007-09-12Merge branch 'sp/maint-no-thin' into maintLibravatar Junio C Hamano1-1/+1
* sp/maint-no-thin: Make --no-thin the default in git-push to save server resources
2007-09-12Define NO_MEMMEM of FreeBSD as it lacks the functionLibravatar Robert Boone1-0/+1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-12stash: end index commit log with a newlineLibravatar Jean-Luc Herren1-1/+1
There was no newline at the end of the index commit message, putting the shell prompt at its end after a 'git cat-file commit $id'. This is similar to what was fixed in 843103d69388a5c74ed99753e1c162a66835b04d. Signed-off-by: Jean-Luc Herren <jlh@gmx.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-12git-commit: Disallow amend if it is going to produce an empty non-merge commitLibravatar Dmitry V. Levin1-1/+1
Right now one can amend the last non-merge commit using a dirty index and in the process maybe cause the last commit to have the same tree as its parent. In such a case one would want to discard the last commit instead of amending it. This reverts commit 8588452ceb78b1da17652ba03f9942ef740e07ea. Signed-off-by: Dmitry V. Levin <ldv@altlinux.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-12git-send-email.perl: Add angle brackets to In-Reply-To if necessaryLibravatar David Kastrup1-1/+2
Although message-id by defintion should have surrounding angle brackets, there is no point forcing people to type them in. Signed-off-by: David Kastrup <dak@gnu.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-11Fix a test failure (t9500-*.sh) on cygwinLibravatar Ramsay Jones1-5/+13
On filesystems where it is appropriate to set core.filemode to false, test 29 ("commitdiff(0): mode change") fails when git-commit does not notice a file (execute) permission change. A fix requires noting the new file execute permission in the index with a "git update-index --chmod=+x", prior to the commit. Add a function (note_chmod) which implements this idea, and insert a call in each test that modifies the x permission. Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-10Merge branch 'rs/archive'Libravatar Junio C Hamano13-23/+197
* rs/archive: archive - leakfix for format_subst() Define NO_MEMMEM on Darwin as it lacks the function archive: rename attribute specfile to export-subst archive: specfile syntax change: "$Format:%PLCHLDR$" instead of just "%PLCHLDR" (take 2) add memmem() Remove unused function convert_sha1_file() archive: specfile support (--pretty=format: in archive files) Export format_commit_message()
2007-09-10archive - leakfix for format_subst()Libravatar Junio C Hamano1-0/+1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-10Merge branch 'sp/maint-no-thin'Libravatar Junio C Hamano4-11/+24
* sp/maint-no-thin: Make --no-thin the default in git-push to save server resources fix doc for --compression argument to pack-objects git-tag -s must fail if gpg cannot sign the tag.
2007-09-10Make --no-thin the default in git-push to save server resourcesLibravatar Shawn O. Pearce1-1/+1
1) pushes happen less often than fetches, so the bandwidth saving is much less visible in that case overall. 2) thin packs have to be complemented with missing delta bases to be valid, so many received thin packs will take more disk space. 3) the bother of repacking should be distributed amongst "clients" i.e. fetchers and pushers as much as possible, and not the server being fetched or pushed, to keep disk and CPU usage low on the server. This is why a fetch should get thin packs but a push should not. Both Nico and I have been assuming that --no-thin was the default behavior of git-push ever since Nico introduced --fix-thin into the index-pack process, which allowed fetch and receive-pack to avoid exploding packfiles received during transfer. This patch finally makes it so. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-09fix doc for --compression argument to pack-objectsLibravatar Nicolas Pitre1-6/+2
Remove obsolete details (core.legacyheaders is always true now). Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-09git-tag -s must fail if gpg cannot sign the tag.Libravatar Carlos Rica2-4/+21
Most of this patch code and message was written by Shawn O. Pearce. I made some tests to know what the problem was, and then I changed the code related with the SIGPIPE signal. If the user has misconfigured `user.signingkey` in their .git/config or just doesn't have any secret keys on their keyring and they ask for a signed tag with `git tag -s` we better make sure the resulting tag was actually signed by gpg. Prior versions of builtin git-tag allowed this failure to slip by without error as they were not checking the return value of the finish_command() so they did not notice when gpg exited with an error exit status. They also did not fail if gpg produced an empty output or if read_in_full received an error from the read system call while trying to read the pipe back from gpg. Finally, we did not actually honor any return value from the do_sign function as it returns ssize_t but was being stored into an unsigned long. This caused the compiler to optimize out the die condition, allowing git-tag to continue along and create the tag object. However, when gpg gets a wrong username, it exits before any read was done and then the writing process receives SIGPIPE and program is terminated. By ignoring this signal, anyway, the function write_or_die gets EPIPE from write_in_full and exits returning 0 to the system without a message. Here we better call to write_in_full directly so we can fail printing a message and return safely to the caller. With these issues fixed `git-tag -s` will now fail to create the tag and will report a non-zero exit status to its caller, thereby allowing automated helper scripts to detect (and recover from) failure if gpg is not working properly. Proposed-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Carlos Rica <jasampler@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-09Merge branch 'maint'Libravatar Junio C Hamano6-16/+40
* maint: git-svn: understand grafts when doing dcommit git-diff: don't squelch the new SHA1 in submodule diffs git-svn: fix "Malformed network data" with svn:// servers (cvs|svn)import: Ask git-tag to overwrite old tags. Documentation / grammer nit
2007-09-09git-svn: understand grafts when doing dcommitLibravatar Eric Wong1-8/+3
Use the rev-list --parents functionality to read the parents of the commit. cat-file only shows the raw object with the original parents and doesn't take into account grafts; so we'll rely on rev-list machinery for the smarts here. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-09git-diff: don't squelch the new SHA1 in submodule diffsLibravatar Sven Verdoolaege2-4/+21
The code to squelch empty diffs introduced by commit fb13227e089f22dc31a3b1624559153821056848 would inadvertently populate filespec "two" of a submodule change using the uninitialized (null) SHA1, thereby replacing the submodule SHA1 by 0{40} in the output. This change teaches diffcore_skip_stat_unmatch to handle submodule changes correctly. Signed-off-by: Sven Verdoolaege <skimo@kotnet.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-09Define NO_MEMMEM on Darwin as it lacks the functionLibravatar Shawn O. Pearce1-0/+1
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-07git-svn: fix "Malformed network data" with svn:// serversLibravatar Eric Wong1-1/+13
We have a workaround for the reparent function not working correctly on the SVN native protocol servers. This workaround opens a new connection (SVN::Ra object) to the new URL/directory. Since libsvn appears limited to only supporting one connection at a time, this workaround invalidates the Git::SVN::Ra object that is $self inside gs_fetch_loop_common(). So we need to restart that connection once all the fetching is done for each loop iteration to be able to run get_log() successfully. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-07(cvs|svn)import: Ask git-tag to overwrite old tags.Libravatar Michael Smith2-2/+2
If the tag was moved in CVS or SVN history, it will be moved in the imported history as well. Tag history is not tracked. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-07git-rebase: fix -C optionLibravatar J. Bruce Fields1-1/+0
The extra shift here causes failure to parse any commandline including the -C option. Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-07git-rebase: support --whitespace=<option>Libravatar J. Bruce Fields2-3/+11
Pass --whitespace=<option> to git-apply. Since git-apply and git-am expect this, I'm always surprised when I try to give it to git-rebase and it doesn't work. Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-07Documentation / grammer nitLibravatar Mike Ralphson1-1/+1
If we're counting, a smaller number is 'fewer' not 'less' Signed-off-by: Mike Ralphson <mike@abacus.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-06archive: rename attribute specfile to export-substLibravatar René Scharfe3-19/+19
As suggested by Junio and Johannes, change the name of the former attribute specfile to export-subst to indicate its function rather than purpose and to make clear that it is not applied to working tree files. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-06archive: specfile syntax change: "$Format:%PLCHLDR$" instead of just ↵Libravatar René Scharfe3-8/+53
"%PLCHLDR" (take 2) As suggested by Johannes, --pretty=format: placeholders in specfiles need to be wrapped in $Format:...$ now. This syntax change restricts the expansion of placeholders and makes it easier to use with files that contain non-placeholder percent signs. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-06add memmem()Libravatar René Scharfe3-0/+46
memmem() is a nice GNU extension for searching a length limited string in another one. This compat version is based on the version found in glibc 2.2 (GPL 2); I only removed the optimization of checking the first char by hand, and generally tried to keep the code simple. We can add it back if memcmp shows up high in a profile, but for now I prefer to keep it (almost trivially) simple. Since I don't really know which platforms beside those with a glibc have their own memmem(), I used a heuristic: if NO_STRCASESTR is set, then NO_MEMMEM is set, too. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-06Merge branch 'master' of git://repo.or.cz/git/git-p4Libravatar Junio C Hamano1-130/+212
* 'master' of git://repo.or.cz/git/git-p4: git-p4: Added support for automatically importing newly appearing perforce branches. git-p4: Cleanup; moved the (duplicated) code for turning a branch into a git ref (for example foo -> refs/remotes/p4/<project>/foo) into a separate method. git-p4: Cleanup; moved the code for the initial #head or revision import into a separate function, out of P4Sync.run. git-p4: Cleanup; Turn self.revision into a function local variable (it's not used anywhere outside the function). git-p4: Cleanup; moved the code to import a list of p4 changes using fast-import into a separate member function of P4Sync. git-p4: Cleanup; moved the code for getting a sorted list of p4 changes for a list of given depot paths into a standalone method. git-p4: After submission to p4 always synchronize from p4 again (into refs/remotes). Whether to rebase HEAD or not is still left as question to the end-user. git-p4: Always call 'p4 sync ...' before submitting to Perforce.
2007-09-05Merge branch 'maint'Libravatar Junio C Hamano6-4/+73
* maint: Include a git-push example for creating a remote branch Cleanup unnecessary file modifications in t1400-update-ref Makefile: Add cache-tree.h to the headers list Don't allow contrib/workdir/git-new-workdir to trash existing dirs git-apply: do not read past the end of buffer
2007-09-05Include a git-push example for creating a remote branchLibravatar Shawn O. Pearce1-0/+6
Many users get confused when `git push origin master:foo` works when foo already exists on the remote repository but are confused when foo doesn't exist as a branch and this form does not create the branch foo. This new example highlights the trick of including refs/heads/ in front of the desired branch name to create a branch. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-05Cleanup unnecessary file modifications in t1400-update-refLibravatar Shawn O. Pearce1-2/+0
Kristian Høgsberg pointed out that the two file modifications we were doing during the 'creating initial files' step are not even used within the test suite. This was actually confusing as we do not even need these changes for the tests to pass. All that really matters here is the specific commit dates are used so that these appear in the branch's reflog, and that the dates are different so that the branch will update when asked and the reflog entry is also updated. There is no need for the file modification. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-05Makefile: Add cache-tree.h to the headers listLibravatar Dmitry V. Levin1-1/+1
The dependency was missing. Signed-off-by: Dmitry V. Levin <ldv@altlinux.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-05Don't allow contrib/workdir/git-new-workdir to trash existing dirsLibravatar Shawn O. Pearce1-0/+6
Recently I found that doing a sequence like the following: git-new-workdir a b ... git-new-workdir a b by accident will cause a (and now also b) to have an infinite cycle in its refs directory. This is caused by git-new-workdir trying to create the "refs" symlink over again, only during the second time it is being created within a's refs directory and is now also pointing back at a's refs. This causes confusion in git as suddenly branches are named things like "refs/refs/refs/refs/refs/refs/refs/heads/foo" instead of the more commonly accepted "refs/heads/foo". Plenty of commands start to see ambiguous ref names and others just take ages to compute. git-clone has the same safety check, so git-new-workdir should behave just like it. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-05git-apply: do not read past the end of bufferLibravatar Junio C Hamano2-1/+60
When the preimage we are patching is shorter than what the patch text expects, we tried to match the buffer contents at the "original" line with the fragment in full, without checking we have enough data to match in the preimage. This caused the size of a later memmove() to wrap around and attempt to scribble almost the entire address space. Not good. The code that follows the part this patch touches tries to match the fragment with line offsets. Curiously, that code does not have the problem --- it guards against reading past the end of the preimage. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-05Merge branch 'ds/sendmail'Libravatar Junio C Hamano2-27/+109
* ds/sendmail: send-email: Add support for SSL and SMTP-AUTH
2007-09-05Function for updating refs.Libravatar Carlos Rica5-29/+46
A function intended to be called from builtins updating refs by locking them before write, specially those that came from scripts using "git update-ref". [jc: with minor fixups] Signed-off-by: Carlos Rica <jasampler@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>