summaryrefslogtreecommitdiffstats
path: root/exec_cmd.c (unfollow)
Commit message (Collapse)AuthorFilesLines
2006-05-16apply --cached: apply a patch without using working tree.Junio C Hamano1-20/+52
A new flag "--cached" takes the cached data, applies the patch and stores the result in the index, without using the working tree. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-15builtin-grep: unparse more command line options.Junio C Hamano1-8/+57
The earlier one to use external grep missed some often used options. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-15pack-object: slightly more efficientNicolas Pitre2-7/+10
Avoid creating a delta index for objects with maximum depth since they are not going to be used as delta base anyway. This also reduce peak memory usage slightly as the current object's delta index is not useful until the next object in the loop is considered for deltification. This saves a bit more than 1% on CPU usage. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-15simple euristic for further free packing improvementsNicolas Pitre1-5/+2
Given that the early eviction of objects with maximum delta depth may exhibit bad packing on its own, why not considering a bias against deep base objects in try_delta() to mitigate that bad behavior. This patch adjust the MAX_size allowed for a delta based on the depth of the base object as well as enabling the early eviction of max depth objects from the object window. When used separately, those two things produce slightly better and much worse results respectively. But their combined effect is a surprising significant packing improvement. With this really simple patch the GIT repo gets nearly 15% smaller, and the Linux kernel repo about 5% smaller, with no significantly measurable CPU usage difference. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-15read-tree --reset -u fix.Linus Torvalds1-4/+12
The previous commit makes -u to mean "I do want to remove the local changes, just update it from the read tree" only for one-way merge. It makes sense to have it depend on the "--reset" flag instead. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-15send-email: quiet some warnings, reject invalid addressesEric Wong1-3/+12
I'm not sure why we never actually rejected invalid addresses in the first place. We just seemed to be using our email validity checkers to kill duplicates. Now we just drop invalid email addresses completely and warn the user about it. Since we support local sendmail, we'll also accept username-only addresses. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-15send-email: allow sendmail binary to be used instead of SMTPEric Wong1-20/+40
This should make local mailing possible for machines without a connection to an SMTP server. It'll default to using /usr/sbin/sendmail or /usr/lib/sendmail if no SMTP server is specified (the default). If it can't find either of those paths, it'll fall back to connecting to an SMTP server on localhost. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-15Strip useless "tags/" prefix from git-tag -l outputSean1-5/+3
2006-05-15apply --numstat: show new name, not old name.Junio C Hamano1-1/+1
Somehow --stat showed the new name but --numstat showed the old name for renamed/copied paths. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-15read-tree -u one-way merge fix to check out locally modified paths.Junio C Hamano1-0/+3
The "-u" flag means "update the working tree files", but to other types of merges, it also implies "I want to keep my local changes" -- because they prevent local changes from getting lost by using verify_uptodate. The one-way merge is different from other merges in that its purpose is opposite of doing something else while keeping unrelated local changes. The point of one-way merge is to nuke local changes. So while it feels somewhat wrong that this actively loses local changes, it is the right thing to do. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-15Install git-send-email by defaultEric Wong2-7/+4
After 567ffeb7722eefab3991cb894c96548b92b57cc2 and 4bc87a28be020a6bf7387161c65ea3d8e4a0228b, git-send-email no longer requires any non-standard Perl modules, so there's no reason to special-case it. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-15send-email: address expansion for common mailersEric Wong1-0/+48
mutt, gnus, pine, mailrc formats should be supported. Testing and feedback for correctness and completeness of all formats and support for additional formats would be good. Nested expansions are also supported. More than one alias file to be used. All alias file formats must still of be the same type, though. Two git repo-config keys are required for this (as suggested by Ryan Anderson): sendemail.aliasesfile = <filename of aliases file> sendemail.aliasfiletype = (mutt|gnus|pine|mailrc) Signed-off-by: Eric Wong <normalperson@yhbt.net> Acked-by: Ryan Anderson <ryan@michonline.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-15builtin-grep: use external grep when we can take advantage of itLinus Torvalds1-0/+79
It's not perfect, but it gets the "git grep some-random-string" down to the good old half-a-second range for the kernel. It should convert more of the argument flags for "grep", that should be trivial to expand (I did a few just as an example). It should also bother to try to return the right "hit" value (which it doesn't, right now - the code is kind of there, but I didn't actually bother to do it _right_). Also, right now it _just_ limits by number of arguments, but it should also strictly speaking limit by total argument size (ie add up the length of the filenames, and do the "exec_grep()" flush call if it's bigger than some random value like 32kB). But I think that it's _conceptually_ doing all the right things, and it seems to work. So maybe somebody else can do some of the final polish. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-15diffstat rename squashing fix.Junio C Hamano1-2/+7
When renaming leading/a/filename to leading/b/filename (and "filename" is sufficiently long), we tried to squash the rename to "leading/{a => b}/filename". However, when "/a" or "/b" part is empty, we underflowed and tried to print a substring of length -1. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-15Simplify "git reset --hard"Linus Torvalds1-46/+4
Now that the one-way merge strategy does the right thing wrt files that do not exist in the result, just remove all the random crud we did in "git reset" to do this all by hand. Instead, just pass in "-u" to git-read-tree when we do a hard reset, and depend on git-read-tree to update the working tree appropriately. This basically means that git reset turns into # Always update the HEAD ref git update-ref HEAD "$rev" case "--soft" # do nothing to index/working tree case "--hard" # read index _and_ update working tree git-read-tree --reset -u "$rev" case "--mixed" # update just index, report on working tree differences git-read-tree --reset "$rev" git-update-index --refresh which is what it was always semantically doing, it just did it in a rather strange way because it was written to not expect git-read-tree to do anything to the working tree. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-15Allow one-way tree merge to remove old filesLinus Torvalds1-1/+1
For some random reason (probably just because nobody noticed), the one-way merge strategy didn't mark deleted files as deleted, so if you used git-read-tree -m -u <newtree> it would update the files that got changed in the index, but it would not delete the files that got deleted. This should fix it, and I can't imagine that anybody depends on the old strange "update only existing files" behaviour. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-15Convert some "apply --summary" users to "diff --summary".Sean3-4/+3
Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-15Add "--summary" option to git diff.Sean3-2/+93
Remove the need to pipe git diff through git apply to get the extended headers summary. Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-15Make git rebase interactive help match documentation.Sean3-13/+30
Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-15Ensure author & committer before asking for commit message.Sean1-0/+2
It's better to find out you need to fix your author and committer information before you enter a long commit message. Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-15git diff: support "-U" and "--unified" options properlyLinus Torvalds3-1/+53
We used to parse "-U" and "--unified" as part of the GIT_DIFF_OPTS environment variable, but strangely enough we would _not_ parse them as part of the normal diff command line (where we only accepted "-u"). This adds parsing of -U and --unified, both with an optional numeric argument. So now you can just say git diff --unified=5 to get a unified diff with a five-line context, instead of having to do something silly like GIT_DIFF_OPTS="--unified=5" git diff -u (that silly format does continue to still work, of course). Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-15Add "--branches", "--tags" and "--remotes" options to git-rev-parse.Sean5-7/+48
"git branch" uses "rev-parse --all" and becomes much too slow when there are many tags (it scans all refs). Use the new "--branches" option of rev-parse to speed things up. Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-15include header to define uint32_t, necessary on Mac OS XBen Clifford2-0/+2
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-13git config syntax updatesLinus Torvalds3-20/+90
This updates the hierarchical section name syntax to [section<space>+"<randomstring>"] where the only rule for "randomstring" is that it can't contain a newline, and if you really want to insert a double-quote, you do it with \". It turns that into the section name "secion.randomstring". The "section" part is still case insensitive, but the "randomstring" part is case sensitive. So you could use this for things like [email "torvalds@osdl.org"] name = Linus Torvalds if you wanted to do the "email->name" conversion as part of the config file format (I'm not claiming that is sensible, I'm just giving it as an insane example). That would show up as the association email.torvalds@osdl.org.name -> Linus Torvalds which is easy to parse (the "." in the email _looks_ ambiguous, but it isn't: you know that there will always be a single key-name, so you find the key name with "strrchr(name, '.')" and things are entirely unambiguous). Repo-config is updated to be able to parse the new format, and also write things out in the new format. [jc: rolled two patches from Linus and one fix-up from Sean into one, with additional adjustments for t/t1300 test to check the case insensitiveness of section base and variable and case sensitiveness of the extended section part. Then stripped some part off to make the result applicable to the stale 1.3.X series that does not have recent enhancements. ] Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-13Another config file parsing fix.sean1-1/+3
If the variable we need to store should go into a section that currently only has a single variable (not matching the one we're trying to insert), we will already be into the next section before we notice we've bypassed the correct location to insert the variable. To handle this case we store the current location as soon as we find a variable matching the section of our new variable. This breakage was brought up by Linus. Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-13checkout: use --aggressive when running a 3-way merge (-m).Junio C Hamano1-1/+1
After doing an in-index 3-way merge, we always do the stock "merge-index merge-one-file" without doing anything fancy; use of --aggressive helps performance quite a bit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-13Fix git-pack-objects for 64-bit platformsDennis Stosberg2-2/+2
The offset of an object in the pack is recorded as a 4-byte integer in the index file. When reading the offset from the mmap'ed index in prepare_pack_revindex(), the address is dereferenced as a long*. This works fine as long as the long type is four bytes wide. On NetBSD/sparc64, however, a long is 8 bytes wide and so dereferencing the offset produces garbage. [jc: taking suggestion by Linus to use uint32_t] Signed-off-by: Dennis Stosberg <dennis@stosberg.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-10fix diff-delta bad memory accessNicolas Pitre1-5/+0
It cannot be assumed that the given buffer will never be moved when shrinking the allocated memory size with realloc(). So let's ignore that optimization for now. This patch makes Electric Fence happy on Linux. Signed-off-by: Nicolas Pitre <nico@cam.org> Acked-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-10checkout: use --aggressive when running a 3-way merge (-m).Junio C Hamano1-1/+1
After doing an in-index 3-way merge, we always do the stock "merge-index merge-one-file" without doing anything fancy; use of --aggressive helps performance quite a bit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-10revert/cherry-pick: use aggressive merge.Linus Torvalds1-1/+1
After doing an in-index 3-way merge, we always do the stock "merge-index merge-one-file" without doing anything fancy; use of --aggressive helps performance quite a bit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-10builtin-grep: -F (--fixed-strings)Junio C Hamano2-5/+33
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-10builtin-grep: -w fixJunio C Hamano1-3/+3
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-10builtin-grep: typofixJunio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-09read-cache.c: use xcalloc() not calloc()Yakov Lerner1-1/+1
Elsewhere we use xcalloc(); we should consistently do so. Signed-off-by: Yakov Lerner <iler.ml@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-09apply: fix infinite loop with multiple patches with --indexEric Wong1-9/+9
When multiple patches are passed to git-apply, it will attempt to open multiple file descriptors to an index, which means multiple entries will be in the circular cache_file_list. This change makes git-apply only open the index once and write the index at exit. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-09builtin-grep: tighten argument parsing.Junio C Hamano1-26/+50
I mistyped git grep next -e '"^@"' '*.c' and got many hits that contain "next" without complaint. Obviously what I meant to say was: git grep -e '"^@"' next -- '*.c' This tightens the argument parsing rule a bit: - All "grep" parameters should come first; - If there is no -e nor -f to specify pattern, the first non option string is the parameter; - After that, zero or more revs can follow. - An optional '--' can be present, and is skipped. - All the rest are pathspecs. If '--' was not there, they must be paths that exist in the working tree. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-09Teach git-clean optional <paths>... parameters.Junio C Hamano2-5/+17
When optional paths arguments are given, git-clean passes them to underlying git-ls-files; with this, you can say: git clean 'temp-*' to clean only the garbage files whose names begin with 'temp-'. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Pavel Roskin <proski@gnu.org>
2006-05-09Separate object name errors from usage errorsDmitry V. Levin13-25/+36
Separate object name errors from usage errors. Signed-off-by: Dmitry V. Levin <ldv@altlinux.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-09get_sha1() - fix infinite loop on nonexistent stage.Junio C Hamano1-0/+1
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-08Documentation: {caret} fixes (git-rev-list.txt)Junio C Hamano1-3/+4
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-08builtin-grep: documentationJunio C Hamano1-23/+62
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-08Teach -f <file> option to builtin-grep.Junio C Hamano1-19/+42
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-08improve base85 generated assembly codeNicolas Pitre1-29/+35
This code is arguably pretty hot, if you use binary patches of course. This patch helps gcc generate both smaller and faster code especially in the error free path. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-08Fix "git diff --stat" with long filenamesLinus Torvalds1-1/+1
When we cut off the front of a filename to make it fit on the line, we add a "..." in front. However, the way the "git diff" code was written, we will never reset the prefix back to the empty string, so every single filename afterwards will have the "..." prefix, whether appropriate or not. You can see this with "git diff v2.6.16.." on the current kernel tree, since there are filenames with long names that changed there: [ snip snip ] Documentation/filesystems/vfs.txt | 229 .../firmware_class/firmware_sample_driver.c | 3 .../firmware_sample_firmware_class.c | 1 ...Documentation/fujitsu/frv/kernel-ABI.txt | 192 ...Documentation/hwmon/w83627hf | 4 [ snip snip ] notice how the two Documentation/firmware** filenames caused the "..." to be added, but then the later filenames don't want it, and it also screws up the alignment of the line numbering afterwards. Trivially fixed by moving the declaration (and initial setting) of the "prefix" variable into the for-loop where it is used. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-08Fix repo-config set-multivar error return path.Junio C Hamano1-12/+6
This hopefully fixes the problem an earlier commit 5d8ee9ceb attemted to fix. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-08clone: don't clone the info/alternates fileMartin Waitz1-5/+1
Now that the cloned alternates file is parsed, too we don't need to copy it into our new repository, we just reference it. Signed-off-by: Martin Waitz <tali@admingilde.org> Signed-off-by: Junio C Hamano <junkio@cox.net>