summaryrefslogtreecommitdiff
path: root/Documentation
AgeCommit message (Collapse)Author
2007-01-18Documentation: move command list in git.txt into separate files.Junio C Hamano
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-18Document --ignore-if-in-upstream in git-format-patchDavid Kågedal
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-18git-format-patch: the default suffix is now .patch, not .txtJunio C Hamano
Editors often give easier handling of patch files if the filename ends with .patch, so use it instead of .txt. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-18git-format-patch -3Junio C Hamano
This teaches "git-format-patch" to honor the --max-count parameter revision traversal machinery takes, so that you can say "git-format-patch -3" to process the three topmost commits from the current HEAD (or "git-format-patch -2 topic" to name a specific branch). Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-18Refer users to git-rev-parse for revision specification syntax.Shawn O. Pearce
The revision specification syntax (sometimes referred to as SHA1-expressions) is accepted almost everywhere in Git by almost every tool. Unfortunately it is only documented in git-rev-parse.txt, and most users don't know to look there. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-18Document the master@{n} reflog query syntax.Shawn O. Pearce
In ab2a1a32 Junio improved the reflog query logic to support obtaining the n-th prior value of a ref, but this was never documented in git-rev-parse. Now it is. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-17Documentation/git-parse-remote.txt: we deal with config vars as wellJunio C Hamano
... but we never documented it. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-17Documentation: m can be relative in "git-blame -Ln,m"Junio C Hamano
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-17Documentation: suggest corresponding Porcelain-level in plumbing docs.Junio C Hamano
Instead of keeping the confused end user reading low-level documentation, suggest the higher level commands that implement what the user may want to do using them upfront. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-17Documentation/git-resolve: deprecated.Junio C Hamano
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-17sanitize content of README fileNicolas Pitre
Current README content is way too esoteric for someone looking at GIT for the first time. Instead it should provide a quick summary of what GIT is with a few pointers to other resources. The bulk of the previous README content is moved to Documentation/core-intro.txt. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-17Introduce 'git-format-patch --suffix=.patch'Junio C Hamano
The default can also be changed with "format.suffix" configuration. Leaving it empty would not add any suffix. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-17Documentation/glossary.txt: describe remotes/ tracking and packed-refsJunio C Hamano
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-17Documentation/glossary.txt: unpacked objects are loose.Junio C Hamano
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-17Documentation: describe shallow repositoryJunio C Hamano
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-17Make a short-and-sweet "git-add -i" synonym for "git-add --interactive"Junio C Hamano
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-17Documentation: detached HEADJunio C Hamano
Add discussion section to git-checkout documentation and mention detached HEAD in repository-layout document. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-17Documentation: a few spelling fixesRené Scharfe
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-17Documentation/git-sh-setup.txt: programmer's docsJunio C Hamano
Clarify that this is not meant for end users, and list what shell functions are defined. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-17Documentation/git-whatchanged.txt: show -<n> instead of --max-count.Junio C Hamano
... to match the change we did earlier to git-log documentation. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-17Documentation/git-status.txt: mention color configurationJunio C Hamano
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-17Documentation/git-tar-tree.txt: default umask is now 002Junio C Hamano
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-17Documentation/git-tools.txt: mention tig and refer to wikiJunio C Hamano
In general list at Wiki seems to be maintained a lot better than this list. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-17Documentation/git-tag: the command can be used to also verify a tag.Junio C Hamano
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-17Documentation/SubmittingPatches: Gnus tipsJunio C Hamano
Also warn about format=flowed (aka 'flawed'). Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-17git-commit: document log message formatting conventionJunio C Hamano
Take it from the tutorial, since not everybody necessarily reads it. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-17Document where configuration files are in config.txtJunio C Hamano
Talking about what the files contain without talking about where they are does not help new users. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-17git-commit documentation: remove comment on unfixed git-rmJunio C Hamano
... which was fixed since then. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-17tutorial: shorthand for remotes but show distributed nature of gitJunio C Hamano
* Promiscous pull shows the distributed nature of git better. * Add a new step after that to teach "remote add". * Highlight that with the shorthand defined you will get remote tracking branches for free. * Fix Alice's workflow. Signed-off-by: Santi Béjar <sbejar@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-17tutorial: Use only separate layoutSanti Béjar
Then the newbies only have to understand one layout. Signed-off-by: Santi Béjar <sbejar@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-16git-rm documentation: remove broken behaviour from the example.Junio C Hamano
The example section were talking about the old broken default behaviour. Correct it. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-16git-push documentation: remaining bitsJunio C Hamano
Mention --thin, --no-thin, --repo and -v. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-16document --exec for git-pushUwe Kleine-K,Av(Bnig
The text is just copied from git-send-pack.txt. Signed-off-by: Uwe Kleine-K,Av(Bnig <zeisberg@informatik.uni-freiburg.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-15git-pull: disallow implicit merging to detached HEADJeff King
Instead, we complain to the user and suggest that they explicitly specify the remote and branch. We depend on the exit status of git-symbolic-ref, so let's go ahead and document that. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-15Fix git-fetch while on detached HEAD not to give needlessly alarming errorsJunio C Hamano
When we are on a detached HEAD, there is no current branch. There is no reason to leak the error messages to the end user since this is a situation we expect to see. This adds -q option to git-symbolic-ref to exit without issuing an error message if the given name is not a symbolic ref. By the way, with or without this patch, there currently is no good way to tell failure modes between "git symbolic-ref HAED" and "git symbolic-ref HEAD". Both says "is not a symbolic ref". We may want to do something about it. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-15git reflog expire: document --stale-fix option.Junio C Hamano
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-15Documentation: merge-output is not too verbose now.Junio C Hamano
We've squelched output from merge-recursive, and git-merge when used with recursive does not attempt the trivial one first anymore, so there won't be "Trying ... Nope." messages now. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-15Improve git-describe performance by reducing revision listing.Shawn O. Pearce
My prior version of git-describe ran very slowly on even reasonably sized projects like git.git and linux.git as it tended to identify a large number of possible tags and then needed to generate the revision list for each of those tags to sort them and select the best tag to describe the input commit. All we really need is the number of commits in the input revision which are not in the tag. We can generate these counts during the revision walking and tag matching loop by assigning a color to each tag and coloring the commits as we walk them. This limits us to identifying no more than 26 possible tags, as there is limited space available within the flags field of struct commit. The limitation of 26 possible tags is hopefully not going to be a problem in real usage, as most projects won't create 26 maintenance releases and merge them back into a development trunk after the development trunk was tagged with a release candidate tag. If that does occur git-describe will start to revert to its old behavior of using the newer maintenance release tag to describe the development trunk, rather than the development trunk's own tag. The suggested workaround would be to retag the development trunk's tip. However since even 26 possible tags can take a while to generate a description for on some projects I'm defaulting the limit to 10 but offering the user --candidates to increase the number of possible matches if they need a more accurate result. I specifically chose 10 for the default as it seems unlikely projects will have more than 10 maintenance releases merged into a development trunk before retagging the development trunk, and it seems to perform about the same on linux.git as v1.4.4.4 git-describe. A large amount of debugging information was also added during the development of this change, so I've left it in to be toggled on with --debug. It may be useful to the end user to help them understand why git-describe took one particular tag over another. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-15some doc updatesNicolas Pitre
1) talk about "git merge" instead of "git pull ." 2) suggest "git repo-config" instead of directly editing config files 3) echo "URL: blah" > .git/remotes/foo is obsolete and should be "git repo-config remote.foo.url blah" 4) support for partial URL prefix has been removed (see commit ea560e6d64374ec1f6c163c276319a3da21a1345) so drop mention of it. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-15git log documentation: teach -<n> form.Junio C Hamano
We say "this shows only the most often used ones"; so instead of teaching --max-number=<n> form, list -<n> form which is much easier to type. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-14Allow the user to control the verbosity of merge-recursive.Shawn O. Pearce
Junio C Hamano <junkio@cox.net> writes: > > I think the output from merge-recursive can be categorized into 5 > verbosity levels: > > 1. "CONFLICT", "Rename", "Adding here instead due to D/F conflict" > (outermost) > > 2. "Auto-merged successfully" (outermost) > > 3. The first "Merging X with Y". > > 4. outermost "Merging:\ntitle1\ntitle2". > > 5. outermost "found N common ancestors\nancestor1\nancestor2\n..." > and anything from inner merge. > > I would prefer the default verbosity level to be 2 (that is, show > both 1 and 2). and this change makes it so. I think level 3 is probably pointless as its only one line of output above level 2, but I can see how some users may want to view it but not view the slightly more verbose output of level 4. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-13git-commit documentation: -a adds and also removesJunio C Hamano
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-12Make git-prune-packed a bit more chatty.Junio C Hamano
Steven Grimm noticed that git-repack's verbosity is inconsistent because pack-objects is chatty and prune-packed is not. This makes the latter a bit more chatty and gives -q option to squelch it. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-12glossary typofixJunio C Hamano
Pointed out by Paul Witt <paul.witt@oxix.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-12use 'init' instead of 'init-db' for shipped docs and toolsNicolas Pitre
While 'init-db' still is and probably will always remain a valid git command for obvious backward compatibility reasons, it would be a good idea to move shipped tools and docs to using 'init' instead. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-12fix documentation for git-commit --no-verifyMichael S. Tsirkin
Despite what the documentation claims, git-commit does not check commit for suspicious lines: all hooks are disabled by default, and the pre-comit hook could be changed to do something else. Signed-off-by: Michael S. Tsirkin <mst@mellanox.co.il> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-11Document git-initJunio C Hamano
These days, the command does a lot more than just initialise the object database (such as setting default config-variables, installing template hooks...), and "git init" is actually a more sensible name nowadays. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-10Add git-init documentation.Nicolas Pitre
Oops. Commit 515377ea9ec6192f82a2fa5c5b5b7651d9d6cf6c missed one file, git-init documentation. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-10-u is now default for 'git-mailinfo'.Junio C Hamano
Originally from David Woodhouse, but also adjusts the callers of mailinfo to the new default. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-10-u is now default for 'git-applymbox'Junio C Hamano
It has '-n' to disable it just in case, but do not even bother documenting it. Signed-off-by: Junio C Hamano <junkio@cox.net>