summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2006-04-24Merge branch 'fix'Libravatar Junio C Hamano5-17/+212
* fix: Document the configuration file Document git-var -l listing also configuration variables rev-parse: better error message for ambiguous arguments
2006-04-24Document the configuration fileLibravatar Petr Baudis3-14/+198
This patch adds a Documentation/config.txt file included by git-repo-config and currently aggregating hopefully all the available git plumbing / core porcelain configuration variables, as well as briefly describing the format. It also updates an outdated bit of the example in git-repo-config(1). Signed-off-by: Petr Baudis <pasky@suse.cz>
2006-04-24Document git-var -l listing also configuration variablesLibravatar Petr Baudis1-1/+4
Signed-off-by: Petr Baudis <pasky@suse.cz>
2006-04-24rev-parse: better error message for ambiguous argumentsLibravatar Paul Mackerras1-2/+10
Currently, if git-rev-parse encounters an argument that is neither a recognizable revision name nor the name of an existing file or directory, and it hasn't encountered a "--" argument, it prints an error message saying "No such file or directory". This can be confusing for users, including users of programs such as gitk that use git-rev-parse, who may then think that they can't ask about the history of files that no longer exist. This makes it print a better error message, one that points out the ambiguity and tells the user what to do to fix it. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-24Merge branch 'ar/chmod-series'Libravatar Junio C Hamano1-7/+16
* ar/chmod-series: make update-index --chmod work with multiple files and --stdin
2006-04-24Merge branch 'sh/daemon'Libravatar Junio C Hamano1-1/+1
* sh/daemon: socksetup: don't return on set_reuse_addr() error
2006-04-24Merge branch 'jc/cc-stat'Libravatar Junio C Hamano1-1/+2
* jc/cc-stat: Fix "git show --stat"
2006-04-24Merge branch 'jc/unresolve'Libravatar Junio C Hamano1-0/+127
* jc/unresolve: git-update-index --unresolve Add git-unresolve <paths>...
2006-04-24Merge branch 'jc/color'Libravatar Junio C Hamano2-0/+198
* jc/color: Add colordiff for git to contrib/colordiff.
2006-04-24Merge git://git.kernel.org/pub/scm/gitk/gitkLibravatar Junio C Hamano1-18/+2
* git://git.kernel.org/pub/scm/gitk/gitk: gitk: Let git-rev-list do the argument list parsing
2006-04-23gitk: Let git-rev-list do the argument list parsingLibravatar Paul Mackerras1-18/+2
This is a fix for a problem reported by Jim Radford where an argument list somewhere overflows on repositories with lots of tags. In fact it's now unnecessary to use git-rev-parse since git-rev-list can take all the arguments that git-rev-parse can. This is inspired by but not the same as the solutions suggested by Jim Radford and Linus Torvalds. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-23make update-index --chmod work with multiple files and --stdinLibravatar Alex Riesen1-7/+16
The patch makes "--chmod=-x" and "--chmod=+x" act like "--add" and "--remove" to affect the behaviour of the command for the rest of the path parameters, not just the following one. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-21Fix "git show --stat"Libravatar Junio C Hamano1-1/+2
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-21Add colordiff for git to contrib/colordiff.Libravatar Junio C Hamano2-0/+198
I hacked it up to teach it the git extended diff headers, made it not to read the whole patch in the array. Also, the original program, when arguments are given, ran "diff" with the given arguments and showed the output from it. Of course, I changed it to run "git diff" ;-). Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-21Merge branch 'jc/diff'Libravatar Junio C Hamano1-9/+68
* jc/diff: diff --stat: do not drop rename information.
2006-04-21Makefile: dependency for builtin-help.oLibravatar Junio C Hamano1-0/+2
builtin-help.c wants to include common-cmds.h which is a generated file. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-21Split up builtin commands into separate files from git.cLibravatar Linus Torvalds5-305/+342
Right now it split it into "builtin-log.c" for log-related commands ("log", "show" and "whatchanged"), and "builtin-help.c" for the informational commands (usage printing and "help" and "version"). This just makes things easier to read, I find. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-21Merge branch 'fix'Libravatar Junio C Hamano1-0/+2
* fix: git-log produces no output
2006-04-21git-log produces no outputLibravatar Linus Torvalds1-0/+2
When $PAGER is set to 'less -i', we used to fail because we assumed the $PAGER is a command and simply exec'ed it. Try exec first, and then run it through shell if it fails. This allows even funkier PAGERs like these ;-): PAGER='sed -e "s/^/`date`: /" | more' PAGER='contrib/colordiff.perl | less -RS' Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-21Merge branch 'fix'Libravatar Junio C Hamano3-8/+12
* fix: fix pack-object buffer size mailinfo: decode underscore used in "Q" encoding properly. Reintroduce svn pools to solve the memory leak. pack-objects: do not stop at object that is "too small"
2006-04-21fix pack-object buffer sizeLibravatar Nicolas Pitre1-1/+1
The input line has 40 _chars_ of sha1 and no 20 _bytes_. It should also account for the space before the pathname, and the terminating \n and \0. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-21mailinfo: decode underscore used in "Q" encoding properly.Libravatar Junio C Hamano1-5/+7
Quoted-Printable (RFC 2045) and the "Q" encoding (RFC 2047) are subtly different; the latter is used on the mail header and an underscore needs to be decoded to 0x20. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-20Reintroduce svn pools to solve the memory leak.Libravatar Santi_Béjar1-1/+3
Introduced in 4802426. Signed-off-by: Santi Béjar <sbejar@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-20pack-objects: do not stop at object that is "too small"Libravatar Junio C Hamano1-1/+1
Because we sort the delta window by name-hash and then size, hitting an object that is too small to consider as a delta base for the current object does not mean we do not have better candidate in the window beyond it. Noticed by Shawn Pearce, analyzed by Nico, Linus and me. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-20Merge branch 'fix'Libravatar Junio C Hamano2-7/+16
* fix: git-commit --amend: two fixes.
2006-04-20git-commit --amend: two fixes.Libravatar Junio C Hamano2-7/+16
When running "git commit --amend" only to fix the commit log message without any content change, we mistakenly showed the git-status output that says "nothing to commit" without commenting it out. If you have already run update-index but you want to amend the top commit, "git commit --amend --only" without any paths should have worked, because --only means "starting from the base commit, update-index these paths only to prepare the index to commit, and perform the commit". However, we refused -o without paths. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-19git-update-index --unresolveLibravatar Junio C Hamano4-149/+128
Retire git-unresolve and make it into "git-update-index --unresolve". It processes all paths that follow. During a merge, you would mark a path that is dealt with with: $ git update-index hello and you would "undo" it with: $ git update-index --unresolve hello Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-19diff --stat: do not drop rename information.Libravatar Junio C Hamano1-9/+68
When a verbatim rename or copy is detected, we did not show anything on the "diff --stat" for the filepair. This makes it to show the rename information. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-19Add git-unresolve <paths>...Libravatar Junio C Hamano3-1/+149
This is an attempt to address the issue raised on #git channel recently by Carl Worth. After a conflicted automerge, "git diff" shows a combined diff to give you how the tentative automerge result differs from what came from each branch. During a complex merge, it is tempting to be able to resolve a few paths at a time, mark them "I've dealt with them" with git-update-index to unclutter the next "git diff" output, and keep going. However, when the final result does not compile or otherwise found to be a mismerge, the workflow to fix the mismerged paths suddenly changes to "git diff HEAD -- path" (to get a diff from our HEAD before merging) and "git diff MERGE_HEAD -- path" (to get a diff from theirs), and it cannot show the combined anymore. With git-unresolve <paths>..., the versions from our branch and their branch for specified blobs are placed in stage #2 and stage #3, without touching the working tree files. This gives you the combined diff back for easier review, along with "diff --ours" and "diff --theirs". One thing it does not do is to place the base in stage #1; this means "diff --base" would behave differently between the run immediately after a conflicted three-way merge, and the run after an update-index by mistake followed by a git-unresolve. We could theoretically run merge-base between HEAD and MERGE_HEAD to find which tree to place in stage #1, but reviewing "diff --base" is not that useful so.... Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-19Merge branch 'lt/xsha1'Libravatar Junio C Hamano3-1/+67
* lt/xsha1: get_tree_entry(): make it available from tree-walk sha1_name.c: no need to include diff.h; tree-walk.h will do. sha1_name.c: prepare to make get_tree_entry() reusable from others. get_sha1() shorthands for blob/tree objects
2006-04-19Merge branch 'maint'Libravatar Junio C Hamano2-1/+4
* maint: pre-commit hook: complain about conflict markers. git-merge: a bit more readable user guidance.
2006-04-19diff: move diff.c to diff-lib.c to make room.Libravatar Junio C Hamano2-1/+1
Now I am not doing any real "git-diff in C" yet, but this would help before doing so. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-19pre-commit hook: complain about conflict markers.Libravatar Junio C Hamano1-0/+3
Several <<< or === or >>> characters at the beginning of a line is very likely to be leftover conflict markers from a failed automerge the user resolved incorrectly, so detect them. As usual, this can be defeated with "git commit --no-verify" if you really do want to have those files, just like changes that introduce trailing whitespaces. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-19git-merge: a bit more readable user guidance.Libravatar Junio C Hamano1-1/+1
We said "fix up by hand" after failed automerge, which was a big "Huh? Now what?". Be a bit more explicit without being too verbose. Suggested by Carl Worth. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-19get_tree_entry(): make it available from tree-walkLibravatar Junio C Hamano3-52/+52
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-19sha1_name.c: no need to include diff.h; tree-walk.h will do.Libravatar Junio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-19sha1_name.c: prepare to make get_tree_entry() reusable from others.Libravatar Junio C Hamano1-9/+10
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-19git log: don't do merge diffs by defaultLibravatar Linus Torvalds1-2/+0
I personally prefer "ignore_merges" to be on by default, because quite often the merge diff is distracting and not interesting. That's true both with "-p" and with "--stat" output. If you want output from merges, you can trivially use the "-m", "-c" or "--cc" flags to tell that you're interested in merges, which also tells the diff generator what kind of diff to do (for --stat, any of the three will do, of course, but they differ for plain patches or for --patch-with-stat). This trivial patch just removes the two lines that tells "git log" not to ignore merges. It will still show the commit log message, of course, due to the "always_show_header" part. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-19Allow "git repack" users to specify repacking window/depthLibravatar Linus Torvalds1-3/+5
.. but don't even bother documenting it. I don't think any normal person is supposed to ever really care, but it simplifies testing when you want to use the "git repack" wrapper rather than forcing you to use the core programs (which already do support the window/depth arguments, of course). Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-19Merge branch 'fix'Libravatar Junio C Hamano2-4/+24
* fix: Document git-clone --reference Fix filename scaling for binary files
2006-04-18get_sha1() shorthands for blob/tree objectsLibravatar Linus Torvalds1-1/+66
This is a fairly straightforward patch to allow "get_sha1()" to also have shorthands for tree and blob objects. The syntax is very simple and intuitive: you can specify a tree or a blob by simply specifying <revision>:<path>, and get_sha1() will do the SHA1 lookup from the tree for you. You can currently do it with "git ls-tree <rev> <path>" and parsing the output, but that's actually pretty awkward. With this, you can do something like git cat-file blob v1.2.4:Makefile to get the contents of "Makefile" at revision v1.2.4. Now, this isn't necessarily something you really need all that often, but the concept itself is actually pretty powerful. We could, for example, allow things like git diff v0.99.6:git-commit-script..v1.3.0:git-commit.sh to see the difference between two arbitrary files in two arbitrary revisions. To do that, the only thing we'd have to do is to make git-diff-tree accept two blobs to diff, in addition to the two trees it now expects. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-18Fix uninteresting tags in new revision parsingLibravatar Linus Torvalds1-0/+1
When I unified the revision argument parsing, I introduced a simple bug wrt tags that had been marked uninteresting. When it was preparing for the revision walk, it would mark all the parent commits of an uninteresting tag correctly uninteresting, but it would forget about the commit itself. This means that when I just did my 2.6.17-rc2 release, and my scripts generated the log for "v2.6.17-rc1..v2.6.17-rc2", everything was fine, except the commit pointed to by 2.6.17-rc1 (which shouldn't have been there) was included. Even though it should obviously have been marked as being uninteresting. Not a huge deal, and the fix is trivial. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-18Document git-clone --referenceLibravatar Shawn Pearce1-1/+20
The new --reference flag introduced to git-clone in GIT 1.3.0 was not documented but is rather handy. So document it. Also corrected a minor issue with the documentation for the -s flag; the info/alternates file name was spelled wrong. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-18Fix filename scaling for binary filesLibravatar Jonas Fonseca1-3/+4
Set maximum filename length for binary files so that scaling won't be triggered and result in invalid string access. Signed-off-by: Jonas Fonseca <fonseca@diku.dk> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-18socksetup: don't return on set_reuse_addr() errorLibravatar Serge E. Hallyn1-1/+1
The set_reuse_addr() error case was the only error case in socklist() where we returned rather than continued. Not sure why. Either we must free the socklist, or continue. This patch continues on error. Signed-off-by: Serge E. Hallyn <serue@us.ibm.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-18Merge branch 'jc/pager-cat'Libravatar Junio C Hamano1-1/+1
* jc/pager-cat: Do not fork PAGER=cat
2006-04-18Merge branch 'lt/logopt'Libravatar Junio C Hamano14-437/+472
* lt/logopt: Fix "git log --stat": make sure to set recursive with --stat. combine-diff: show diffstat with the first parent. git.c: LOGSIZE is unused after log printing cleanup. Log message printout cleanups (#3): fix --pretty=oneline Log message printout cleanups (#2) Log message printout cleanups rev-list --header: output format fix Fixes for option parsing log/whatchanged/show - log formatting cleanup. Simplify common default options setup for built-in log family. Tentative built-in "git show" Built-in git-whatchanged. rev-list option parser fix. Split init_revisions() out of setup_revisions() Fix up rev-list option parsing. Fix up default abbrev in setup_revisions() argument parser. Common option parsing for "git log --diff" and friends
2006-04-18GIT 1.3.0Libravatar Junio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-18Add git-annotate(1) and git-blame(1)Libravatar Jonas Fonseca4-1/+92
[jc: with entries in git.txt] Signed-off-by: Jonas Fonseca <fonseca@diku.dk> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-18Fix "git log --stat": make sure to set recursive with --stat.Libravatar Junio C Hamano2-2/+9
Just like "patch" format always needs recursive, "diffstat" format does not make sense without setting recursive. Signed-off-by: Junio C Hamano <junkio@cox.net>