aboutsummaryrefslogtreecommitdiff
path: root/Documentation
Commit message (Collapse)AuthorAge
* Let git-svnimport's author file use same syntax as git-cvsimport'sKarl Hasselström2006-02-27
| | | | | | | | | | | | | git-cvsimport uses a username => Full Name <email@addr.es> mapping file with this syntax: kha=Karl Hasselström <kha@treskal.com> Since there is no reason to use another format for git-svnimport, use the same format. Signed-off-by: Karl Hasselström <kha@treskal.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
* svnimport: Read author names and emails from a fileKarl Hasselström2006-02-26
| | | | | | | | | | | | | Read a file with lines on the form username User's Full Name <email@addres.org> and use "User's Full Name <email@addres.org>" as the GIT author and committer for Subversion commits made by "username". If encountering a commit made by a user not in the list, abort. Signed-off-by: Karl Hasselström <kha@treskal.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
* svnimport: Convert the svn:ignore propertyKarl Hasselström2006-02-26
| | | | | | | | | | Put the value of the svn:ignore property in a regular file when converting a Subversion repository to GIT. The Subversion and GIT ignore syntaxes are similar enough that it often just works to set the filename to .gitignore and do nothing else. Signed-off-by: Karl Hasselström <kha@treskal.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
* svnimport: Mention -r in usage summaryKarl Hasselström2006-02-26
| | | | | | | | I added the -r option to git-svnimport some time ago, but forgot to update the usage summary in the documentation. Signed-off-by: Karl Hasselström <kha@treskal.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Merge branch 'ml/cvs'Junio C Hamano2006-02-22
|\ | | | | | | | | * ml/cvs: Introducing git-cvsserver -- a CVS emulator for git.
| * Introducing git-cvsserver -- a CVS emulator for git.Martin Langhoff2006-02-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git-cvsserver is highly functional. However, not all methods are implemented, and for those methods that are implemented, not all switches are implemented. All the common read operations are implemented, and add/remove/commit are supported. Testing has been done using both the CLI CVS client, and the Eclipse CVS plugin. Most functionality works fine with both of these clients. Currently git-cvsserver only works over SSH connections, see the Documentation for more details on how to configure your client. It does not support pserver for anonymous access but it should not be hard to implement. Anonymous access will need tighter input validation. In our very informal tests, it seems to be significantly faster than a real CVS server. This utility depends on a version of git-cvsannotate that supports -S and on DBD::SQLite. Licensed under GPLv2. Copyright The Open University UK. Authors: Martyn Smith <martyn@catalyst.net.nz> Martin Langhoff <martin@catalyst.net.nz> Signed-off-by: Martin Langhoff <martin@catalyst.net.nz> Signed-off-by: Junio C Hamano <junkio@cox.net>
* | Add new git-rm command with documentationCarl Worth2006-02-22
|/ | | | | | | | | | | | | | This adds a git-rm command which provides convenience similar to git-add, (and a bit more since it takes care of the rm as well if given -f). Like git-add, git-rm expands the given path names through git-ls-files. This means it only acts on files listed in the index. And it does act recursively on directories by default, (no -r needed as in the case of rm itself). When it recurses, it does not remove empty directories that are left behind. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Merge branch 'fix'Junio C Hamano2006-02-22
|\ | | | | | | | | | | | | * fix: git-push: Update documentation to describe the no-refspec behavior. format-patch: pretty-print timestamp correctly. git-add: Add support for --, documentation, and test.
| * git-push: Update documentation to describe the no-refspec behavior.Carl Worth2006-02-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It turns out that the git-push documentation didn't describe what it would do when not given a refspec, (not on the command line, nor in a remotes file). This is fairly important for the user who is trying to understand operations such as: git clone git://something/some/where # hack, hack, hack git push origin I tracked the mystery behavior down to git-send-pack and lifted the relevant portion of its documentation up to git-push, (namely that all refs existing both locally and remotely are updated). Signed-off-by: Carl Worth <cworth@cworth.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
| * git-add: Add support for --, documentation, and test.Carl Worth2006-02-21
| | | | | | | | | | | | | | | | | | | | | | This adds support to git-add to allow the common -- to separate command-line options and file names. It adds documentation and a new git-add test case as well. [jc: this should apply to 1.2.X maintenance series, so I reworked git-ls-files --error-unmatch test. ] Signed-off-by: Junio C Hamano <junkio@cox.net>
* | Merge branch 'jc/pack-reuse'Junio C Hamano2006-02-21
|\ \ | | | | | | | | | | | | | | | | | | | | | * jc/pack-reuse: pack-objects: avoid delta chains that are too long. git-repack: allow passing a couple of flags to pack-objects. pack-objects: finishing touches. pack-objects: reuse data from existing packs.
| * | git-repack: allow passing a couple of flags to pack-objects.Junio C Hamano2006-02-17
| | | | | | | | | | | | | | | | | | | | | A new flag -q makes underlying pack-objects less chatty. A new flag -f forces delta to be recomputed from scratch. Signed-off-by: Junio C Hamano <junkio@cox.net>
| * | pack-objects: finishing touches.Junio C Hamano2006-02-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This introduces --no-reuse-delta option to disable reusing of existing delta, which is a large part of the optimization introduced by this series. This may become necessary if repeated repacking makes delta chain too long. With this, the output of the command becomes identical to that of the older implementation. But the performance suffers greatly. It still allows reusing non-deltified representations; there is no point uncompressing and recompressing the whole text. It also adds a couple more statistics output, while squelching it under -q flag, which the last round forgot to do. $ time old-git-pack-objects --stdout >/dev/null <RL Generating pack... Done counting 184141 objects. Packing 184141 objects.................... real 12m8.530s user 11m1.450s sys 0m57.920s $ time git-pack-objects --stdout >/dev/null <RL Generating pack... Done counting 184141 objects. Packing 184141 objects..................... Total 184141, written 184141 (delta 138297), reused 178833 (delta 134081) real 0m59.549s user 0m56.670s sys 0m2.400s $ time git-pack-objects --stdout --no-reuse-delta >/dev/null <RL Generating pack... Done counting 184141 objects. Packing 184141 objects..................... Total 184141, written 184141 (delta 134833), reused 47904 (delta 0) real 11m13.830s user 9m45.240s sys 0m44.330s There is one remaining issue when --no-reuse-delta option is not used. It can create delta chains that are deeper than specified. A<--B<--C<--D E F G Suppose we have a delta chain A to D (A is stored in full either in a pack or as a loose object. B is depth1 delta relative to A, C is depth2 delta relative to B...) with loose objects E, F, G. And we are going to pack all of them. B, C and D are left as delta against A, B and C respectively. So A, E, F, and G are examined for deltification, and let's say we decided to keep E expanded, and store the rest as deltas like this: E<--F<--G<--A Oops. We ended up making D a bit too deep, didn't we? B, C and D form a chain on top of A! This is because we did not know what the final depth of A would be, when we checked objects and decided to keep the existing delta. Unfortunately, deferring the decision until just before the deltification is not an option. To be able to make B, C, and D candidates for deltification with the rest, we need to know the type and final unexpanded size of them, but the major part of the optimization comes from the fact that we do not read the delta data to do so -- getting the final size is quite an expensive operation. To prevent this from happening, we should keep A from being deltified. But how would we tell that, cheaply? To do this most precisely, after check_object() runs, each object that is used as the base object of some existing delta needs to be marked with the maximum depth of the objects we decided to keep deltified (in this case, D is depth 3 relative to A, so if no other delta chain that is longer than 3 based on A exists, mark A with 3). Then when attempting to deltify A, we would take that number into account to see if the final delta chain that leads to D becomes too deep. However, this is a bit cumbersome to compute, so we would cheat and reduce the maximum depth for A arbitrarily to depth/4 in this implementation. Signed-off-by: Junio C Hamano <junkio@cox.net>
* | | Merge branch 'jc/nostat'Junio C Hamano2006-02-21
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * jc/nostat: cache_name_compare() compares name and stage, nothing else. "assume unchanged" git: documentation. ls-files: split "show-valid-bit" into a different option. "Assume unchanged" git: --really-refresh fix. ls-files: debugging aid for CE_VALID changes. "Assume unchanged" git: do not set CE_VALID with --refresh "Assume unchanged" git
| * | | "assume unchanged" git: documentation.Junio C Hamano2006-02-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This updates documentation to describe the "assume unchanged" behaviour. Signed-off-by: Junio C Hamano <junkio@cox.net>
* | | | git-ls-files: Fix, document, and add test for --error-unmatch option.Carl Worth2006-02-21
| | | | | | | | | | | | | | | | Signed-off-by: Junio C Hamano <junkio@cox.net>
* | | | git-rebase: Clarify usage statement and copy it into the actual documentation.Carl Worth2006-02-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I found a paper thin man page for git-rebase, but was quite happy to see something much more useful in the usage statement of the script when I went there to find out how this thing worked. Here it is cleaned up slightly and expanded a bit into the actual documentation. Signed-off-by: Carl Worth <cworth@cworth.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* | | | Documentation: fix typo in rev-parse --short option description.Junio C Hamano2006-02-19
| | | | | | | | | | | | | | | | Signed-off-by: Junio C Hamano <junkio@cox.net>
* | | | Merge fixes up to GIT 1.2.2Junio C Hamano2006-02-18
|\ \ \ \ | | |_|/ | |/| |
| * | | Document --short and --git-dir in git-rev-parse(1)Jonas Fonseca2006-02-17
| | | | | | | | | | | | | | | | Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
* | | | SubmittingPatches: note on whitespacesJunio C Hamano2006-02-17
| | | | | | | | | | | | | | | | Signed-off-by: Junio C Hamano <junkio@cox.net>
* | | | git-tag: -l to list tags (usability).Junio C Hamano2006-02-17
| |_|/ |/| | | | | | | | | | | | | | | | | git-tag -l lists all tags, and git-tag -l <pattern> filters the result with <pattern>. Signed-off-by: Junio C Hamano <junkio@cox.net>
* | | Merge branch 'kh/svn'Junio C Hamano2006-02-14
|\ \ \ | | | | | | | | | | | | | | | | * kh/svn: git-svnimport: -r adds svn revision number to commit messages
| * | | git-svnimport: -r adds svn revision number to commit messagesKarl Hasselström2006-02-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | New -r flag for prepending the corresponding Subversion revision number to each commit message. Signed-off-by: Karl Hasselström <kha@treskal.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
* | | | Merge branch 'ra/email'Junio C Hamano2006-02-14
|\ \ \ \ | |/ / / |/| | | | | | | | | | | | | | | * ra/email: send-email: Add --cc send-email: Add some options for controlling how addresses are automatically added to the cc: list.
| * | | send-email: Add --ccRyan Anderson2006-02-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Since Junio used this in an example, and I've personally tried to use it, I suppose the option should actually exist. Signed-off-by: Ryan Anderson <ryan@michonline.com>
| * | | send-email: Add some options for controlling how addresses are automatically ↵Ryan Anderson2006-02-13
| | | | | | | | | | | | | | | | | | | | | | | | added to the cc: list. Signed-off-by: Ryan Anderson <ryan@michonline.com>
* | | | Merge some proposed fixesJunio C Hamano2006-02-13
|\ \ \ \ | | |/ / | |/| | | | | | | | | | | | | | | | | | | | | | Conflicts: Documentation/git-commit.txt - taking the post 1.2.0 semantics. Signed-off-by: Junio C Hamano <junkio@cox.net>
| * | | Documentation: git-ls-files asciidocco.Junio C Hamano2006-02-13
| | | | | | | | | | | | | | | | | | | | | | | | Noticed by Jon Nelson. Signed-off-by: Junio C Hamano <junkio@cox.net>
| * | | Documentation: git-commit in 1.2.X series defaults to --include.Junio C Hamano2006-02-13
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | The documentation was mistakenly describing the --only semantics to be default. The 1.2.0 release and its maintenance series 1.2.X will keep the traditional --include semantics as the default. Clarify the situation. Signed-off-by: Junio C Hamano <junkio@cox.net>
* | | git-commit: Now --only semantics is the default.Junio C Hamano2006-02-12
|/ / | | | | | | | | | | | | | | This changes the "git commit paths..." to default to --only semantics from traditional --include semantics, as agreed on the list. Signed-off-by: Junio C Hamano <junkio@cox.net>
* | Add howto about separating topics.kent@lysator.liu.se2006-02-12
| | | | | | | | | | | | | | | | This howto consists of a footnote from an email by JC to the git mailing list (<7vfyms0x4p.fsf@assigned-by-dhcp.cox.net>). Signed-off-by: Kent Engstrom <kent@lysator.liu.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
* | Add support for explicit type specifiers when calling git-repo-configPetr Baudis2006-02-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, git-repo-config will just return the raw value of option as specified in the config file; this makes things difficult for scripts calling it, especially if the value is supposed to be boolean. This patch makes it possible to ask git-repo-config to check if the option is of the given type (int or bool) and write out the value in its canonical form. If you do not pass --int or --bool, the behaviour stays unchanged and the raw value is emitted. This also incidentally fixes the segfault when option with no value is encountered. [jc: tweaked the option parsing a bit to make it easier to see that the patch does not change anything but the type stuff in the diff output. Also changed to avoid "foo ? : bar" construct. ] Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>
* | Add --diff-filter= documentation paragraphJon Loeliger2006-02-09
|/ | | | | Signed-off-by: Jon Loeliger <jdl@jdl.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Basic documentation for git-showPetr Baudis2006-02-07
| | | | | Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Document git-diff-tree --alwaysPetr Baudis2006-02-07
| | | | | Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>
* format-patch: Remove last vestiges of --mbox optionAndreas Ericsson2006-02-07
| | | | | | | | | | | | Don't mention it in docs or --help output. Remove mbox, date and author variables from git-format-patch.sh. Use DESCRIPTION text from man-page to update LONG_USAGE output. It's a bit silly to have two texts saying the same thing in different words, and I'm too lazy to update both. Signed-off-by: Andreas Ericsson <ae@op5.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-commit: revamp the git-commit semantics.Junio C Hamano2006-02-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - "git commit" without _any_ parameter keeps the traditional behaviour. It commits the current index. We commit the whole index even when this form is run from a subdirectory. - "git commit --include paths..." (or "git commit -i paths...") is equivalent to: git update-index --remove paths... git commit - "git commit paths..." acquires a new semantics. This is an incompatible change that needs user training, which I am still a bit reluctant to swallow, but enough people seem to have complained that it is confusing to them. It 1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds trained git users that the traditional semantics now needs -i flag. 2. refuses to run if named paths... are different in HEAD and the index (ditto about reminding). Added paths are OK. 3. reads HEAD commit into a temporary index file. 4. updates named paths... from the working tree in this temporary index. 5. does the same updates of the paths... from the working tree to the real index. 6. makes a commit using the temporary index that has the current HEAD as the parent, and updates the HEAD with this new commit. - "git commit --all" can run from a subdirectory, but it updates the index with all the modified files and does a whole tree commit. - In all cases, when the command decides not to create a new commit, the index is left as it was before the command is run. This means that the two "git diff" in the following sequence: $ git diff $ git commit -a $ git diff would show the same diff if you abort the commit process by making the commit log message empty. This commit also introduces much requested --author option. $ git commit --author 'A U Thor <author@example.com>' Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-rerere: reuse recorded resolve.Junio C Hamano2006-02-06
| | | | | | | | | | | | | | | In a workflow that employs relatively long lived topic branches, the developer sometimes needs to resolve the same conflict over and over again until the topic branches are done (either merged to the "release" branch, or sent out and accepted upstream). This commit introduces a new command, "git rerere", to help this process by recording the conflicted automerge results and corresponding hand-resolve results on the initial manual merge, and later by noticing the same conflicted automerge and applying the previously recorded hand resolution using three-way merge. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Docs: minor git-push copyeditingJ. Bruce Fields2006-02-06
| | | | | | | Minor git-push copyediting Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Docs: move git url and remotes text to separate sectionsJ. Bruce Fields2006-02-06
| | | | | | | | | The sections on git urls and remotes files in the git-fetch, git-pull, and git-push manpages seem long enough to be worth a manpage section of their own. Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Docs: split up pull-fetch-param.txtJ. Bruce Fields2006-02-06
| | | | | | | | | | | | | | | | The push and pull man pages include a bunch of shared text from pull-fetch-param.txt. This simplifies maintenance somewhat, but there's actually quite a bit of text that applies only to one or the other. So, separate out the push- and pull/fetch-specific text into pull-fetch-param.txt and git-push.txt, then include the largest chunk of common stuff (the description of protocols and url's) from urls.txt. That cuts some irrelevant stuff from the man pages without making us duplicate too much. Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: Junio C Hamano <junkio@cox.net>
* core-tutorial: adjust to recent reality.Junio C Hamano2006-02-06
| | | | | | | | | | We still talked about HEAD symlinks but these days we use symrefs by default. Also 'failed/prevented' message is now gone from the merge output. Signed-off-by: Junio C Hamano <junkio@cox.net>
*-. Merge branches 'jc/daemon' and 'mw/http'Junio C Hamano2006-02-05
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * jc/daemon: daemon: extend user-relative path notation. daemon: Set SO_REUSEADDR on listening sockets. daemon: do not forbid user relative paths unconditionally under --base-path * mw/http: http-fetch: Tidy control flow in process_alternate_response http: Turn on verbose Curl messages if GIT_CURL_VERBOSE set in environment http-fetch: Fix message reporting rename of object file. http-fetch: Fix object list corruption in fill_active_slots().
| * | daemon: extend user-relative path notation.Junio C Hamano2006-02-05
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Earlier, we made --base-path to automatically forbid user-relative paths, which was probably a mistake. This introduces --user-path (or --user-path=path) option to control the use of user-relative paths independently. The latter form of the option can be used to restrict accesses to a part of each user's home directory, similar to "public_html" some webservers supports. If we're invoked with --user-path=FOO option, then a URL of the form git://~USER/PATH/... resolves to the path HOME/FOO/PATH/..., where HOME is USER's home directory. [jc: This is much reworked by me so bugs are mine, but the original patch was done by Mark Wooding.] Signed-off-by: Junio C Hamano <junkio@cox.net>
* | git-send-email: Fully implement --quiet and document it.Ryan Anderson2006-02-05
|/ | | | | | | Also reorganizes the man page to list options alphabetically. Signed-off-by: Ryan Anderson <ryan@michonline.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Documentation: git-diff-tree --cc also omits empty commitsJunio C Hamano2006-02-02
| | | | | | | | | | | A misguided attempt to show logs at all time was inserted only to the documentation of this flag. Worse yet, it was not even implemented, causing more confusion. Drop it. We might want to have an option to show --pretty even when there is no diff output, but that is applicable to all forms of diff, not just --cc. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Make apply accept the -pNUM option like patch does.Daniel Barkalow2006-01-31
| | | | | | | This only applies to traditional diffs, not to git diffs. Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* documentation: cvs migration - typofix.Junio C Hamano2006-01-30
| | | | Signed-off-by: Junio C Hamano <junkio@cox.net>
* cvs-migration documentation updateJ. Bruce Fields2006-01-30
| | | | | | | | | | | | | | | | | | | | | | | Here's some changes to the cvs-migration.txt. As usual, in my attempt to make things clearer someone may have found I've made them less so, or I may have just gotten something wrong; so any review is welcomed. I can break up this sort of thing into smaller steps if preferred, the monolothic patch is just a bit simpler for me for this sort of thing. I moved the material describing shared repository management from core-tutorial.txt to cvs-migration.txt, where it seems more appropriate, and combined two sections to eliminate some redundancy. I also revised the earlier sections of cvs-migration.txt, mainly trying to make it more concise. I've left the last section of cvs-migration.txt (on CVS annotate alternatives) alone for now. Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: Junio C Hamano <junkio@cox.net>
generated by cgit v1.2.1 (git 2.18.0) at 2025-01-07 13:01:34 +0000