aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
* git-fetch: Avoid reading packed refs over and over againJunio C Hamano2006-12-17
| | | | | | | | | | | | 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>
* markup fix in svnimport documentation.Junio C Hamano2006-12-17
| | | | Signed-off-by: Junio C Hamano <junkio@cox.net>
* Documentation: new option -P for git-svnimportQuy Tonthat2006-12-17
| | | | | | | Documentation: new option -P for git-svnimport. Signed-off-by: Quy Tonthat <qtonthat@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Fix mis-mark-up in git-merge-file.txt documentationJunio C Hamano2006-12-17
| | | | Signed-off-by: Junio C Hamano <junkio@cox.net>
* Default GIT_COMMITTER_NAME to login name in recieve-pack.Shawn O. Pearce2006-12-17
| | | | | | | | | | | | | | | | | | 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>
* Fix check_file_directory_conflict().Junio C Hamano2006-12-17
| | | | | | | | | | | | 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>
* git-add: remove conflicting entry when adding.Junio C Hamano2006-12-17
| | | | | | | | | | | | | 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>
* update-index: make D/F conflict error a bit more verbose.Junio C Hamano2006-12-17
| | | | | | | | | | | | 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>
* merge: give a bit prettier merge message to "merge branch~$n"Junio C Hamano2006-12-16
| | | | | | | 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>
* Document git-merge-fileJohannes Schindelin2006-12-16
| | | | | | | 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>
* git-clone documentationQuy Tonthat2006-12-15
| | | | | | | | 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>
* git-status always says what branch it's onAndy Parkins2006-12-15
| | | | | | | | | | | | 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>
* Align section headers of 'git status' to new 'git add'.Shawn O. Pearce2006-12-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Suggest use of "git add file1 file2" when there is nothing to commit.Shawn O. Pearce2006-12-15
| | | | | | | | | | | | | | | | | | | 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>
* Make git-diff documentation use [--] when it should.Brian Gernhardt2006-12-15
| | | | | | | | | | 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>
* Add --add option to git-repo-configBrian Gernhardt2006-12-15
| | | | | | | | | | | | | | | 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>
* Teach bash the new features of 'git show'.Shawn O. Pearce2006-12-15
| | | | | | | | | 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>
* Export PERL_PATHLuben Tuikov2006-12-15
| | | | | | | 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>
* Enable reflogs by default in any repository with a working directory.Shawn O. Pearce2006-12-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Provide more meaningful output from 'git init-db'.Shawn O. Pearce2006-12-15
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* make commit message a little more consistent and confortingNicolas Pitre2006-12-15
| | | | | | | | | | | | 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>
* Avoid accessing a slow working copy during diffcore operations.Shawn O. Pearce2006-12-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Merge branch 'js/show'Junio C Hamano2006-12-15
|\ | | | | | | | | * js/show: git-show: grok blobs, trees and tags, too
| * git-show: grok blobs, trees and tags, tooJohannes Schindelin2006-12-14
| | | | | | | | | | | | | | | | 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>
* | git-reset [--mixed] <tree> [--] <paths>...Junio C Hamano2006-12-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | git-reset: make it work from within a subdirectory.Junio C Hamano2006-12-14
| | | | | | | | | | | | | | | | | | | | | | If you typically sit in, say "src/", it's annoying to have to change directory to do a reset. This may need to be reworked when we add "git reset -- paths..." to encapsulate the "ls-tree $tree | update-index --index-info" pattern. Signed-off-by: Junio C Hamano <junkio@cox.net>
* | git-fetch: make it work from within a subdirectory.Junio C Hamano2006-12-14
|/ | | | Signed-off-by: Junio C Hamano <junkio@cox.net>
* INSTALL: no need to have GNU diff installedJohannes Schindelin2006-12-14
| | | | | | | Since a long time, we have inbuilt diff generation. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Merge branch 'maint'Junio C Hamano2006-12-14
|\ | | | | | | | | * maint: Bypass expensive content comparsion during rename detection.
| * Bypass expensive content comparsion during rename detection.Shawn O. Pearce2006-12-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When comparing file contents during the second loop through a rename detection attempt we can skip the expensive byte-by-byte comparsion if both source and destination files have valid SHA1 values. This improves performance by avoiding either an expensive open/mmap to read the working tree copy, or an expensive inflate of a blob object. Unfortunately we still have to at least initialize the sizes of the source and destination files even if the SHA1 values don't match. Failing to initialize the sizes causes a number of test cases to fail and start reporting different copy/rename behavior than was expected. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* | Update git-diff documentationJunio C Hamano2006-12-14
| | | | | | | | | | | | | | | | | | | | | | Porcelain documentation should talk in terms of end-user workflow, not in terms of implementation details. Do not suggest update-index, but git-add instead. Explain differences among 0-, 1- and 2-tree cases not as differences of number of trees given to the command, but say why user would want to give these number of trees to the command in what situation. Signed-off-by: Junio C Hamano <junkio@cox.net>
* | Merge branch 'jc/diff--cached'Junio C Hamano2006-12-13
|\ \ | | | | | | | | | | | | * jc/diff--cached: Revert "git-diff: Introduce --index and deprecate --cached."
| * | Revert "git-diff: Introduce --index and deprecate --cached."Junio C Hamano2006-12-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 4c81c213a479e4aae0653a56ad6e8db5c31f019c. Although --cached and --index are confusing wording, the use of word --cached for git-diff is consistent with git-apply. It means "work with index without looking at the working tree". We should probably come up with better wording for --cached, if somebody wants to deprecate it. But making --index and --cached synonyms for diff while leaving them mean different things for apply is no good.
* | | git-svn: allow both diff.color and color.diffJunio C Hamano2006-12-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The list concensus is to group color related configuration under "color.*" so let's be consistent. Inspired by Andy Parkins's patch to do the same for diff/log family. With fixes from Eric Wong. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
* | | repacked packs should be read-onlyNicolas Pitre2006-12-13
| | | | | | | | | | | | | | | | | | | | | ... just like the other pack creating tools do. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* | | config documentation: group color items together.Junio C Hamano2006-12-13
| | | | | | | | | | | | Signed-off-by: Junio C Hamano <junkio@cox.net>
* | | git-svn: correctly handle "(no author)" when using an authors fileEric Wong2006-12-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | The low-level parts of the SVN library return NULL/undef for author-less revisions, whereas "(no author)" is a (svn) client convention. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
* | | Merge branch 'jc/read-tree-ignore'Junio C Hamano2006-12-13
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | * jc/read-tree-ignore: read-tree: document --exclude-per-directory Loosen "working file will be lost" check in Porcelain-ish read-tree: further loosen "working file will be lost" check.
| * | | read-tree: document --exclude-per-directoryJunio C Hamano2006-12-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This documents the new option to read-tree that is used for the improved "branch switching" code. Signed-off-by: Junio C Hamano <junkio@cox.net>
| * | | Loosen "working file will be lost" check in Porcelain-ishJunio C Hamano2006-12-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This uses the previous update to read-tree in Porcelain-ish commands "git checkout" and "git merge" to loosen the check when switching branches. Signed-off-by: Junio C Hamano <junkio@cox.net>
| * | | read-tree: further loosen "working file will be lost" check.Junio C Hamano2006-12-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This follows up commit ed93b449 where we removed overcautious "working file will be lost" check. A new option "--exclude-per-directory=.gitignore" can be used to tell the "git-read-tree" command that the user does not mind losing contents in untracked files in the working tree, if they need to be overwritten by a merge (either a two-way "switch branches" merge, or a three-way merge). Signed-off-by: Junio C Hamano <junkio@cox.net>
* | | | Merge branch 'ew/rerere'Junio C Hamano2006-12-13
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * ew/rerere: rerere: record (or avoid misrecording) resolved, skipped or aborted rebase/am git-rerere: add 'gc' command. rerere: add clear, diff, and status commands
| * | | | rerere: record (or avoid misrecording) resolved, skipped or aborted rebase/amEric Wong2006-12-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Data in rr-cache isn't valid after a patch application is skipped or and aborted, so our next commit could be misrecorded as a resolution of that skipped/failed commit, which is wrong. git-am --skip, git-rebase --skip/--abort will automatically invoke git-rerere clear to avoid this. Also, since git-am --resolved indicates a resolution was succesful, remember to run git-rerere to record the resolution (and not surprise the user when the next commit is made). Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
| * | | | git-rerere: add 'gc' command.Junio C Hamano2006-12-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Over time, unresolved rr-cache entries are accumulated and they tend to get less and less likely to be useful as the tips of branches advance. Reorder documentation page to show the subcommand section earlier than the discussion section. Signed-off-by: Junio C Hamano <junkio@cox.net>
| * | | | rerere: add clear, diff, and status commandsEric Wong2006-12-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git-am and git-rebase will be updated to use 'clear', and diff/status can be used to aid the user in tracking progress in the resolution process. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
* | | | | Merge branch 'np/addcommit'Junio C Hamano2006-12-13
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * np/addcommit: git-commit: allow --only to lose what was staged earlier. Documentation/git-commit: rewrite to make it more end-user friendly. make 'git add' a first class user friendly interface to the index
| * | | | | git-commit: allow --only to lose what was staged earlier.Junio C Hamano2006-12-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The command used to have a safety valve to prevent this sequence: edit foo git update-index foo edit foo git diff foo git commit --only foo The reason for this was because an inexperienced user might mistakenly think what is shown with the last-minute diff contains all the change that is being committed (instead, what the user asked to check was an incremental diff since what has been staged so far). However, this turns out to only annoy people who know what they are doing. Inexperienced people would not be using the first "update-index" anyway, in which case they would see the full changes in the "git diff". Signed-off-by: Junio C Hamano <junkio@cox.net>
| * | | | | Documentation/git-commit: rewrite to make it more end-user friendly.Junio C Hamano2006-12-09
| | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Junio C Hamano <junkio@cox.net>
| * | | | | make 'git add' a first class user friendly interface to the indexNicolas Pitre2006-12-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This brings the power of the index up front using a proper mental model without talking about the index at all. See for example how all the technical discussion has been evacuated from the git-add man page. Any content to be committed must be added together. Whether that content comes from new files or modified files doesn't matter. You just need to "add" it, either with git-add, or by providing git-commit with -a (for already known files only of course). No need for a separate command to distinguish new vs modified files please. That would only screw the mental model everybody should have when using GIT. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* | | | | | Merge branch 'lh/branch-rename'Junio C Hamano2006-12-13
|\ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * lh/branch-rename: git-branch: let caller specify logmsg rename_ref: use lstat(2) when testing for symlink git-branch: add options and tests for branch renaming Conflicts: builtin-branch.c
generated by cgit v1.2.1 (git 2.18.0) at 2024-07-29 12:41:34 +0000