summaryrefslogtreecommitdiff
path: root/Documentation
AgeCommit message (Collapse)AuthorFilesLines
2013-04-07Sync with 1.8.2.1Libravatar Junio C Hamano3-2/+14
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-07Git 1.8.2.1Libravatar Junio C Hamano2-1/+7
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-07Update draft release notes to 1.8.3Libravatar Junio C Hamano1-0/+20
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-07Merge branch 'cn/commit-amend-doc'Libravatar Junio C Hamano1-8/+9
* cn/commit-amend-doc: Documentation/git-commit: reword the --amend explanation
2013-04-07Merge branch 'mg/texinfo-5'Libravatar Junio C Hamano1-0/+1
Strip @anchor elements in the texinfo output of the documentation, as a single document created by concatenating our entire manual set will produce many duplicates that makes newer texinfo unhappy. * mg/texinfo-5: Documentation: Strip texinfo anchors to avoid duplicates
2013-04-07Merge branch 'rr/triangle'Libravatar Junio C Hamano1-3/+21
Support "pull from one place, push to another place" workflow better by introducing remote.pushdefault (overrides the "origin" thing) and branch.*.pushremote (overrides the branch.*.remote). * rr/triangle: remote.c: introduce branch.<name>.pushremote remote.c: introduce remote.pushdefault remote.c: introduce a way to have different remotes for fetch/push t5516 (fetch-push): drop implicit arguments from helper functions t5516 (fetch-push): update test description remote.c: simplify a bit of code using git_config_string()
2013-04-07Sync with 1.8.1.6Libravatar Junio C Hamano2-1/+7
2013-04-07Git 1.8.1.6Libravatar Junio C Hamano2-1/+7
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-07gitremote-helpers(1): clarify refspec behaviourLibravatar John Keeping1-2/+2
The documentation says that "If no 'refspec' capability is advertised, there is an implied `refspec *:*`" but this is only the case for the "import" command. Since there is a comment in transport-helper.c indicating that this default is for historical reasons, change the documentation to clarify that a refspec should always be specified. Signed-off-by: John Keeping <john@keeping.me.uk> Acked-by: Sverre Rabbelier <srabbelier@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-07fast-export: Allow pruned-references in mark fileLibravatar Antoine Pelisse1-0/+2
fast-export can fail because of some pruned-reference when importing a mark file. The problem happens in the following scenario: $ git fast-export --export-marks=MARKS master (rewrite master) $ git prune $ git fast-export --import-marks=MARKS master This might fail if some references have been removed by prune because some marks will refer to no longer existing commits. git-fast-export will not need these objects anyway as they were no longer reachable. We still need to update last_numid so we don't change the mapping between marks and objects for remote-helpers. Unfortunately, the mark file should not be rewritten without lost marks if no new objects has been exported, as we could lose track of the last last_numid. Signed-off-by: Antoine Pelisse <apelisse@gmail.com> Reviewed-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-05Update draft release notes to 1.8.3Libravatar Junio C Hamano1-0/+12
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-05Merge branch 'mh/rev-parse-verify-doc'Libravatar Junio C Hamano1-4/+15
"rev-parse --verify" was documented in a misleading way. * mh/rev-parse-verify-doc: rev-parse: clarify documentation for the --verify option
2013-04-05Merge branch 'sg/gpg-sig'Libravatar Junio C Hamano2-1/+7
Teach "merge/pull" to optionally verify and reject commits that are not signed properly. * sg/gpg-sig: pretty printing: extend %G? to include 'N' and 'U' merge/pull Check for untrusted good GPG signatures merge/pull: verify GPG signatures of commits being merged commit.c/GPG signature verification: Also look at the first GPG status line Move commit GPG signature verification to commit.c
2013-04-05Documentation/git-commit: reword the --amend explanationLibravatar Carlos Martín Nieto1-8/+9
The explanation for 'git commit --amend' talks about preparing a tree object, which shouldn't be how user-facing documentation talks about commit. Reword it to say it works as usual, but replaces the current commit. Signed-off-by: Carlos Martín Nieto <cmn@elego.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-03Documentation: Strip texinfo anchors to avoid duplicatesLibravatar Martin von Gagern1-0/+1
This keeps texinfo 5.x happy. See https://bugs.gentoo.org/464210. Signed-off-by: Martin von Gagern <Martin.vGagern@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-03Update draft release notes to 1.8.3Libravatar Junio C Hamano1-10/+31
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-03Sync with maintLibravatar Junio C Hamano3-0/+75
2013-04-03Merge branch 'jc/sha1-name-object-peeler'Libravatar Junio C Hamano1-0/+5
There was no good way to ask "I have a random string that came from outside world. I want to turn it into a 40-hex object name while making sure such an object exists". A new peeling suffix ^{object} can be used for that purpose, together with "rev-parse --verify". * jc/sha1-name-object-peeler: peel_onion(): teach $foo^{object} peeler peel_onion: disambiguate to favor tree-ish when we know we want a tree-ish
2013-04-03Update draft release notes to 1.8.2.1Libravatar Junio C Hamano1-0/+35
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-03Merge branch 'mg/gpg-interface-using-status' into maintLibravatar Junio C Hamano1-0/+1
Verification of signed tags were not done correctly when not in C or en/US locale. * mg/gpg-interface-using-status: pretty: make %GK output the signing key for signed commits pretty: parse the gpg status lines rather than the output gpg_interface: allow to request status return log-tree: rely upon the check in the gpg_interface gpg-interface: check good signature in a reliable way
2013-04-03Merge branch 'bc/commit-complete-lines-given-via-m-option' into maintLibravatar Junio C Hamano1-10/+19
'git commit -m "$msg"' used to add an extra newline even when $msg already ended with one. * bc/commit-complete-lines-given-via-m-option: Documentation/git-commit.txt: rework the --cleanup section git-commit: only append a newline to -m mesg if necessary t7502: demonstrate breakage with a commit message with trailing newlines t/t7502: compare entire commit message with what was expected
2013-04-03Sync with 1.8.1 maintenance trackLibravatar Junio C Hamano2-0/+40
* maint-1.8.1: Start preparing for 1.8.1.6 git-tag(1): we tag HEAD by default Fix revision walk for commits with the same dates t2003: work around path mangling issue on Windows pack-refs: add fully-peeled trait pack-refs: write peeled entry for non-tags use parse_object_or_die instead of die("bad object") avoid segfaults on parse_object failure entry: fix filter lookup t2003: modernize style name-hash.c: fix endless loop with core.ignorecase=true
2013-04-03Start preparing for 1.8.1.6Libravatar Junio C Hamano1-0/+34
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-03Merge branch 'yd/doc-merge-annotated-tag' into maint-1.8.1Libravatar Junio C Hamano2-1/+26
* yd/doc-merge-annotated-tag: Documentation: merging a tag is a special case
2013-04-03git-tag(1): we tag HEAD by defaultLibravatar Thomas Rast1-0/+6
The <commit>|<object> argument is actually not explained anywhere (except implicitly in the description of an unannotated tag). Write a little explanation, in particular to cover the default. Signed-off-by: Thomas Rast <trast@inf.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-02Update draft release notes to 1.8.3Libravatar Junio C Hamano1-0/+11
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-02Merge branch 'bk/document-commit-tree-S'Libravatar Junio C Hamano1-1/+6
* bk/document-commit-tree-S: commit-tree: document -S option consistently
2013-04-02remote.c: introduce branch.<name>.pushremoteLibravatar Ramkumar Ramachandra1-4/+15
This new configuration variable overrides `remote.pushdefault` and `branch.<name>.remote` for pushes. When you pull from one place (e.g. your upstream) and push to another place (e.g. your own publishing repository), you would want to set `remote.pushdefault` to specify the remote to push to for all branches, and use this option to override it for a specific branch. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-02remote.c: introduce remote.pushdefaultLibravatar Ramkumar Ramachandra1-3/+10
This new configuration variable defines the default remote to push to, and overrides `branch.<name>.remote` for all branches. It is useful in the typical triangular-workflow setup, where the remote you're fetching from is different from the remote you're pushing to. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-02rev-parse: clarify documentation for the --verify optionLibravatar Michael Haggerty1-4/+15
The old version could be read to mean that the argument has to refer to a valid object, but that is incorrect: * the object is not necessarily read (e.g., to check for corruption) * if the argument is a 40-digit string of hex digits, then it is accepted whether or not is is the name of an existing object. So reword the explanation to be less ambiguous. Also fix the examples involving --verify: to be sure that the argument refers to a commit (rather than some other kind of object), the argument has to be suffixed with "^{commit}". This trick is not possible in the example involving --default, so don't imply that it is exactly the same as the previous example. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-01Update draft release notes to 1.8.3Libravatar Junio C Hamano1-2/+28
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-01Merge branch 'maint'Libravatar Junio C Hamano1-0/+4
* maint: Update draft release notes to 1.8.2.1
2013-04-01Update draft release notes to 1.8.2.1Libravatar Junio C Hamano1-0/+4
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-01Merge branch 'yd/doc-is-in-asciidoc' into maintLibravatar Junio C Hamano1-0/+3
* yd/doc-is-in-asciidoc: CodingGuidelines: our documents are in AsciiDoc
2013-04-01Merge branch 'yd/doc-merge-annotated-tag' into maintLibravatar Junio C Hamano2-1/+26
* yd/doc-merge-annotated-tag: Documentation: merging a tag is a special case
2013-04-01Merge branch 'tb/document-status-u-tradeoff' into maintLibravatar Junio C Hamano2-4/+14
* tb/document-status-u-tradeoff: status: advise to consider use of -u when read_directory takes too long git status: document trade-offs in choosing parameters to the -u option
2013-04-01Merge branch 'da/downcase-u-in-usage' into maintLibravatar Junio C Hamano1-2/+2
* da/downcase-u-in-usage: contrib/mw-to-git/t/install-wiki.sh: use a lowercase "usage:" string contrib/examples/git-remote.perl: use a lowercase "usage:" string tests: use a lowercase "usage:" string git-svn: use a lowercase "usage:" string Documentation/user-manual.txt: use a lowercase "usage:" string templates/hooks--update.sample: use a lowercase "usage:" string contrib/hooks/setgitperms.perl: use a lowercase "usage:" string contrib/examples: use a lowercase "usage:" string contrib/fast-import/import-zips.py: use spaces instead of tabs contrib/fast-import/import-zips.py: fix broken error message contrib/fast-import: use a lowercase "usage:" string contrib/credential: use a lowercase "usage:" string git-cvsimport: use a lowercase "usage:" string git-cvsimport: use a lowercase "usage:" string git-cvsexportcommit: use a lowercase "usage:" string git-archimport: use a lowercase "usage:" string git-merge-one-file: use a lowercase "usage:" string git-relink: use a lowercase "usage:" string git-svn: use a lowercase "usage:" string git-sh-setup: use a lowercase "usage:" string
2013-03-31pretty printing: extend %G? to include 'N' and 'U'Libravatar Sebastian Götte1-1/+2
Expand %G? in pretty format strings to 'N' in case of no GPG signature and 'U' in case of a good but untrusted GPG signature in addition to the previous 'G'ood and 'B'ad. This eases writing anyting parsing git-log output. Signed-off-by: Sebastian Götte <jaseg@physik-pool.tu-berlin.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-31merge/pull Check for untrusted good GPG signaturesLibravatar Sebastian Götte1-2/+2
When --verify-signatures is specified, abort the merge in case a good GPG signature from an untrusted key is encountered. Signed-off-by: Sebastian Götte <jaseg@physik-pool.tu-berlin.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-31merge/pull: verify GPG signatures of commits being mergedLibravatar Sebastian Götte1-0/+5
When --verify-signatures is specified on the command-line of git-merge or git-pull, check whether the commits being merged have good gpg signatures and abort the merge in case they do not. This allows e.g. auto-deployment from untrusted repo hosts. Signed-off-by: Sebastian Götte <jaseg@physik-pool.tu-berlin.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-31peel_onion(): teach $foo^{object} peelerLibravatar Junio C Hamano1-0/+5
A string that names an object can be suffixed with ^{type} peeler to say "I have this object name; peel it until you get this type. If you cannot do so, it is an error". v1.8.2^{commit} asks for a commit that is pointed at an annotated tag v1.8.2; v1.8.2^{tree} unwraps it further to the top-level tree object. A special suffix ^{} (i.e. no type specified) means "I do not care what it unwraps to; just peel annotated tag until you get something that is not a tag". When you have a random user-supplied string, you can turn it to a bare 40-hex object name, and cause it to error out if such an object does not exist, with: git rev-parse --verify "$userstring^{}" for most objects, but this does not yield the tag object name when $userstring refers to an annotated tag. Introduce a new suffix, ^{object}, that only makes sure the given name refers to an existing object. Then git rev-parse --verify "$userstring^{object}" becomes a way to make sure $userstring refers to an existing object. This is necessary because the plumbing "rev-parse --verify" is only about "make sure the argument is something we can feed to get_sha1() and turn it into a raw 20-byte object name SHA-1" and is not about "make sure that 20-byte object name SHA-1 refers to an object that exists in our object store". When the given $userstring is already a 40-hex, by definition "rev-parse --verify $userstring" can turn it into a raw 20-byte object name. With "$userstring^{object}", we can make sure that the 40-hex string names an object that exists in our object store before "--verify" kicks in. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-28Merge branch 'yd/doc-is-in-asciidoc'Libravatar Junio C Hamano1-0/+3
* yd/doc-is-in-asciidoc: CodingGuidelines: our documents are in AsciiDoc
2013-03-28Merge branch 'yd/doc-merge-annotated-tag'Libravatar Junio C Hamano2-1/+26
Document the 1.7.9 feature to merge a signed tag and keep that in the mergetag header in the resulting commit better. * yd/doc-merge-annotated-tag: Documentation: merging a tag is a special case
2013-03-28Merge branch 'jk/difftool-dir-diff-edit-fix'Libravatar Junio C Hamano1-3/+5
"git difftool --dir-diff" made symlinks to working tree files when preparing a temporary directory structure, so that accidental edits of these files in the difftool are reflected back to the working tree, but the logic to decide when to do so was not quite right. * jk/difftool-dir-diff-edit-fix: difftool --dir-diff: symlink all files matching the working tree difftool: avoid double slashes in symlink targets git-difftool(1): fix formatting of --symlink description
2013-03-28Merge branch 'maint'Libravatar Junio C Hamano1-1/+1
* maint: git help config: s/insn/instruction/
2013-03-28Merge branch 'maint-1.8.1' into maintLibravatar Junio C Hamano1-1/+1
* maint-1.8.1: git help config: s/insn/instruction/
2013-03-28git help config: s/insn/instruction/Libravatar Matthias Krüger1-1/+1
"insn" appears to be an in-code abbreviation and should not appear in manual/help pages. Signed-off-by: Matthias Krüger <matthias.krueger@famsik.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-27Merge branch 'maint'Libravatar Junio C Hamano3-1/+6
* maint: More fixes for 1.8.2.1 merge-tree: fix typo in merge-tree.c::unresolved git-commit doc: describe use of multiple `-m` options git-pull doc: fix grammo ("conflicts" is plural)
2013-03-27More fixes for 1.8.2.1Libravatar Junio C Hamano1-0/+3
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-27Merge branch 'maint-1.8.1' into maintLibravatar Junio C Hamano2-1/+3
* maint-1.8.1: merge-tree: fix typo in merge-tree.c::unresolved git-commit doc: describe use of multiple `-m` options git-pull doc: fix grammo ("conflicts" is plural)