summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2006-12-19Remove COLLISION_CHECK from Makefile since it's not used.Libravatar Brian Gernhardt2-8/+0
It's rather misleading to have configuration options that don't do anything. If someone adds collision checking they might also want to restore this option. Signed-off-by: Brian Gernhardt <benji@silverinsanity.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-19fix populate-filespecLibravatar Junio C Hamano1-1/+1
I hand munged the original patch when committing 1510fea78, and screwed up the conversion. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-19git-cvsserver: fix breakage when calling git merge-fileLibravatar Eric Wong1-1/+1
In the same vein as 8336afa563fbeff35e531396273065161181f04c, this fixes the the RCS merge to git-merge-file conversion in commit e2b70087. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-18rerere: fix breakage of resolving.Libravatar Junio C Hamano1-1/+1
commit e2b70087 botched the RCS merge to git-merge-file conversion. There is no command called "git merge-file" (yes, we are using safer variant of Perl's system(3)). Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-18Add config example with respect to branchLibravatar Aneesh Kumar K.V1-0/+5
Update config.txt with example with respect to branch config variable. This give a better idea regarding how branch names are expected. Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-18Add documentation for show-branch --topicsLibravatar Brian Gernhardt1-1/+9
Add a quick paragraph explaining the --topics option for show-branch. The explanation is an abbreviated version of the commit message from d320a5437f8304cf9ea3ee1898e49d643e005738. Signed-off-by: Brian Gernhardt <benji@silverinsanity.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-18make git a bit less cryptic on fetch errorsLibravatar Nicolas Pitre3-3/+3
The remote server might not want to tell why it doesn't like us for security reasons, but let's make the client report such error in a bit less confusing way. The remote failure remains a mystery, but the local message might be a bit less so. [jc: with a gentle wording updates from Andy Parkins] Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-18make patch_delta() error cases a bit more verboseLibravatar Nicolas Pitre2-9/+8
It is especially important to distinguish between a malloc() failure from all the other cases. An out of memory condition is much less worrisome than a compatibility/corruption problem. Also make test-delta compilable again. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-18racy-git: documentation updates.Libravatar Junio C Hamano1-18/+20
We've removed the workaround for runtime penalty that did not exist in practice some time ago, but the technical paper that proposed that change still said "we probably should do so". Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-18show-ref: fix --exclude-existingLibravatar Junio C Hamano1-3/+4
Do not falsely document --filter-invalid which does not even exist. Also make sure the line is long enough to have ^{} suffix before checking for it. Pointed out by Dscho. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-18parse-remote::expand_refs_wildcard()Libravatar Junio C Hamano1-5/+3
Work around dash incompatibility by not using "${name%'^{}'}". Noticed by Jeff King; dash seems to mistake the closing brace inside the single quote as the terminating brace for parameter expansion. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-18vim syntax: follow recent changes to commit templateLibravatar Jeff King1-2/+2
This patch changes the syntax highlighting to correctly match the new text of the commit message introduced by 82dca84871637ac9812c0dec27f56d07cfba524c Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-17show-ref: fix --verify --hash=lengthLibravatar Junio C Hamano1-10/+15
An earlier optimization for --verify broke a lot of stuff because it did not take interaction with other flags into account. This also fixes an unrelated argument parsing error; --hash=8 should mean the same as "--hash --abbrev=8". Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-17show-ref: fix --quiet --verifyLibravatar Junio C Hamano1-3/+5
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-17Merge branch 'jc/blame-boundary'Libravatar Junio C Hamano1-1/+14
* jc/blame-boundary: git-blame: show lines attributed to boundary commits differently.
2006-12-17Merge branch 'jc/reflog' (early part)Libravatar Junio C Hamano1-5/+30
* 'jc/reflog' (early part): Teach show-branch how to show ref-log data.
2006-12-17Merge branch 'js/branch-config'Libravatar Junio C Hamano6-1/+142
* js/branch-config: git-branch: rename config vars branch.<branch>.*, too add a function to rename sections in the config
2006-12-17Merge branch 'jn/web' (early part)Libravatar Junio C Hamano1-33/+183
* 'jn/web' (early part): gitweb: Add "next" link to commit view gitweb: Add title attribute to ref marker with full ref name gitweb: Do not show difftree for merges in "commit" view gitweb: SHA-1 in commit log message links to "object" view gitweb: Hyperlink target of symbolic link in "tree" view (if possible) gitweb: Add generic git_object subroutine to display object of any type gitweb: Show target of symbolic link in "tree" view gitweb: Don't use Content-Encoding: header in git_snapshot
2006-12-17avoid accessing _all_ loose refs in git-show-ref --verifyLibravatar Junio C Hamano1-0/+17
If you want to verify a ref, it is overkill to first read all loose refs into a linked list, and then check if the desired ref is there. Signed-off-by: Junio C Hamano <junkio@cox.net> Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
2006-12-17git-fetch: Avoid reading packed refs over and over againLibravatar Junio C Hamano2-10/+62
When checking which tags to fetch, the old code used to call git-show-ref --verify for each remote tag. Since reading even packed refs is not a cheap operation when there are a lot of local refs, the code became quite slow. This fixes it by teaching git-show-ref to filter out existing refs using a new mode of operation of git-show-ref. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-17Teach show-branch how to show ref-log data.Libravatar Junio C Hamano1-5/+30
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-17markup fix in svnimport documentation.Libravatar Junio C Hamano1-8/+8
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-17Documentation: new option -P for git-svnimportLibravatar Quy Tonthat1-0/+9
Documentation: new option -P for git-svnimport. Signed-off-by: Quy Tonthat <qtonthat@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-17Fix mis-mark-up in git-merge-file.txt documentationLibravatar Junio C Hamano1-2/+2
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-17Default GIT_COMMITTER_NAME to login name in recieve-pack.Libravatar Shawn O. Pearce3-0/+18
If GIT_COMMITTER_NAME is not available in receive-pack but reflogs are enabled we would normally die out with an error message asking the user to correct their environment settings. Now that reflogs are enabled by default in (what we guessed to be) non-bare Git repositories this may cause problems for some users who don't have their full name in the gecos field and who don't have access to the remote system to correct the problem. So rather than die()'ing out in receive-pack when we try to log a ref change and have no committer name we default to the username, as obtained from the host's password database. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-17Fix check_file_directory_conflict().Libravatar Junio C Hamano2-1/+10
When replacing an existing file A with a directory A that has a file A/B in it in the index, 'update-index --replace --add A/B' did not properly remove the file to make room for the new directory. There was a trivial logic error, most likely a cut & paste one, dating back to quite early days of git. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-17git-add: remove conflicting entry when adding.Libravatar Junio C Hamano1-1/+1
When replacing an existing file A with a directory A that has a file A/B in it in the index, 'git add' did not succeed because it forgot to pass the allow-replace flag to add_cache_entry(). It might be safer to leave this as an error and require the user to explicitly remove the existing A first before adding A/B since it is an unusual case, but doing that automatically is much easier to use. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-17update-index: make D/F conflict error a bit more verbose.Libravatar Junio C Hamano1-1/+1
When you remove a directory D that has a tracked file D/F out of the way to create a file D and try to "git update-index --add D", it used to say "cannot add" which was not very helpful. This issues an extra error message to explain the situation before the final "fatal" message. Since D/F conflicts are relatively rare event, extra verbosity would not make things too noisy. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-16git-branch: rename config vars branch.<branch>.*, tooLibravatar Johannes Schindelin2-0/+16
When renaming a branch, the corresponding config section should be renamed, too. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-16add a function to rename sections in the configLibravatar Johannes Schindelin4-1/+126
Given a config like this: # A config [very.interesting.section] not The command $ git repo-config --rename-section very.interesting.section bla.1 will lead to this config: # A config [bla "1"] not Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-16merge: give a bit prettier merge message to "merge branch~$n"Libravatar Junio C Hamano1-9/+17
This hacks the input to fmt-merge-msg to make the message for merging early part of a branch a little easier to read. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-16gitweb: Add "next" link to commit viewLibravatar Jakub Narebski1-9/+29
Add a kind of "next" view in the bottom part of navigation bar for "commit" view, similar to what was added for "commitdiff" view in commit 151602df00b8e5c5b4a8193f59a94b85f9b5aebc 'gitweb: Add "next" link to commitdiff view' For "commit" view for single parent commit: (parent: _commit_) For "commit" view for merge (multi-parent) commit: (merge: _commit_ _commit_ ...) For "commit" view for root (parentless) commit (initial) where _link_ denotes hyperlink. SHA1 of commit is shortened to 7 characters on display. While at it, remove leftovers from commit cae1862a by Petr Baudis: 'gitweb: More per-view navigation bar links' namely the "blame" link if there exist $file_name and commit has a parent; it was added in git_commit probably by mistake. The rest of what mentioned commit added for git_commit was removed in commit 6e0e92fda893311ff5af91836e5007bf6bbd4a21 by Luben Tuikov: 'gitweb: Do not print "log" and "shortlog" redundantly in commit view' (which should have probably removed also this "blame" link removed now). Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-16gitweb: Add title attribute to ref marker with full ref nameLibravatar Jakub Narebski1-1/+2
Add title attribute, which will be shown as popup on mouseover in graphical web browsers, with full name of ref, including part (type) removed from the name of ref itself. This is useful to see that this strange ref is StGIT ref, or it is remote branch, or it is lightweigh tag (with branch-like name). Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-16gitweb: Do not show difftree for merges in "commit" viewLibravatar Jakub Narebski1-7/+15
Do not show difftree against first parent for merges (commits with more than one parent) in "commit" view, because it usually is misleading. git-show and git-whatchanged doesn't show diff for merges either. Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-16Document git-merge-fileLibravatar Johannes Schindelin2-0/+95
Most of this is derived from the documentation of RCS merge. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-15git-clone documentationLibravatar Quy Tonthat1-1/+1
When --use-separate-remote is used on git-clone, the remote heads are saved under $GIT_DIR/refs/remotes/origin/, not "$GIT_DIR/remotes/origin/" Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-15git-status always says what branch it's onLibravatar Andy Parkins1-1/+1
If the current branch was "master" then git-status wouldn't say # On branch XXXX In its output. This patch makes it so that this message is always output; regardless of branch name. Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-15Align section headers of 'git status' to new 'git add'.Libravatar Shawn O. Pearce4-12/+13
Now that 'git add' is considered a first-class UI for 'update-index' and that the 'git add' documentation states "Even modified files must be added to the set of changes about to be committed" we should make the output of 'git status' align with that documentation and common usage. So now we see a status output such as: # Added but not yet committed: # (will commit) # # new file: x # # Changed but not added: # (use "git add file1 file2" to include for commit) # # modified: x # # Untracked files: # (use "git add" on files to include for commit) # # y which just reads better in the context of using 'git add' to manipulate a commit (and not a checkin, whatever the heck that is). We also now support 'color.status.added' as an alias for the existing 'color.status.updated', as this alias more closely aligns with the current output and documentation. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-15Suggest use of "git add file1 file2" when there is nothing to commit.Libravatar Shawn O. Pearce2-6/+7
If a user modifies files and runs 'git commit' (without the very useful -a option) and they have not yet updated the index they are probably coming from another SCM-like tool which would perform the same as 'git commit -a' in this case. Showing the user their current status and a final line of "nothing to commit" is not very reassuring, as the user might believe that Git did not recognize their files were modified. Instead we can suggest as part of the 'nothing to commit' message that the user invoke 'git add' to add files to their next commit. Suggested by Andy Parkins' Git 'niggles' list (<200612132237.10051.andyparkins@gmail.com>). Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-15Make git-diff documentation use [--] when it should.Libravatar Brian Gernhardt1-3/+3
Two of the cases has "[--] [<path>...]" and two had "-- [<path>...]". Not terribly consistent and potentially confusing. Also add "[--]" to the synopsis so that it's obvious you can use it from the very beginning. Signed-off-by: Brian Gernhardt <benji@silverinsanity.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-15Add --add option to git-repo-configLibravatar Brian Gernhardt3-3/+27
For multivars, the "git-repo-config name value ^$" is useful but nonintuitive and troublesome to do repeatedly (since the value is not at the end of the command line). This commit simply adds an --add option that adds a new value to a multivar. Particularly useful for tracking a new branch on a remote: git-repo-config --add remote.origin.fetch +next:origin/next Includes documentation and test. Signed-off-by: Brian Gernhardt <benji@silverinsanity.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-15Teach bash the new features of 'git show'.Libravatar Shawn O. Pearce1-3/+21
Now that 'git show' accepts ref:path as an argument to specify a tree or blob we should use the same completion logic as we support for cat-file's object identifier. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-15Export PERL_PATHLibravatar Luben Tuikov1-0/+2
PERL_PATH is used by perl/Makefile so export it. Signed-off-by: Luben Tuikov <ltuikov@yahoo.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-15Enable reflogs by default in any repository with a working directory.Libravatar Shawn O. Pearce5-4/+21
New and experienced Git users alike are finding out too late that they forgot to enable reflogs in the current repository, and cannot use the information stored within it to recover from an incorrectly entered command such as `git reset --hard HEAD^^^` when they really meant HEAD^^ (aka HEAD~2). So enable reflogs by default in all future versions of Git, unless the user specifically disables it with: [core] logAllRefUpdates = false in their .git/config or ~/.gitconfig. We only enable reflogs in repositories that have a working directory associated with them, as shared/bare repositories do not have an easy means to prune away old log entries, or may fail logging entirely if the user's gecos information is not valid during a push. This heuristic was suggested on the mailing list by Junio. Documentation was also updated to indicate the new default behavior. We probably should start to teach usuing the reflog to recover from mistakes in some of the tutorial material, as new users are likely to make a few along the way and will feel better knowing they can recover from them quickly and easily, without fsck-objects' lost+found features. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-15Provide more meaningful output from 'git init-db'.Libravatar Shawn O. Pearce4-10/+17
Back in the old days of Git when people messed around with their GIT_DIR environment variable more often it was nice to know whether or not git-init-db created a .git directory or used GIT_DIR. As most users at that time were rather technical UNIXy folk the message "defaulting to local storage area" made sense to some and seemed reasonable. But it doesn't really convey any meaning to the new Git user, as they don't know what a 'local storage area is' nor do they know enough about Git to care. It also really doesn't tell the experienced Git user a whole lot about the command they just ran, especially if they might be reinitializing an existing repository (e.g. to update hooks). So now we print out what we did ("Initialized empty" or "Reinitialized existing"), what type of repository ("" or "shared"), and what location the repository will be in ("$GIT_DIR"). Suggested in part by Andy Parkins in his Git 'niggles' list (<200612132237.10051.andyparkins@gmail.com>). Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-15make commit message a little more consistent and confortingLibravatar Nicolas Pitre9-29/+84
It is nicer to let the user know when a commit succeeded all the time, not only the first time. Also the commit sha1 is much more useful than the tree sha1 in this case. This patch also introduces a -q switch to supress this message as well as the summary of created/deleted files. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-15Avoid accessing a slow working copy during diffcore operations.Libravatar Shawn O. Pearce2-3/+28
The Cygwin folks have done a fine job at creating a POSIX layer on Windows That Just Works(tm). However it comes with a penalty; accessing files in the working tree by way of stat/open/mmap can be slower for diffcore than inflating the data from a blob which is stored in a packfile. This performance problem is especially an issue in merge-recursive when dealing with nearly 7000 added files, as we are loading each file's content from the working directory to perform rename detection. I have literally seen (and sadly watched) paint dry in less time than it takes for merge-recursive to finish such a merge. On the other hand this very same merge runs very fast on Solaris. If Git is compiled with NO_FAST_WORKING_DIRECTORY set then we will avoid looking at the working directory when the blob in question is available within a packfile and the caller doesn't need the data unpacked into a temporary file. We don't use loose objects as they have the same open/mmap/close costs as the working directory file access, but have the additional CPU overhead of needing to inflate the content before use. So it is still faster to use the working tree file over the loose object. If the caller needs the file data unpacked into a temporary file its likely because they are going to call an external diff program, passing the file as a parameter. In this case reusing the working tree file will be faster as we don't need to inflate the data and write it out to a temporary file. The NO_FAST_WORKING_DIRECTORY feature is enabled by default on Cygwin, as that is the platform which currently appears to benefit the most from this option. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-15Merge branch 'js/show'Libravatar Junio C Hamano3-9/+115
* js/show: git-show: grok blobs, trees and tags, too
2006-12-14git-show: grok blobs, trees and tags, tooLibravatar Johannes Schindelin3-9/+115
Since git-show is pure Porcelain, it is the ideal candidate to pretty print other things than commits, too. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-14git-reset [--mixed] <tree> [--] <paths>...Libravatar Junio C Hamano1-22/+47
Sometimes it is asked on the list how to revert selected path in the index from a tree, most often HEAD, without affecting the files in the working tree. A similar operation that also affects the working tree files has been available in the form of "git checkout <tree> -- <paths>...". By definition --soft would never affect either the index nor the working tree files, and --hard is the way to make the working tree files as close to pristine, so this new option is available only for the default --mixed case. Signed-off-by: Junio C Hamano <junkio@cox.net>