summaryrefslogtreecommitdiff
path: root/Documentation
AgeCommit message (Collapse)AuthorFilesLines
2016-03-17Git 2.7.4Libravatar Junio C Hamano1-0/+11
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-17Sync with Git 2.6.6Libravatar Junio C Hamano4-3/+39
* maint-2.6: Git 2.6.6 Git 2.5.5 Git 2.4.11
2016-03-17Git 2.6.6Libravatar Junio C Hamano2-1/+13
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-17Merge branch 'maint-2.5' into maint-2.6Libravatar Junio C Hamano3-2/+26
* maint-2.5: Git 2.5.5 Git 2.4.11 list-objects: pass full pathname to callbacks list-objects: drop name_path entirely list-objects: convert name_path to a strbuf show_object_with_name: simplify by using path_name() http-push: stop using name_path tree-diff: catch integer overflow in combine_diff_path allocation add helpers for detecting size_t overflow
2016-03-17Git 2.5.5Libravatar Junio C Hamano2-1/+13
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-17Merge branch 'maint-2.4' into maint-2.5Libravatar Junio C Hamano2-1/+13
* maint-2.4: Git 2.4.11 list-objects: pass full pathname to callbacks list-objects: drop name_path entirely list-objects: convert name_path to a strbuf show_object_with_name: simplify by using path_name() http-push: stop using name_path tree-diff: catch integer overflow in combine_diff_path allocation add helpers for detecting size_t overflow
2016-03-17Git 2.4.11Libravatar Junio C Hamano2-1/+13
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-10Git 2.7.3Libravatar Junio C Hamano2-1/+64
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-10Merge branch 'mm/push-simple-doc' into maintLibravatar Junio C Hamano1-0/+7
The documentation did not clearly state that the 'simple' mode is now the default for "git push" when push.default configuration is not set. * mm/push-simple-doc: Documentation/git-push: document that 'simple' is the default
2016-03-10Merge branch 'jk/tighten-alloc' into maintLibravatar Junio C Hamano1-0/+7
* jk/tighten-alloc: (23 commits) compat/mingw: brown paper bag fix for 50a6c8e ewah: convert to REALLOC_ARRAY, etc convert ewah/bitmap code to use xmalloc diff_populate_gitlink: use a strbuf transport_anonymize_url: use xstrfmt git-compat-util: drop mempcpy compat code sequencer: simplify memory allocation of get_message test-path-utils: fix normalize_path_copy output buffer size fetch-pack: simplify add_sought_entry fast-import: simplify allocation in start_packfile write_untracked_extension: use FLEX_ALLOC helper prepare_{git,shell}_cmd: use argv_array use st_add and st_mult for allocation size computation convert trivial cases to FLEX_ARRAY macros use xmallocz to avoid size arithmetic convert trivial cases to ALLOC_ARRAY convert manual allocations to argv_array argv-array: add detach function add helpers for allocating flex-array structs harden REALLOC_ARRAY and xcalloc against size_t overflow ...
2016-02-23Documentation/git-push: document that 'simple' is the defaultLibravatar Matthieu Moy1-0/+7
The default behavior is well documented already in git-config(1), but git-push(1) itself did not mention it at all. For users willing to learn how "git push" works but not how to configure it, this makes the documentation cumbersome to read. Make the git-push(1) page self-contained by adding a short summary of what 'push.default=simple' does, early in the page. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22argv-array: add detach functionLibravatar Jeff King1-0/+7
The usual pattern for an argv array is to initialize it, push in some strings, and then clear it when done. Very occasionally, though, we must do other exotic things with the memory, like freeing the list but keeping the strings. Let's provide a detach function so that callers can make use of our API to build up the array, and then take ownership of it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22Git 2.7.2Libravatar Junio C Hamano2-1/+16
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22Merge branch 'mm/clean-doc-fix' into maintLibravatar Junio C Hamano1-3/+1
The documentation for "git clean" has been corrected; it mentioned that .git/modules/* are removed by giving two "-f", which has never been the case. * mm/clean-doc-fix: Documentation/git-clean.txt: don't mention deletion of .git/modules/*
2016-02-17Start preparing for 2.7.2Libravatar Junio C Hamano1-0/+27
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-17Merge branch 'nd/do-not-move-worktree-manually' into maintLibravatar Junio C Hamano1-5/+10
"git worktree" had a broken code that attempted to auto-fix possible inconsistency that results from end-users moving a worktree to different places without telling Git (the original repository needs to maintain backpointers to its worktrees, but "mv" run by end-users who are not familiar with that fact will obviously not adjust them), which actually made things worse when triggered. * nd/do-not-move-worktree-manually: worktree: stop supporting moving worktrees manually worktree.c: fix indentation
2016-02-09Documentation/git-clean.txt: don't mention deletion of .git/modules/*Libravatar Matt McCutchen1-3/+1
The latter half of this sentence, the removal of the submodules, was never done with (or without) double -f back when it was written, and we still do not do so. Signed-off-by: Matt McCutchen <matt@mattmccutchen.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-05Git 2.7.1Libravatar Junio C Hamano2-1/+89
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-05Merge branch 'lv/add-doc-working-tree' into maintLibravatar Junio C Hamano1-1/+1
* lv/add-doc-working-tree: git-add doc: do not say working directory when you mean working tree
2016-02-05Merge branch 'ss/clone-depth-single-doc' into maintLibravatar Junio C Hamano2-9/+9
Documentation for "git fetch --depth" has been updated for clarity. * ss/clone-depth-single-doc: docs: clarify that --depth for git-fetch works with newly initialized repos docs: say "commits" in the --depth option wording for git-clone docs: clarify that passing --depth to git-clone implies --single-branch
2016-02-05Merge branch 'ew/for-each-ref-doc' into maintLibravatar Junio C Hamano1-2/+7
* ew/for-each-ref-doc: for-each-ref: document `creatordate` and `creator` fields
2016-02-05Merge branch 'ss/user-manual' into maintLibravatar Junio C Hamano2-10/+36
Drop a few old "todo" items by deciding that the change one of them suggests is not such a good idea, and doing the change the other one suggested to do. * ss/user-manual: user-manual: add addition gitweb information user-manual: add section documenting shallow clones glossary: define the term shallow clone user-manual: remove temporary branch entry from todo list
2016-02-05Merge branch 'jk/list-tag-2.7-regression' into maintLibravatar Junio C Hamano2-2/+6
"git tag" started listing a tag "foo" as "tags/foo" when a branch named "foo" exists in the same repository; remove this unnecessary disambiguation, which is a regression introduced in v2.7.0. * jk/list-tag-2.7-regression: tag: do not show ambiguous tag names as "tags/foo" t6300: use test_atom for some un-modern tests
2016-02-05Merge branch 'nd/exclusion-regression-fix' into maintLibravatar Junio C Hamano1-19/+4
The ignore mechanism saw a few regressions around untracked file listing and sparse checkout selection areas in 2.7.0; the change that is responsible for the regression has been reverted. * nd/exclusion-regression-fix: Revert "dir.c: don't exclude whole dir prematurely if neg pattern may match"
2016-02-05Merge branch 'dw/signoff-doc' into maintLibravatar Junio C Hamano5-1/+9
The documentation has been updated to hint the connection between the '--signoff' option and DCO. * dw/signoff-doc: Expand documentation describing --signoff
2016-01-26tag: do not show ambiguous tag names as "tags/foo"Libravatar Jeff King2-2/+6
Since b7cc53e9 (tag.c: use 'ref-filter' APIs, 2015-07-11), git-tag has started showing tags with ambiguous names (i.e., when both "heads/foo" and "tags/foo" exists) as "tags/foo" instead of just "foo". This is both: - pointless; the output of "git tag" includes only refs/tags, so we know that "foo" means the one in "refs/tags". and - ambiguous; in the original output, we know that the line "foo" means that "refs/tags/foo" exists. In the new output, it is unclear whether we mean "refs/tags/foo" or "refs/tags/tags/foo". The reason this happens is that commit b7cc53e9 switched git-tag to use ref-filter's "%(refname:short)" output formatting, which was adapted from for-each-ref. This more general code does not know that we care only about tags, and uses shorten_unambiguous_ref to get the short-name. We need to tell it that we care only about "refs/tags/", and it should shorten with respect to that value. In theory, the ref-filter code could figure this out by us passing FILTER_REFS_TAGS. But there are two complications there: 1. The handling of refname:short is deep in formatting code that does not even have our ref_filter struct, let alone the arguments to the filter_ref struct. 2. In git v2.7.0, we expose the formatting language to the user. If we follow this path, it will mean that "%(refname:short)" behaves differently for "tag" versus "for-each-ref" (including "for-each-ref refs/tags/"), which can lead to confusion. Instead, let's add a new modifier to the formatting language, "strip", to remove a specific set of prefix components. This fixes "git tag", and lets users invoke the same behavior from their own custom formats (for "tag" or "for-each-ref") while leaving ":short" with its same consistent meaning in all places. We introduce a test in t7004 for "git tag", which fails without this patch. We also add a similar test in t3203 for "git branch", which does not actually fail. But since it is likely that "branch" will eventually use the same formatting code, the test helps defend against future regressions. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-22worktree: stop supporting moving worktrees manuallyLibravatar Nguyễn Thái Ngọc Duy1-5/+10
The current update_linked_gitdir() has a bug that can create "gitdir" file in non-multi-worktree setup. Worse, sometimes it can write relative path to "gitdir" file, which will not work (e.g. "git worktree list" will display the worktree's location incorrectly) Instead of fixing this, we step back a bit. The original design was probably not well thought out. For now, if the user manually moves a worktree, they have to fix up "gitdir" file manually or the worktree will get pruned. Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-21git-add doc: do not say working directory when you mean working treeLibravatar Lars Vogel1-1/+1
The usage of working directory is inconsistent in the git add help. Also http://git-scm.com/docs/git-clone speaks only about working tree. Remaining entry found by "git grep -B1 '^directory' git-add.txt" really relates to a directory. Signed-off-by: Lars Vogel <Lars.Vogel@vogella.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-08docs: clarify that --depth for git-fetch works with newly initialized reposLibravatar Sebastian Schuberth1-4/+5
The original wording sounded as if --depth could only be used to deepen or shorten the history of existing repos. However, that is not the case. In a workflow like $ git init $ git remote add origin https://github.com/git/git.git $ git fetch --depth=1 The newly initialized repo is properly created as a shallow repo. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-08docs: say "commits" in the --depth option wording for git-cloneLibravatar Sebastian Schuberth1-1/+1
It is not wrong to talk about "revisions" here, but in this context revisions are always commits, and that is how we already name it in the git-fetch docs. So align the docs by always referring to "commits". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-08Revert "dir.c: don't exclude whole dir prematurely if neg pattern may match"Libravatar Nguyễn Thái Ngọc Duy1-19/+4
This reverts commit 57534ee77d22e725d971ee89c77dc6aad61c573f. The feature added in that commit requires that patterns behave the same way from anywhere. But some patterns can behave differently depending on current "working" directory. The conditions to catch and avoid these patterns are too loose. The untracked listing[1] and sparse-checkout selection[2] can become incorrect as a result. [1] http://article.gmane.org/gmane.comp.version-control.git/283520 [2] http://article.gmane.org/gmane.comp.version-control.git/283532 Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-07docs: clarify that passing --depth to git-clone implies --single-branchLibravatar Sebastian Schuberth1-5/+4
It is confusing to document how --depth behaves as part of the --single-branch docs. Better move that part to the --depth docs, saying that it implies --single-branch by default. Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-05Expand documentation describing --signoffLibravatar David A. Wheeler5-1/+9
Modify various document (man page) files to explain in more detail what --signoff means. This was inspired by https://lwn.net/Articles/669976/ where paulj noted, "adding [the] '-s' argument to [a] git commit doesn't really mean you have even heard of the DCO...". Extending git's documentation will make it easier to argue that developers understood --signoff when they use it. Signed-off-by: David A. Wheeler <dwheeler@dwheeler.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-05for-each-ref: document `creatordate` and `creator` fieldsLibravatar Eric Wong1-2/+7
These were introduced back in 2006 at 3175aa1ec28c but never documented. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-04Git 2.7Libravatar Junio C Hamano1-0/+5
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-04Sync with 2.6.5Libravatar Junio C Hamano2-1/+21
2016-01-04Git 2.6.5Libravatar Junio C Hamano2-1/+21
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-12-30user-manual: add addition gitweb informationLibravatar Stephen P. Smith1-4/+11
Rework the section on gitweb to add information about the cgi script and the instaweb command. Signed-off-by: Stephen P. Smith <ischis2@cox.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-12-30user-manual: add section documenting shallow clonesLibravatar Stephen P. Smith1-3/+20
Signed-off-by: Stephen P. Smith <ischis2@cox.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-12-29glossary: define the term shallow cloneLibravatar Stephen P. Smith1-0/+5
There are several places in the documentation that the term shallow clone is used. Defining the term enables its use elsewhere with a known definition. Signed-off-by: Stephen P. Smith <ischis2@cox.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-12-28Git 2.7-rc3Libravatar Junio C Hamano1-0/+11
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-12-28user-manual: remove temporary branch entry from todo listLibravatar Stephen P. Smith1-3/+0
In the section on "How to check out a different version of a project" the "new" branch is used as a temporary branch. A detached HEAD was not used since it was a new feature introduced just a couple weeks prior. The section could be changed to use and explain a detached HEAD, except that would increase the learning curve early in the manual. Detached HEADs are discussed a couple sections later under "Examining an old version without creating a new branch". Let's declare that it is a bad idea to rewrite the example that uses a temporary branch to do the sightseeing on a detached HEAD. Signed-off-by: Stephen P. Smith <ischis2@cox.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-12-22Git 2.7-rc2Libravatar Junio C Hamano1-0/+3
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-12-21Update release notes to 2.7Libravatar Junio C Hamano1-2/+29
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-12-21Merge branch 'bc/format-patch-null-from-line'Libravatar Junio C Hamano1-0/+4
"format-patch" has learned a new option to zero-out the commit object name on the mbox "From " line. * bc/format-patch-null-from-line: format-patch: check that header line has expected format format-patch: add an option to suppress commit hash sha1_file.c: introduce a null_oid constant
2015-12-21Merge branch 'mc/push-recurse-submodules-config'Libravatar Junio C Hamano2-10/+28
Add new config to avoid typing "--recurse-submodules" on each push. * mc/push-recurse-submodules-config: push: follow the "last one wins" convention for --recurse-submodules push: test that --recurse-submodules on command line overrides config push: add recurseSubmodules config option
2015-12-15format-patch: add an option to suppress commit hashLibravatar brian m. carlson1-0/+4
Oftentimes, patches created by git format-patch will be stored in version control or compared with diff. In these cases, two otherwise identical patches can have different commit hashes, leading to diff noise. Teach git format-patch a --zero-commit option that instead produces an all-zero hash to avoid this diff noise. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-12-15Git 2.7-rc1Libravatar Junio C Hamano1-7/+13
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-12-15Sync with maintLibravatar Junio C Hamano1-0/+14
2015-12-15Update draft release notes to 2.6.5Libravatar Junio C Hamano1-0/+14
Signed-off-by: Junio C Hamano <gitster@pobox.com>