summaryrefslogtreecommitdiff
path: root/Documentation
AgeCommit message (Collapse)AuthorFilesLines
2007-02-05Show an example of deleting commits with git-rebase.Libravatar Shawn O. Pearce1-2/+25
This particular use of git-rebase to remove a single commit or a range of commits from the history of a branch recently came up on the mailing list. Documenting the example should help other users arrive at the same solution on their own. It also was not obvious to the newcomer that git-rebase is able to accept any commit for --onto <newbase> and <upstream>. We should at least minimally document this, as much of the language in git-rebase's manpage refers to 'branch' rather than 'committish'. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-05git-for-each-ref doesn't return "the bit after $GIT_DIR/refs"Libravatar Andy Parkins1-1/+1
The documentation for git-for-each-ref said that the refname variable would return "the part after $GIT_DIR/refs/", which isn't true. Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-04Merge branch 'np/dreflog'Libravatar Junio C Hamano2-4/+10
* np/dreflog: show-branch -g: default to the current branch. Let git-checkout always drop any detached head Enable HEAD@{...} and make it independent from the current branch scan reflogs independently from refs add reflog when moving HEAD to a new branch create_symref(): do not assume pathname from git_path() persists long enough add logref support to git-symbolic-ref move create_symref() past log_ref_write() add reflog entries for HEAD when detached enable separate reflog for HEAD lock_ref_sha1_basic(): remember the original name of a ref when resolving it make reflog filename independent from struct ref_lock
2007-02-04Why is it bad to rewind a branch that has already been pushed out?Libravatar Robin Rosenberg1-0/+2
Mention git-revert as an alternative to git-reset to revert changes. Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-03show-branch -g: default to the current branch.Libravatar Junio C Hamano1-3/+5
Now we have a separate reflog on HEAD, show-branch -g without an explicit parameter defaults to the current branch, or HEAD when it is detached from branches. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-03Merge branch 'master' into np/dreflogLibravatar Junio C Hamano34-440/+3832
This is to resolve conflicts early in preparation for possible inclusion of "reflog on detached HEAD" series by Nico, as having it in 1.5.0 would really help us remove confusion between detached and attached states. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-03Assorted typo fixesLibravatar Pavel Roskin6-10/+10
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-03Cleanup subcommand documentation for git-remote.Libravatar Shawn O. Pearce1-4/+19
Jakub Narebski pointed out the positional notation in git-remote's documentation was very confusing, especially now that we have 3 supported subcommands. Instead of referring to subcommands by position, refer to them by name. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-03Why is it bad to rewind a branch that has already been pushed out?Libravatar Junio C Hamano1-3/+3
I was reading the tutorial and noticed that we say this: Also, don't use "git reset" on a publicly-visible branch that other developers pull from, as git will be confused by history that disappears in this way. I do not think this is a good explanation. For example, if we do this: (1) I build a series and push it out. ---o---o---o---j (2) Alice clones from me, and builds two commits on top of it. ---o---o---o---j---a---a (3) I rewind one and build a few, and push them out. ---o---o---o...j \ h---h---h---h (4) Alice pulls from me again: ---o---o---o---j---a---a---* \ / h---h---h---h Contrary to the description, git will happily have Alice merge between the two branches, and never gets confused. Maybe I did not want to have 'j' because it was an incomplete solution to some problem, and Alice may have fixed it up with her changes, while I abandoned that approach I started with 'j', and worked on something completely unrelated in the four 'h' commits. In such a case, the merge Alice would make would be very sensible, and after she makes the merge if I pull from her, the world will be perfect. I started something with 'j' and dropped the ball, Alice picked it up and perfected it while I went on to work on something else with 'h'. This would be a perfect example of distributed parallel collaboration. There is nothing confused about it. The case the rewinding becomes problematic is if the work done in 'h' tries to solve the same problem as 'j' tried to solve in a different way. Then the merge forced on Alice would make her pick between my previous attempt with her fixups (j+a) and my second attempt (h). If 'a' commits were to fix up what 'j' started, presumably Alice already studied and knows enough about the problem so she should be able to make an informed decision to pick between what 'j+a' and 'h' do. A lot worse case is if Alice's work is not at all related to what 'j' wanted to do (she did not mean to pick up from where I left off -- she just wanted to work on something different). Then she would not be familiar enough with what 'j' and 'h' tried to achieve, and I'd be forcing her to pick between the two. Of course if she can make the right decision, then again that is a perfect example of distributed collaboration, but that does not change the fact that I'd be forcing her to clean up my mess. Signed-off-by: Junio C Hamano <junkio@cox.net>
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-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-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-01Teach 'git remote' how to cleanup stale tracking branches.Libravatar Shawn O. Pearce1-0/+5
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-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-01add a quiet option to git-checkoutLibravatar Nicolas Pitre1-1/+4
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-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-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-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-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>
2007-01-29user-manual: minor "TODO" updatesLibravatar J. Bruce Fields1-9/+6
I still really want a section on interoperability with CVS, subversion, etc., but I'm not getting around to it very fast, so just add this to the TODO section for now. And a few other minor todo updates. Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
2007-01-29user-manual: rewrap a few long linesLibravatar J. Bruce Fields1-56/+59
Rewrap some long lines. Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
2007-01-29user-manual: reflogs, other recoveryLibravatar J. Bruce Fields1-15/+78
Add a brief discussion of reflogs. Also recovery of dangling commits seems to fit in here, so move some of the discussion out of Linus's email to here. Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
2007-01-29user-manual: fix a header levelLibravatar J. Bruce Fields1-1/+1
Oops. Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
2007-01-29user-manual: typo fixLibravatar J. Bruce Fields1-1/+1
Oops Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
2007-01-29user-manual: add references to git-config man pageLibravatar J. Bruce Fields1-3/+7
Direct editing of config files may be more natural for users than using the git-config commandline; but we should still reference the git-config man page when we describe such editing, so people know where to go for details on the config file syntax and meanings of the variables. Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
2007-01-28user-manual: repo-config -> configLibravatar J. Bruce Fields1-9/+9
Looks like we're going to allow git-config as the preferred alias to git-repo-config, so let's document that instead. Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
2007-01-28user-manual: fsck-objects -> fsckLibravatar J. Bruce Fields1-8/+8
There seems to be an agreement to rename fsck-objects to fsck. Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
2007-01-28user-manual: git-fsck, dangling objectsLibravatar J. Bruce Fields1-6/+118
Initial import of fsck and dangling objects discussion, mostly lifted from an email from Linus. Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
2007-01-28git-fsck-objects is now synonym to git-fsckLibravatar Junio C Hamano7-131/+148
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-28[PATCH] Rename git-repo-config to git-config.Libravatar Tom Prince15-244/+262
Signed-off-by: Tom Prince <tom.prince@ualberta.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-28Teach for-each-ref about a little language called Tcl.Libravatar Shawn O. Pearce1-2/+2
Love it or hate it, some people actually still program in Tcl. Some of those programs are meant for interfacing with Git. Programs such as gitk and git-gui. It may be useful to have Tcl-safe output available from for-each-ref, just like shell, Perl and Python already enjoy. Thanks to Sergey Vlasov for pointing out the horrible flaws in the first and second version of this patch, and steering me in the right direction for Tcl value quoting. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-28Document 'git-blame --incremental'Libravatar Junio C Hamano1-1/+46
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-28Documentation/config.txt: Fix documentation of colour config tweaks.Libravatar Mark Wooding1-10/+16
* The description of valid colour specifications was rather incomplete, so fix it so that it actually describes colour specs as accepted by color_parse(). * The list of colour items allowed in color.diff.BLAH was missing the `commit' and `whitespace' entries. Signed-off-by: Mark Wooding <mdw@distorted.org.uk> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-28add logref support to git-symbolic-refLibravatar Nicolas Pitre1-1/+5
Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-28Update describe documentation.Libravatar Junio C Hamano1-9/+22
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-27Document --check option to git diff.Libravatar Bill Lear2-1/+6
Signed-off-by: Bill Lear <rael@zopyra.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-27Allow the tag signing key to be specified in the config fileLibravatar Andy Parkins2-0/+17
I did this: $ git tag -s test-sign gpg: skipped "Andy Parkins <andyparkins@gmail.com>": secret key not available gpg: signing failed: secret key not available failed to sign the tag with GPG. The problem is that I have used the comment field in my key's UID definition. $ gpg --list-keys andy pub 1024D/4F712F6D 2003-08-14 uid Andy Parkins (Google) <andyparkins@gmail.com> So when git-tag looks for "Andy Parkins <andyparkins@gmail.com>"; obviously it's not going to be found. There shouldn't be a requirement that I use the same form of my name in my git repository and my gpg key - I might want to be formal (Andrew) in my gpg key and informal (Andy) in the repository. Further I might have multiple keys in my keyring, and might want to use one that doesn't match up with the address I use in commit messages. This patch adds a configuration entry "user.signingkey" which, if present, will be passed to the "-u" switch for gpg, allowing the tag signing key to be overridden. If the entry is not present, the fallback is the original method, which means existing behaviour will continue untouched. Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-27user-manual: reorganize fetch discussion, add internals, etc.Libravatar J. Bruce Fields1-204/+954
Keep git remote discussion in the first chapter, but postpone lower-level git fetch usage (to fetch individual branches) till later. Import a bunch of slightly modified text from the readme to give an architectural overview at the end. Add more discussion of history rewriting. And a bunch of other miscellaneous changes.... Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
2007-01-26Documentation: pack-refs --all vs default behaviourLibravatar Junio C Hamano1-1/+12
Document the recommended way to prime a repository with tons of references with 'pack-refs --all -prune'. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-25Add dangling objects tips.Libravatar Linus Torvalds1-0/+109
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-26user-manual: stub discussion of fsck and reflogLibravatar J. Bruce Fields1-0/+21
Have some sort of recovery/reliability section that deals with reflog and fsck. Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
2007-01-24make --upload-pack option to git-fetch configurableLibravatar Uwe Kleine-König1-1/+5
This introduces the config item remote.<name>.uploadpack to override the default value (which is "git-upload-pack"). Signed-off-by: Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de> Signed-off-by: Junio C Hamano <junkio@cox.net>