summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2007-02-02core-tutorial: http reference link fixLibravatar Junio C Hamano1-2/+2
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-02Tutorial-2: Adjust git-status output to recent reality.Libravatar Junio C Hamano1-8/+7
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-02Tutorial: fix asciidoc formatting of "git add" section.Libravatar Junio C Hamano1-18/+18
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-02Don't leak file descriptors from unavailable pack files.Libravatar Shawn O. Pearce1-1/+16
If open_packed_git failed it may have been because the packfile actually exists and is readable, but some sort of verification did not pass. In this case open_packed_git left pack_fd filled in, as the file descriptor is valid. We don't want to leak the file descriptor, nor do we want to allow someone in the future to use this packed_git. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-02doc: hooks.txt said post-commit default sends an email, it doesn'tLibravatar Andy Parkins1-3/+2
The default post-commit hook is actually empty; it is the update hook that sends an email. This patch corrects hooks.txt to reflect that. Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-02Disallow invalid --pretty= abbreviationsLibravatar Eric Wong1-1/+2
--pretty=o is a valid abbreviation, --pretty=omfg is not Noticed by: Nicolas Vilz Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-01Fix some documentation typos and grammarLibravatar Mike Coleman2-6/+8
Also suggest user manual mention .gitignore. Signed-off-by: Michael Coleman <tutufan@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-01Don't find objects in packs which aren't available anymore.Libravatar Shawn O. Pearce1-0/+12
Matthias Lederhofer identified a race condition where a Git reader process was able to locate an object in a packed_git index, but was then preempted while a `git repack -a -d` ran and completed. By the time the reader was able to seek in the packfile to get the object data, the packfile no longer existed on disk. In this particular case the reader process did not attempt to open the packfile before it was deleted, so it did not already have the pack_fd field popuplated. With the packfile itself gone, there was no way for the reader to open it and fetch the data. I'm fixing the race condition by teaching find_pack_entry to ignore a packed_git whose packfile is not currently open and which cannot be opened. If none of the currently known packs can supply the object, we will return 0 and the caller will decide the object is not available. If this is the first attempt at finding an object, the caller will reprepare_packed_git and try again. If it was the second attempt, the caller will typically return NULL back, and an error message about a missing object will be reported. This patch does not address the situation of a reader which is being starved out by a tight sequence of `git repack -a -d` runs. In this particular case the reader will try twice, probably fail both times, and declare the object in question cannot be found. As it is highly unlikely that a real world `git repack -a -d` can complete faster than a reader can open a packfile, so I don't think this is a huge concern. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-01Refactor open_packed_git to return an error code.Libravatar Shawn O. Pearce1-15/+16
Because I want to reuse open_packed_git in a context where I don't want the process to die if the packfile in question is bogus, I'm changing its behavior to return error("...") rather than die("...") when it detects something is wrong with the packfile it was given. Right now we still must die out of use_pack should open_packed_git fail, as none of use_pack's callers are prepared to handle a failure from that function. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-01Correct comment in prepare_packed_git_one.Libravatar Shawn O. Pearce1-1/+4
After staring at the comment and the associated for loop, I realized the comment was completely bogus. The section of code its talking about is trying to avoid duplicate mapping of the same packfile. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-01Cleanup prepare_packed_git_one to reuse install_packed_git.Libravatar Shawn O. Pearce1-2/+1
There is little point in having the linked list insertion code appearing in install_packed_git, and then again just 30 lines further down in the same file. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-01Teach 'git remote' how to cleanup stale tracking branches.Libravatar Shawn O. Pearce2-1/+43
Since it can be annoying to manually cleanup 40 tracking branches which were removed by the remote system, 'git remote prune <n>' can now be used to delete any tracking branches under <n> which are no longer available on the remote system. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-01Pull out remote listing functions in git-remote.Libravatar Shawn O. Pearce1-20/+23
I want to reuse the stale branch detection to implement a new 'git remote prune' subcommand. Easiest way to do that is to use the same logic that 'git remote show' uses to determine the stale tracking branches, then delete those. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-01git-svn: do not let Git.pm warn if we prematurely close pipesLibravatar Eric Wong1-5/+5
This mainly quiets down warnings when running git svn log. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-01Update the documentation for the new '@{...}' syntaxLibravatar Johannes Schindelin1-0/+4
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-01Teach the '@{...}' notation to git-log -gLibravatar Johannes Schindelin1-0/+8
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-01provide a nice @{...} syntax to always mean the current branch reflogLibravatar Nicolas Pitre1-6/+11
This is shorter than HEAD@{...} and being nameless it has no semantic issues. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-01prevent HEAD reflog to be interpreted as current branch reflogLibravatar Nicolas Pitre1-1/+15
The work in progress to enable separate reflog for HEAD will make it independent from reflog of any branch HEAD might be pointing to. In the mean time disallow HEAD@{...} until that work is completed. Otherwise people might get used to the current behavior which makes HEAD@{...} an alias for <current_branch>@{...} which won't be the case later. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-01Use "git checkout -q" in git-bisectLibravatar Junio C Hamano1-1/+1
Converts one use of git-checkout in git-bisect not to say "switching to branch". It looks like all the other cases it is friendlier to give notice to the end user. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-01add a quiet option to git-checkoutLibravatar Nicolas Pitre2-10/+18
Those new messages are certainly nice, but there might be cases where they are simply unwelcome, like when git-commit is used within scripts. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-01reword the detached head message a little againLibravatar Nicolas Pitre1-1/+1
Seems clearer this way, to me at least. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-01detached HEAD -- finishing touchesLibravatar Junio C Hamano1-2/+8
This updates "git-checkout" to report which branch you are switching to. Especially for people who do not use __git_ps1 from contrib/completion/git-completion.bash this would give a friendlier feedback of what is going on, and should make the reminder message much less scary. Here is a sample session (the prompt tells which branch I am on). * I have some local modification and realize that the change deserves to be on its own new topic branch. [git.git (master)]$ git diff --stat git-checkout.sh | 10 ++++++++-- 1 files changed, 8 insertions(+), 2 deletions(-) * So I switch to a new branch. I get a listing of local modifications and assuring "Switched to a new branch" message. [git.git (master)]$ git checkout -b jc/checkout M git-checkout.sh Switched to a new branch "jc/checkout" * If I switch back to "master", I get essentially the same. [git.git (jc/checkout)]$ git checkout master M git-checkout.sh Switched to branch "master" * Detaching head would say which commit I am at and reminds me that I am not on any branch (not that I would detach my HEAD while keeping precious local changes around in any real-world workflow -- this is just a sample session). [git.git (master)]$ git checkout master^ M git-checkout.sh Note: you are not on any branch and are at commit "master^" If you want to create a new branch from this checkout, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b <new_branch_name> * Coming back to an attached state can lose the detached HEAD, so I get warned and stopped. [git.git]$ git checkout master You are not on any branch and switching to branch 'master' may lose your changes. At this point, you can do one of two things: (1) Decide it is Ok and say 'git checkout -f master'; (2) Start a new branch from the current commit, by saying 'git checkout -b <branch-name>'. Leaving your HEAD detached; not switching to branch 'master'. * Moving around while my HEAD is detached is Ok. I still get the list of local modifications. [git.git]$ git checkout master^0 M git-checkout.sh * The previous step that switched to the tip commit is an obscure but useful trick. My HEAD is still detached but now it is pointed at by an existing ref, so I can come back safely. [git.git]$ git checkout master M git-checkout.sh Switched to branch "master" * And we are back on the "master" branch. [git.git (master)]$ exit Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-31GIT v1.5.0-rc3Libravatar Junio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-31Do not use hardcoded path to xhmtl.xsl to generate user's manualLibravatar Junio C Hamano1-1/+1
It does not seem to need it either and gives an error on FC5 I use at kernel.org to cut documentation tarballs, so remove it in the meantime. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-31git main documentation: point at the user's manual.Libravatar Junio C Hamano1-0/+3
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-31Merge branch 'master' of git://linux-nfs.org/~bfields/gitLibravatar Junio C Hamano4-1/+3273
This is in the hope of giving JBF's user-manual wider exposure. I am not very happy with trailing whitespaces in the new document, but let's not worry too much about the formatting issues for now, but concentrate more on the structure and the contents.
2007-01-31t9200: do not test -x bit if the filesystem does not support it.Libravatar Junio C Hamano1-0/+6
The last test in t9200 wants to see if executable bit is retained, which has no chance of succeeding on a filesystem that does not handle executable bit correctly. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-31t9200: Re-code non-ascii path test in UTF-8Libravatar Junio C Hamano1-8/+8
For the purpose of this test we do not really care if the paths are in latin-1, but people on Cygwin seem to be having problem on foreign-looking pathnames that do not play well with their locale. Let's try to re-code them in UTF-8 and see who screams, thanks, or reports no-improvements. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-31Update git-cat-file documentationLibravatar Aneesh Kumar K.V1-1/+3
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-31Documentation: "git-checkout <tree> <path>" takes any tree-ishLibravatar Junio C Hamano1-5/+7
Especially, it is not limited to branch. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-31Improved error message from git-rebaseLibravatar David Kågedal1-1/+2
If the index wasn't clean, git-rebase would simply show the output from git-diff-index with no further comment to the user. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-31Fix git-update-index to work with relative pathnames.Libravatar Alex Riesen1-2/+6
In particular, it fixes the following (typical for cygwin) problem: $ git-update-index --chmod=-x ../wrapper/Jamfile fatal: git-update-index: cannot chmod -x '../wrapper/Jamfile' Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-31Escape --upload-pack from expr.Libravatar Shawn O. Pearce3-3/+3
Recent commit ae1dffcb28ee89a23f8d2747be65e17c8eab1690 by Junio changed the way --upload-pack was passed around between clone, fetch and ls-remote and modified the handling of the command line parameter parsing. Unfortunately FreeBSD 6.1 insists that the expression expr --upload-pack=git-upload-pack : '-[^=]*=\(.*\)' is illegal, as the --upload-pack option is not supported by their implementation of expr. Elsewhere in Git we use z as a leading prefix of both arguments, ensuring the -- isn't seen by expr. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-31Don't coredump on bad refs in update-server-info.Libravatar Shawn O. Pearce1-0/+2
Apparently if we are unable to parse an object update-server-info coredumps, as it doesn't bother to check the return value of its call to parse_object. Instead of coredumping, skip the ref. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-31tone down the detached head warningLibravatar Nicolas Pitre1-3/+3
This is not meant to frighten people or even to suggest they might be doing something wrong, but rather to notify them of a state change and provide a likely option in the case this state was entered by mistake. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-30Fix git-tag -uLibravatar Junio C Hamano1-3/+4
... which I broke when we introduced user.signingkey configuration. There was no reason to add a new variable keyid to the script. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-30user-manual: todo'sLibravatar J. Bruce Fields1-1/+3
Update todo's. Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
2007-01-30user-manual: point to README for gitweb informationLibravatar J. Bruce Fields1-1/+4
I'd like complete gitweb setup instructions some day, but for now just refer to the gitweb README. Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
2007-01-30blameview: Use git-cat-file to read the file content.Libravatar Aneesh Kumar K.V1-1/+2
Fix blameview to use git-cat-file to read the file content. This make sure we show the right content when we have modified file in the working directory which is not committed. Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-30git-fetch: Allow fetching the remote HEADLibravatar Santi Béjar1-1/+1
... with: $ git fetch ${remote} HEAD Also $ git fetch ${remote} :${localref} worked, but $ git fetch ${remote} HEAD:{localref} didn't. Now both are equivalent. Signed-off-by: Santi Béjar <sbejar@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-30git-send-email: remove debugging output.Libravatar Junio C Hamano1-1/+1
rfc2047 unquoter spitted out an annoying "- unquoted" which was added during debugging but I forgot to remove. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-30Add a missing fork() error check.Libravatar Johannes Sixt1-0/+2
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-29git-blame: somewhat better commenting.Libravatar Junio C Hamano1-38/+255
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-29Make fsck and fsck-objects be builtins.Libravatar Mark Wooding4-2/+5
The earlier change df391b192 to rename fsck-objects to fsck broke fsck-objects. This should fix it again. Signed-off-by: Mark Wooding <mdw@distorted.org.uk> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-29git-commit -s: no extra space when sign-offs appear at the end already.Libravatar Junio C Hamano1-1/+4
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-29Replace perl code with pure shell codeLibravatar Simon 'corecode' Schubert1-44/+23
Signed-off-by: Simon 'corecode' Schubert <corecode@fs.ei.tum.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-29lock_any_ref_for_update(): do not accept malformatted refs.Libravatar Junio C Hamano2-4/+4
We used to use lock_any_ref_for_update() because the command needs to also update HEAD (which is not under refs/, so lock_ref_sha1() cannot be used). The function however did not check for refs with illegal characters in them. Use check_ref_format() to catch malformed refs. For this check, we specifically do not want to say having less than two levels in the name is illegal to allow HEAD (and perhaps other special refs in the future). Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-29Two small typofixes.Libravatar Junio C Hamano1-2/+2
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-29user-manual: SHA1 -> object nameLibravatar J. Bruce Fields1-5/+5
Prefer "object name" to SHA1, at least in higher level documentation. Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
2007-01-29user-manual: document git-show-branch exampleLibravatar J. Bruce Fields1-2/+28
Document Junio's show-branch trick for finding out which tags are descendents of a given comit. Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>