summaryrefslogtreecommitdiff
path: root/Documentation
AgeCommit message (Collapse)AuthorFilesLines
2018-09-10config: document value 2 for protocol.versionLibravatar Brandon Williams1-0/+2
Update the config documentation to note the value `2` as an acceptable value for the protocol.version config. Signed-off-by: Brandon Williams <bmwill@google.com> Signed-off-by: Josh Steadmon <steadmon@google.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-24pack-protocol: mention and point to docs for protocol v2Libravatar Brandon Williams1-1/+2
Signed-off-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-22protocol-v2 doc: put HTTP headers after requestLibravatar Josh Steadmon1-2/+1
HTTP servers return 400 if you send headers before the GET request. Signed-off-by: Josh Steadmon <steadmon@google.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-15transport-helper: introduce stateless-connectLibravatar Brandon Williams1-0/+32
Introduce the transport-helper capability 'stateless-connect'. This capability indicates that the transport-helper can be requested to run the 'stateless-connect' command which should attempt to make a stateless connection with a remote end. Once established, the connection can be used by the git client to communicate with the remote end natively in a stateless-rpc manner as supported by protocol v2. This means that the client must send everything the server needs in a single request as the client must not assume any state-storing on the part of the server or transport. If a stateless connection cannot be established then the remote-helper will respond in the same manner as the 'connect' command indicating that the client should fallback to using the dumb remote-helper commands. A future patch will implement the 'stateless-connect' capability in our http remote-helper (remote-curl) so that protocol v2 can be used using the http transport. Signed-off-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-15fetch-pack: support shallow requestsLibravatar Brandon Williams1-7/+11
Enable shallow clones and deepen requests using protocol version 2 if the server 'fetch' command supports the 'shallow' feature. Signed-off-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-15fetch-pack: perform a fetch using v2Libravatar Brandon Williams1-1/+66
When communicating with a v2 server, perform a fetch by requesting the 'fetch' command. Signed-off-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-15upload-pack: introduce fetch server commandLibravatar Brandon Williams1-0/+125
Introduce the 'fetch' server command. Signed-off-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-15ls-refs: introduce ls-refs server commandLibravatar Brandon Williams1-0/+31
Introduce the ls-refs server command. In protocol v2, the ls-refs command is used to request the ref advertisement from the server. Since it is a command which can be requested (as opposed to mandatory in v1), a client can sent a number of parameters in its request to limit the ref advertisement based on provided ref-prefixes. Signed-off-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-15serve: introduce git-serveLibravatar Brandon Williams2-0/+171
Introduce git-serve, the base server for protocol version 2. Protocol version 2 is intended to be a replacement for Git's current wire protocol. The intention is that it will be a simpler, less wasteful protocol which can evolve over time. Protocol version 2 improves upon version 1 by eliminating the initial ref advertisement. In its place a server will export a list of capabilities and commands which it supports in a capability advertisement. A client can then request that a particular command be executed by providing a number of capabilities and command specific parameters. At the completion of a command, a client can request that another command be executed or can terminate the connection by sending a flush packet. Signed-off-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-28Git 2.16-rc0Libravatar Junio C Hamano1-0/+31
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-28Merge branch 'sb/describe-blob'Libravatar Junio C Hamano2-2/+21
"git describe" was taught to dig trees deeper to find a <commit-ish>:<path> that refers to a given blob object. * sb/describe-blob: builtin/describe.c: describe a blob builtin/describe.c: factor out describe_commit builtin/describe.c: print debug statements earlier builtin/describe.c: rename `oid` to avoid variable shadowing revision.h: introduce blob/tree walking in order of the commits list-objects.c: factor out traverse_trees_and_blobs t6120: fix typo in test name
2017-12-28Merge branch 'hi/merge-verify-sig-config'Libravatar Junio C Hamano1-0/+4
"git merge" learned to pay attention to merge.verifySignatures configuration variable and pretend as if '--verify-signatures' option was given from the command line. * hi/merge-verify-sig-config: t5573, t7612: clean up after unexpected success of 'pull' and 'merge' t: add tests for pull --verify-signatures merge: add config option for verifySignatures
2017-12-28Merge branch 'ks/doc-previous-checkout'Libravatar Junio C Hamano1-7/+12
Doc update. * ks/doc-previous-checkout: Doc/check-ref-format: clarify information about @{-N} syntax
2017-12-28Merge branch 'sr/http-sslverify-config-doc'Libravatar Junio C Hamano1-2/+2
Docfix. * sr/http-sslverify-config-doc: config: document default value of http.sslVerify
2017-12-28Merge branch 'jh/partial-clone-doc'Libravatar Junio C Hamano1-0/+324
* jh/partial-clone-doc: partial-clone: design doc
2017-12-27RelNotes: the eleventh batchLibravatar Junio C Hamano1-0/+41
Hopefully the last one before -rc0 Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-27Merge branch 'rb/quick-install-doc'Libravatar Junio C Hamano2-6/+8
The build procedure now allows not just the repositories but also the refs to be used to take pre-formatted manpages and html documents to install. * rb/quick-install-doc: install-doc-quick: allow specifying what ref to install
2017-12-27Merge branch 'tb/delimit-pretty-trailers-args-with-comma'Libravatar Junio C Hamano1-5/+7
Doc updates. * tb/delimit-pretty-trailers-args-with-comma: docs/pretty-formats: mention commas in %(trailers) syntax
2017-12-27Merge branch 'jt/decorate-api'Libravatar Junio C Hamano1-6/+0
A few structures and variables that are implementation details of the decorate API have been renamed and then the API got documented better. * jt/decorate-api: decorate: clean up and document API
2017-12-27Merge branch 'db/doc-workflows-neuter-the-maintainer'Libravatar Junio C Hamano1-2/+2
Docfix. * db/doc-workflows-neuter-the-maintainer: doc: reword gitworkflows.txt for neutrality
2017-12-27Merge branch 'es/worktree-checkout-hook'Libravatar Junio C Hamano1-1/+2
"git worktree add" learned to run the post-checkout hook, just like "git checkout" does, after the initial checkout. * es/worktree-checkout-hook: worktree: invoke post-checkout hook (unless --no-checkout)
2017-12-27Merge branch 'lb/rebase-i-short-command-names'Libravatar Junio C Hamano3-48/+54
With a configuration variable rebase.abbreviateCommands set, "git rebase -i" produces the todo list with a single-letter command names. * lb/rebase-i-short-command-names: sequencer.c: drop 'const' from function return type t3404: add test case for abbreviated commands rebase -i: learn to abbreviate command names rebase -i -x: add exec commands via the rebase--helper rebase -i: update functions to use a flags parameter rebase -i: replace reference to sha1 with oid rebase -i: refactor transform_todo_ids rebase -i: set commit to null in exec commands Documentation: use preferred name for the 'todo list' script Documentation: move rebase.* configs to new file
2017-12-27Merge branch 'jh/object-filtering'Libravatar Junio C Hamano3-2/+65
In preparation for implementing narrow/partial clone, the object walking machinery has been taught a way to tell it to "filter" some objects from enumeration. * jh/object-filtering: rev-list: support --no-filter argument list-objects-filter-options: support --no-filter list-objects-filter-options: fix 'keword' typo in comment pack-objects: add list-objects filtering rev-list: add list-objects filtering support list-objects: filter objects in traverse_commit_list oidset: add iterator methods to oidset oidmap: add oidmap iterator methods dir: allow exclusions from blob in addition to file
2017-12-19RelNotes: the tenth batchLibravatar Junio C Hamano1-0/+46
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-19Merge branch 'ls/editor-waiting-message'Libravatar Junio C Hamano1-0/+3
Git shows a message to tell the user that it is waiting for the user to finish editing when spawning an editor, in case the editor opens to a hidden window or somewhere obscure and the user gets lost. * ls/editor-waiting-message: launch_editor(): indicate that Git waits for user input refactor "dumb" terminal determination
2017-12-19Merge branch 'ar/unconfuse-three-dots'Libravatar Junio C Hamano3-12/+21
Ancient part of codebase still shows dots after an abbreviated object name just to show that it is not a full object name, but these ellipses are confusing to people who newly discovered Git who are used to seeing abbreviated object names and find them confusing with the range syntax. * ar/unconfuse-three-dots: t2020: test variations that matter t4013: test new output from diff --abbrev --raw diff: diff_aligned_abbrev: remove ellipsis after abbreviated SHA-1 value t4013: prepare for upcoming "diff --raw --abbrev" output format change checkout: describe_detached_head: remove ellipsis after committish print_sha1_ellipsis: introduce helper Documentation: user-manual: limit usage of ellipsis Documentation: revisions: fix typo: "three dot" ---> "three-dot" (in line with "two-dot").
2017-12-19Merge branch 'tg/worktree-create-tracking'Libravatar Junio C Hamano2-10/+44
The way "git worktree add" determines what branch to create from where and checkout in the new worktree has been updated a bit. * tg/worktree-create-tracking: add worktree.guessRemote config option worktree: add --guess-remote flag to add subcommand worktree: make add <path> <branch> dwim worktree: add --[no-]track option to the add subcommand worktree: add can be created from any commit-ish checkout: factor out functions to new lib file
2017-12-19Merge branch 'sb/clone-recursive-submodule-doc'Libravatar Junio C Hamano1-8/+11
Doc update. * sb/clone-recursive-submodule-doc: Documentation/git-clone: improve description for submodule recursing
2017-12-19Merge branch 'jt/diff-anchored-patience'Libravatar Junio C Hamano1-0/+10
"git diff" learned a variant of the "--patience" algorithm, to which the user can specify which 'unique' line to be used as anchoring points. * jt/diff-anchored-patience: diff: support anchoring line(s)
2017-12-19builtin/describe.c: describe a blobLibravatar Stefan Beller1-2/+16
Sometimes users are given a hash of an object and they want to identify it further (ex.: Use verify-pack to find the largest blobs, but what are these? or [1]) When describing commits, we try to anchor them to tags or refs, as these are conceptually on a higher level than the commit. And if there is no ref or tag that matches exactly, we're out of luck. So we employ a heuristic to make up a name for the commit. These names are ambiguous, there might be different tags or refs to anchor to, and there might be different path in the DAG to travel to arrive at the commit precisely. When describing a blob, we want to describe the blob from a higher layer as well, which is a tuple of (commit, deep/path) as the tree objects involved are rather uninteresting. The same blob can be referenced by multiple commits, so how we decide which commit to use? This patch implements a rather naive approach on this: As there are no back pointers from blobs to commits in which the blob occurs, we'll start walking from any tips available, listing the blobs in-order of the commit and once we found the blob, we'll take the first commit that listed the blob. For example git describe --tags v0.99:Makefile conversion-901-g7672db20c2:Makefile tells us the Makefile as it was in v0.99 was introduced in commit 7672db20. The walking is performed in reverse order to show the introduction of a blob rather than its last occurrence. [1] https://stackoverflow.com/questions/223678/which-commit-has-this-blob Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-19Doc/check-ref-format: clarify information about @{-N} syntaxLibravatar Kaartic Sivaraam1-7/+12
When the N-th previous thing checked out syntax (@{-N}) is used with '--branch' option of check-ref-format the result may not be the name of a branch that currently exists or ever existed. This is because @{-N} is used to refer to the N-th last checked out "thing", which might be a commit object name if the previous check out was a detached HEAD state; or a branch name, otherwise. The documentation thus does a wrong thing by promoting it as the "previous branch syntax". State that @{-N} is the syntax for specifying "N-th last thing checked out" and also state that the result of using @{-N} might also result in an commit object name. Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-18config: document default value of http.sslVerifyLibravatar Simon Ruderich1-2/+2
Remove any doubt that certificates might not be verified by default. Signed-off-by: Simon Ruderich <simon@ruderich.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-14partial-clone: design docLibravatar Jeff Hostetler1-0/+324
Design document for partial clone feature. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-14RelNotes: minor typo fixes in 2.16.0 draftLibravatar Todd Zullinger1-2/+2
Signed-off-by: Todd Zullinger <tmz@pobox.com>
2017-12-13RelNotes: the ninth batchLibravatar Junio C Hamano1-0/+31
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-13Merge branch 'jk/no-optional-locks'Libravatar Junio C Hamano1-0/+13
Doc update for a feature available in Git v2.14 and upwards. * jk/no-optional-locks: git-status.txt: mention --no-optional-locks
2017-12-13Merge branch 'ks/doc-checkout-previous'Libravatar Junio C Hamano1-4/+4
@{-N} in "git checkout @{-N}" may refer to a detached HEAD state, but the documentation was not clear about it, which has been fixed. * ks/doc-checkout-previous: Doc/checkout: checking out using @{-N} can lead to detached state
2017-12-13Merge branch 'fk/sendmail-from-path'Libravatar Junio C Hamano1-3/+3
"git send-email" tries to see if the sendmail program is available in /usr/lib and /usr/sbin; extend the list of locations to be checked to also include directories on $PATH. * fk/sendmail-from-path: git-send-email: honor $PATH for sendmail binary
2017-12-13Merge branch 'jc/receive-pack-hook-doc'Libravatar Junio C Hamano1-10/+10
Doc update. * jc/receive-pack-hook-doc: hooks doc: clarify when receive-pack invokes its hooks
2017-12-13Merge branch 'ra/decorate-limit-refs'Libravatar Junio C Hamano1-0/+7
The tagnames "git log --decorate" uses to annotate the commits can now be limited to subset of available refs with the two additional options, --decorate-refs[-exclude]=<pattern>. * ra/decorate-limit-refs: log: add option to choose which refs to decorate
2017-12-12install-doc-quick: allow specifying what ref to installLibravatar Randall S. Becker2-6/+8
We allow the builders, who want to install the preformatted manpages and html documents, to specify where in their filesystem these two repositories are stored. Let them also specify which ref (or even a revision) to grab the preformatted material from. Signed-off-by: Randall S. Becker <rsbecker@nexbridge.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-12merge: add config option for verifySignaturesLibravatar Hans Jerry Illikainen1-0/+4
git merge --verify-signatures can be used to verify that the tip commit of the branch being merged in is properly signed, but it's cumbersome to have to specify that every time. Add a configuration option that enables this behaviour by default, which can be overridden by --no-verify-signatures. Signed-off-by: Hans Jerry Illikainen <hji@dyntopia.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-08doc: reword gitworkflows.txt for neutralityLibravatar Daniel Bensoussan1-2/+2
Change 'he' to 'them' to be more neutral in "gitworkflows.txt". Signed-off-by: Matthieu Moy <matthieu.moy@univ-lyon1.fr> Signed-off-by: Timothee Albertin <timothee.albertin@etu.univ-lyon1.fr> Signed-off-by: Nathan Payre <nathan.payre@etu.univ-lyon1.fr> Signed-off-by: Daniel Bensoussan <daniel.bensoussan--bohm@etu.univ-lyon1.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-08decorate: clean up and document APILibravatar Jonathan Tan1-6/+0
Improve the names of the identifiers in decorate.h, document them, and add an example of how to use these functions. The example is compiled and run as part of the test suite. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-08docs/pretty-formats: mention commas in %(trailers) syntaxLibravatar Jeff King1-5/+7
Commit 84ff053d47 (pretty.c: delimit "%(trailers)" arguments with ",", 2017-10-01) switched the syntax of the trailers placeholder, but forgot to update the documentation in pretty-formats.txt. There's no need to mention the old syntax; it was never in a released version of Git. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-07worktree: invoke post-checkout hook (unless --no-checkout)Libravatar Eric Sunshine1-1/+2
git-clone and git-checkout both invoke the post-checkout hook following a successful checkout, yet git-worktree neglects to do so even though it too "checks out" the worktree. Fix this oversight. Implementation note: The newly-created worktree may reference a branch or be detached. In the latter case, a commit lookup is performed, though the result is used only in a boolean sense to (a) determine if the commit actually exists, and (b) assign either the branch name or commit ID to HEAD. Since the post-commit hook needs to know the ID of the checked-out commit, the lookup now needs to be done in all cases, rather than only when detached. Consequently, a new boolean is needed to handle (b) since the lookup result itself can no longer perform that role. Reported-by: Matthew K Gumbel <matthew.k.gumbel@intel.com> Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-07launch_editor(): indicate that Git waits for user inputLibravatar Lars Schneider1-0/+3
When a graphical GIT_EDITOR is spawned by a Git command that opens and waits for user input (e.g. "git rebase -i"), then the editor window might be obscured by other windows. The user might be left staring at the original Git terminal window without even realizing that s/he needs to interact with another window before Git can proceed. To this user Git appears hanging. Print a message that Git is waiting for editor input in the original terminal and get rid of it when the editor returns, if the terminal supports erasing the last line. Also, make sure that our message is terminated with a whitespace so that any message the editor may show upon starting up will be kept separate from our message. Power users might not want to see this message or their editor might already print such a message (e.g. emacsclient). Allow these users to suppress the message by disabling the "advice.waitingForEditor" config. The standard advise() function is not used here as it would always add a newline which would make deleting the message harder. Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-06add worktree.guessRemote config optionLibravatar Thomas Gummerer2-0/+13
Some users might want to have the --guess-remote option introduced in the previous commit on by default, so they don't have to type it out every time they create a new worktree. Add a config option worktree.guessRemote that allows users to configure the default behaviour for themselves. Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-06worktree: add --guess-remote flag to add subcommandLibravatar Thomas Gummerer1-0/+7
Currently 'git worktree add <path>' creates a new branch named after the basename of the <path>, that matches the HEAD of whichever worktree we were on when calling "git worktree add <path>". It's sometimes useful to have 'git worktree add <path> behave more like the dwim machinery in 'git checkout <new-branch>', i.e. check if the new branch name, derived from the basename of the <path>, uniquely matches the branch name of a remote-tracking branch, and if so check out that branch and set the upstream to the remote-tracking branch. Add a new --guess-remote option that enables exactly that behaviour. Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-06RelNotes: the eighth batchLibravatar Junio C Hamano1-13/+45
Signed-off-by: Junio C Hamano <gitster@pobox.com>