summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2007-02-06Remove contrib/colordiffLibravatar Junio C Hamano2-198/+0
This has completely been superseded by built-in --color option. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-06Call make always with CFLAGS in git.specLibravatar Horst H. von Brand1-1/+2
If not, the binaries get built once with the correct CFLAGS, and then again with the ones in the Makefile when installing Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-06add replay and log to the usage string of git-bisectLibravatar Uwe Kleine-König1-1/+1
Signed-off-by: Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-06annotate: fix for cvsserver.Libravatar Junio C Hamano2-4/+7
git-cvsserver does not want the boundary commits shown any differently. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-06gitweb: fix mismatched parenthesisLibravatar Junio C Hamano1-1/+1
An earlier commit 04179418 broke gitweb. Badly. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-06git-push: allow globbing wildcard refspec.Libravatar Junio C Hamano1-32/+82
This allows you to set up mothership-satellite configuration more symmetrically and naturally by allowing the globbing wildcard refspec for git-push. On your satellite machine: [remote "mothership"] url = mothership:project.git fetch = refs/heads/*:refs/remotes/mothership/* push = refs/heads/*:refs/remotes/satellite/* You would say "git fetch mothership" to update your tracking branches under mothership/ to keep track of the progress on the mothership side, and when you are done working on the satellite machine, you would "git push mothership" to update their tracking branches under satellite/. Corresponding configuration on the mothership machine can be used to make "git fetch satellite" update its tracking branch under satellite/. on the mothership. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-05bash: Complete git-remote subcommands.Libravatar Shawn O. Pearce1-0/+28
Completing the 3 core subcommands to git-remote, along with the names of remotes for 'show' and 'prune' (which take only existing remotes) is handy. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-05bash: Support git-rebase -m continuation completion.Libravatar Shawn O. Pearce1-1/+1
Apparently `git-rebase -m` uses a metadata directory within .git (.git/.dotest-merge) rather than .dotest used by git-am (and git-rebase without the -m option). This caused the completion code to not offer --continue, --skip or --abort when working within a `git-rebase -m` session. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-05Fix longstanding mismerge of ALL_CFLAGS vs BASIC_CFLAGSLibravatar Junio C Hamano1-1/+1
The earlier commit d7b6c3c0 (Aug 15, 2006) introduced this mismerge when most of the CFLAGS were renamed to BASIC_CFLAGS. Not that it matters right now, since we do not compile XS Perl extensions which wanted non GNU subset of ALL_CFLAGS for compilation, but we should make things consistent. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-05pager: Work around window resizing bug in 'less'Libravatar Linus Torvalds1-0/+12
If you resize the terminal while less is waiting for input, less will exit entirely without even showing the output. This is very noticeable if you do something like "git diff" on a big and cold-cache tree and git takes a few seconds to think, and then you resize the window while it's preparing. Boom. No output AT ALL. The way to reproduce the problem is to do some pager operation that takes a while in git, and resizing the window while git is thinking about the output. Try git diff --stat v2.6.12.. in the kernel tree to do something where it takes a while for git to start outputting information. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-05Teach git-remote add to fetch and trackLibravatar Junio C Hamano1-6/+48
This adds three options to 'git-remote add'. * -f (or --fetch) option tells it to also run the initial "git fetch" using the newly created remote shorthand. * -t (or --track) option tells it not to use the default wildcard to track all branches. * -m (or --master) option tells it to make the remote/$name/HEAD point at a remote tracking branch other than master. For example, with this I can say: $ git remote add -f -t master -t quick-start -m master \ jbf-um git://linux-nfs.org/~bfields/git.git/ to (1) create remote.jbf-um.url; (2) track master and quick-start branches (and no other); the two -t options create these two lines: fetch = +refs/heads/master:refs/remotes/jbf-um/master fetch = +refs/heads/quick-start:refs/remotes/jbf-um/quick-start (3) set up remotes/jbf-um/HEAD to point at jbf-um/master so that later I can say "git log jbf-um" Or I could do $ git remote add -t 'ap/*' andy /home/andy/git.git to make Andy's topic branches kept track of under refs/remotes/andy/ap/. Other possible improvements I considered but haven't implemented (hint, hint) are: * reject wildcard letters other than a trailing '*' to the -t parameter; * make -m optional and when the first -t parameter does not have the trailing '*' default to that value (so the above example does not need to say "-m master"); * if -m is not given, and -t parameter ends with '*' (i.e. the above defaulting did not tell us where to point HEAD at), and if we did the fetch with -f, check if 'master' was fetched and make HEAD point at it. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-05blame: document --contents optionLibravatar Junio C Hamano2-2/+9
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-05Use pretend_sha1_file() in git-blame and git-merge-recursive.Libravatar Junio C Hamano2-2/+2
git-merge-recursive wants an null tree as the fake merge base while producing the merge result tree. The null tree does not have to be written out in the object store as it won't be part of the result, and it is a prime example for using the new pretend_sha1_file() function. git-blame needs to register an arbitrary data to in-core index while annotating a working tree file (or standard input), but git-blame is a read-only application and the user of it could even lack the privilege to write into the object store; it is another good example for pretend_sha1_file(). Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-05Add pretend_sha1_file() interface.Libravatar Junio C Hamano2-0/+58
The new interface allows an application to temporarily hash a small number of objects and pretend that they are available in the object store without actually writing them. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-05git-blame: no rev means start from the working tree file.Libravatar Junio C Hamano3-26/+228
Warning: this changes the semantics. This makes "git blame" without any positive rev to start digging from the working tree copy, which is made into a fake commit whose sole parent is the HEAD. It also adds --contents <file> option to pretend as if the working tree copy has the contents of the named file. You can use '-' to make the command read from the standard input. If you want the command to start annotating from the HEAD commit, you need to explicitly give HEAD parameter. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-05git-blame: an Emacs minor mode to view file with git-blame output.Libravatar David Kågedal1-0/+180
Here's another version of git-blame.el that automatically tries to create a sensible list of colors to use for both light and dark backgrounds. Plus a few minor fixes. To use: 1) Load into emacs: M-x load-file RET git-blame.el RET 2) Open a git-controlled file 3) Blame: M-x git-blame-mode Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-05Allow forcing of a parent commit, even if the parent is not a direct one.Libravatar Simon 'corecode' Schubert2-4/+7
This can be used to compress multiple changesets into one, for example like git cvsexportcommit -P cvshead mybranch without having to do so in git first. Signed-off-by: Simon 'corecode' Schubert <corecode@fs.ei.tum.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-05bisect: it needs to be done in a working tree.Libravatar Junio C Hamano1-0/+1
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-05Commands requiring a work tree must not run in GIT_DIRLibravatar Johannes Schindelin4-4/+19
This patch helps when you accidentally run something like git-clean in the git directory instead of the work tree. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-05Add hg-to-git conversion utility.Libravatar Stelian Pop3-0/+262
hg-to-git.py is able to convert a Mercurial repository into a git one, and preserves the branches in the process (unlike tailor) hg-to-git.py can probably be greatly improved (it's a rather crude combination of shell and python) but it does already work quite well for me. Features: - supports incremental conversion (for keeping a git repo in sync with a hg one) - supports hg branches - converts hg tags Signed-off-by: Stelian Pop <stelian@popies.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-05blameview: Support browsable functionality to blameview.Libravatar Aneesh Kumar K.V1-3/+20
Double clicking on the row execs a new blameview with commit hash as argument. Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-05gitweb: Convert project name to UTF-8Libravatar Yasushi SHOJI1-3/+3
If the repository directory name is in non-ascii, $project needs to be converted from perl internal to utf-8 because it will be used as title, page path, and snapshot filename. use to_utf8() to do the conversion. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-05bash: Support git-bisect and its subcommands.Libravatar Shawn O. Pearce1-0/+31
We now offer completion support for git-bisect's subcommands, as well as ref name completion on the good/bad/reset subcommands. This should make interacting with git-bisect slightly easier on the fingers. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-05bash: Support --add completion to git-config.Libravatar Shawn O. Pearce1-1/+1
We've recently added --add as an argument to git-config, but I missed putting it into the earlier round of git-config updates within the bash completion. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-05bash: Hide git-resolve, its deprecated.Libravatar Shawn O. Pearce1-0/+1
Don't offer resolve as a possible subcommand completion. If you read the top of the script, there is a big warning about how it will go away soon in the near future. People should not be using it. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-05bash: Offer --prune completion for git-gc.Libravatar Shawn O. Pearce1-0/+14
I'm lazy. I don't want to type out --prune if bash can do it for me with --<tab>. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-05bash: Hide diff-stages from completion.Libravatar Shawn O. Pearce1-0/+1
Apparently nobody really makes use of git-diff-stages, as nobody has complained that it is not supported by the git-diff frontend. Since its likely this will go away in the future, we should not offer it as a possible subcommand completion. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-05bash: Support completion on git-cherry.Libravatar Shawn O. Pearce1-0/+8
I just realized I did not support ref name completion for git-cherry. This tool is just too useful to contributors who submit patches upstream by email; completion support for it is very handy. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-05Show an example of deleting commits with git-rebase.Libravatar Shawn O. Pearce1-2/+25
This particular use of git-rebase to remove a single commit or a range of commits from the history of a branch recently came up on the mailing list. Documenting the example should help other users arrive at the same solution on their own. It also was not obvious to the newcomer that git-rebase is able to accept any commit for --onto <newbase> and <upstream>. We should at least minimally document this, as much of the language in git-rebase's manpage refers to 'branch' rather than 'committish'. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-05git-for-each-ref doesn't return "the bit after $GIT_DIR/refs"Libravatar Andy Parkins1-1/+1
The documentation for git-for-each-ref said that the refname variable would return "the part after $GIT_DIR/refs/", which isn't true. Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-05t9200: Work around HFS+ issues.Libravatar Junio C Hamano1-0/+14
We at least know that the test as written has a problem in an environment where "touch '$p'; ls | fgrep '$p'" fails, and have a clear understand why it fails. This tests if the filesystem has that particular issue we know "git add" has a problem with, and skips the test in such an environment. This way, we might catch issues "git add" might have in other environments. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-04Rename get_ident() to fmt_ident() and make it available to outsideLibravatar Junio C Hamano2-4/+5
This makes the functionality of ident.c::get_ident() available to other callers. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-04git-archimport: initial import needs empty directoryLibravatar Gerrit Pape1-0/+9
git-archimport should better refuse to start an initial import if the current directory is not empty. (http://bugs.debian.org/400508) Signed-off-by: Gerrit Pape <pape@smarden.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-04Revert "Allow branch.*.merge to talk about remote tracking branches."Libravatar Junio C Hamano1-6/+2
This reverts commit 80c797764a6b6a373f0f1f47d7f56b0d950418a9. Back when I committed this, it seemed to be a good idea. People who always use remote tracking branches can optionally use the local name they happen to use to specify what to merge, which meant that I did not have to teach them why we use the name at the remote side every time they are confused. But allowing it seems to break other people's scripts. The real solution is not to allow more ways to express the same thing, but to educate people to use the right syntax. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-04Merge branch 'np/dreflog'Libravatar Junio C Hamano14-135/+232
* np/dreflog: show-branch -g: default to the current branch. Let git-checkout always drop any detached head Enable HEAD@{...} and make it independent from the current branch scan reflogs independently from refs add reflog when moving HEAD to a new branch create_symref(): do not assume pathname from git_path() persists long enough add logref support to git-symbolic-ref move create_symref() past log_ref_write() add reflog entries for HEAD when detached enable separate reflog for HEAD lock_ref_sha1_basic(): remember the original name of a ref when resolving it make reflog filename independent from struct ref_lock
2007-02-04Why is it bad to rewind a branch that has already been pushed out?Libravatar Robin Rosenberg1-0/+2
Mention git-revert as an alternative to git-reset to revert changes. Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-04git-clone --reference: saner handling of borrowed symrefs.Libravatar Junio C Hamano2-2/+67
When using --reference to borrow objects from a neighbouring repository while cloning, we copy the entire set of refs under temporary "refs/reference-tmp/refs" space and set up the object alternates. However, a textual symref copied this way would not point at the right place, and causes later steps to emit error messages (which is harmless but still alarming). This is most visible when using a clone created with the separate-remote layout as a reference, because such a repository would have refs/remotes/origin/HEAD with 'ref: refs/remotes/origin/master' as its contents. Although we do not create symbolic-link based refs anymore, they have the same problem because they are always supposed to be relative to refs/ hierarchy (we dereference by hand, so it only is good for HEAD and nothing else). In either case, the solution is simply to remove them after copying under refs/reference-tmp; if a symref points at a true ref, that true ref itself is enough to ensure that objects reachable from it do not needlessly get fetched. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-04bash: Support internal revlist options better.Libravatar Shawn O. Pearce1-1/+3
format-patch/log/whatchanged all take --not and --all as options to the internal revlist process. So these should be supported as possible completions. gitk takes anything rev-list/log/whatchanged takes, so we should use complete_revlist to handle its options. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-04bash: Support unique completion when possible.Libravatar Shawn O. Pearce1-99/+91
Because our use of -o nospace prevents bash from adding a trailing space when a completion is unique and has been fully completed, we need to perform this addition on our own. This (large) change converts all existing uses of compgen to our wrapper __gitcomp which attempts to handle this by tacking a trailing space onto the end of each offered option. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-04bash: Support unique completion on git-config.Libravatar Shawn O. Pearce1-38/+82
In many cases we know a completion will be unique, but we've disabled bash's automatic space addition (-o nospace) so we need to do it ourselves when necessary. This change adds additional support for new configuration options added in 1.5.0, as well as some extended completion support for the color.* family of options. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-04bash: Classify more commends out of completion.Libravatar Shawn O. Pearce1-1/+17
Most of these commands are not ones you want to invoke from the command line on a frequent basis, or have been renamed in 1.5.0 to more friendly versions, but the old names are being left behind to support existing scripts in the wild. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-04bash: Add space after unique command name is completed.Libravatar Shawn O. Pearce1-6/+20
Because we use the nospace option for our completion function for the main 'git' wrapper bash won't automatically add a space after a unique completion has been made by the user. This has been pointed out in the past by Linus Torvalds as an undesired behavior. I agree. We have to use the nospace option to ensure path completion for a command such as `git show` works properly, but that breaks the common case of getting the space for a unique completion. So now we set IFS=$'\n' (linefeed) and add a trailing space to every possible completion option. This causes bash to insert the space when the completion is unique. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-04bash: Complete long options to git-add.Libravatar Shawn O. Pearce1-0/+16
The new --interactive mode of git-add can be very useful, so users will probably want to have completion for it. Likewise the new git-add--interactive executable is actually a plumbing command. Its invoked by `git add --interactive` and is not intended to be invoked directly by the user. Therefore we should hide it from the list of available Git commands. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-04bash: Classify cat-file and reflog as plumbing.Libravatar Shawn O. Pearce1-20/+3
Now that git-show is capable of displaying any file content from any revision and is the approved Porcelain-ish level method of doing so, cat-file should no longer be classified as a user-level utility by the bash completion package. I'm also classifying the new git-reflog command as plumbing for the time being as there are no subcommands which are really useful to the end-user. git-gc already invokes `git reflog expire --all`, which makes it rather unnecessary for the user to invoke it directly. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-04bash: Remove short option completions for branch/checkout/diff.Libravatar Shawn O. Pearce1-3/+3
The short options (-l, -f, -d) for git-branch are rather silly to include in the completion generation as these options must be fully typed out by the user and most users already know what the options are anyway, so including them in the suggested completions does not offer huge value. (The same goes for git-checkout and git-diff.) Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-03show-branch -g: default to the current branch.Libravatar Junio C Hamano2-4/+9
Now we have a separate reflog on HEAD, show-branch -g without an explicit parameter defaults to the current branch, or HEAD when it is detached from branches. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-03Let git-checkout always drop any detached headLibravatar Nicolas Pitre1-15/+2
We used to refuse leaving a detached HEAD when it wasn't matching an existing ref so not to lose any commit that might have been performed while not on any branch (unless -f was provided). But this protection was completely bogus since it was still possible to move to HEAD^ while still remaining detached but losing the last commit anyway if there was one. Now that we have a proper reflog for HEAD it is best to simply remove that bogus (and admitedly annoying) protection and simply display the last HEAD position instead. If one wants to recover a lost detached state then it can be retrieved from the HEAD reflog. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-03Enable HEAD@{...} and make it independent from the current branchLibravatar Nicolas Pitre1-26/+36
Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-03Merge branch 'master' into np/dreflogLibravatar Junio C Hamano123-923/+5106
This is to resolve conflicts early in preparation for possible inclusion of "reflog on detached HEAD" series by Nico, as having it in 1.5.0 would really help us remove confusion between detached and attached states. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-03Default GIT_MERGE_VERBOSITY to 5 during tests.Libravatar Shawn O. Pearce1-0/+2
Its really nice to be able to run a test with -v and automatically see the "debugging" dump from merge-recursive, especially if we are actually trying to debug merge-recursive. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>