summaryrefslogtreecommitdiff
path: root/Documentation
AgeCommit message (Collapse)AuthorFilesLines
2016-08-10Twelfth batch for 2.10Libravatar Junio C Hamano1-20/+21
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-10Merge branch 'jt/format-patch-from-config'Libravatar Junio C Hamano1-0/+10
"git format-patch" learned format.from configuration variable to specify the default settings for its "--from" option. * jt/format-patch-from-config: format-patch: format.from gives the default for --from
2016-08-10Merge branch 'jk/push-force-with-lease-creation'Libravatar Junio C Hamano1-2/+3
"git push --force-with-lease" already had enough logic to allow ensuring that such a push results in creation of a ref (i.e. the receiving end did not have another push from sideways that would be discarded by our force-pushing), but didn't expose this possibility to the users. It does so now. * jk/push-force-with-lease-creation: t5533: make it pass on case-sensitive filesystems push: allow pushing new branches with --force-with-lease push: add shorthand for --force-with-lease branch creation Documentation/git-push: fix placeholder formatting
2016-08-08Sync with maintLibravatar Junio C Hamano1-0/+34
* maint: Hopefully final batch for 2.9.3
2016-08-08Eleventh batch for 2.10Libravatar Junio C Hamano1-20/+65
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-08Merge branch 'jc/hashmap-doc-init'Libravatar Junio C Hamano1-0/+5
The API documentation for hashmap was unclear if hashmap_entry can be safely discarded without any other consideration. State that it is safe to do so. * jc/hashmap-doc-init: hashmap: clarify that hashmap_entry can safely be discarded
2016-08-08Merge branch 'sb/submodule-recommend-shallowness'Libravatar Junio C Hamano1-0/+5
Doc update. * sb/submodule-recommend-shallowness: gitmodules: document shallow recommendation
2016-08-08Merge branch 'jh/clean-smudge-f-doc'Libravatar Junio C Hamano1-0/+5
A minor documentation update. * jh/clean-smudge-f-doc: clarify %f documentation
2016-08-08Merge branch 'jk/reflog-date'Libravatar Junio C Hamano2-9/+41
The reflog output format is documented better, and a new format --date=unix to report the seconds-since-epoch (without timezone) has been added. * jk/reflog-date: date: clarify --date=raw description date: add "unix" format date: document and test "raw-local" mode doc/pretty-formats: explain shortening of %gd doc/pretty-formats: describe index/time formats for %gd doc/rev-list-options: explain "-g" output formats doc/rev-list-options: clarify "commit@{Nth}" for "-g" option
2016-08-08Hopefully final batch for 2.9.3Libravatar Junio C Hamano1-0/+34
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-08Merge branch 'sb/pack-protocol-doc-nak' into maintLibravatar Junio C Hamano1-1/+1
A doc update. * sb/pack-protocol-doc-nak: Documentation: pack-protocol correct NAK response
2016-08-08Merge branch 'jc/doc-diff-filter-exclude' into maintLibravatar Junio C Hamano1-0/+3
Belated doc update for a feature added in v1.8.5. * jc/doc-diff-filter-exclude: diff: document diff-filter exclusion
2016-08-04Tenth batch for 2.10Libravatar Junio C Hamano1-0/+6
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-04Merge branch 'sb/pack-protocol-doc-nak'Libravatar Junio C Hamano1-1/+1
A doc update. * sb/pack-protocol-doc-nak: Documentation: pack-protocol correct NAK response
2016-08-03Ninth batch of topics for 2.10Libravatar Junio C Hamano1-0/+61
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-03Merge branch 'jk/push-progress'Libravatar Junio C Hamano2-0/+13
"git push" and "git clone" learned to give better progress meters to the end user who is waiting on the terminal. * jk/push-progress: receive-pack: send keepalives during quiet periods receive-pack: turn on connectivity progress receive-pack: relay connectivity errors to sideband receive-pack: turn on index-pack resolving progress index-pack: add flag for showing delta-resolution progress clone: use a real progress meter for connectivity check check_connected: add progress flag check_connected: relay errors to alternate descriptor check_everything_connected: use a struct with named options check_everything_connected: convert to argv_array rev-list: add optional progress reporting check_everything_connected: always pass --quiet to rev-list
2016-08-03Merge branch 'sb/push-options'Libravatar Junio C Hamano5-7/+47
"git push" learned to accept and pass extra options to the receiving end so that hooks can read and react to them. * sb/push-options: add a test for push options push: accept push options receive-pack: implement advertising and receiving push options push options: {pre,post}-receive hook learns about push options
2016-08-03clarify %f documentationLibravatar Joey Hess1-0/+5
It's natural to expect %f to be an actual file on disk; help avoid that mistake. Signed-off-by: Joey Hess <joeyh@joeyh.name> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-03gitmodules: document shallow recommendationLibravatar Stefan Beller1-0/+5
Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-02hashmap: clarify that hashmap_entry can safely be discardedLibravatar Junio C Hamano1-0/+5
The API documentation said that the hashmap_entry structure to be embedded in the caller's structure is to be treated as opaque, which left the reader wondering if it can safely be discarded when it no longer is necessary. If the hashmap_entry structure had references to external resources such as allocated memory or an open file descriptor, merely free(3)ing the containing structure (when the caller's structure is on the heap) or letting it go out of scope (when it is on the stack) would end up leaking the external resource. Document that there is no need for hashmap_entry_clear() that corresponds to hashmap_entry_init() to give the API users a little bit of peace of mind. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-01format-patch: format.from gives the default for --fromLibravatar Josh Triplett1-0/+10
This helps users who would prefer format-patch to default to --from, and makes it easier to change the default in the future. Signed-off-by: Josh Triplett <josh@joshtriplett.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-28Sync with maintLibravatar Junio C Hamano1-0/+58
* maint: Some fixes for 2.9.3
2016-07-28Eighth batch of topics for 2.10Libravatar Junio C Hamano1-19/+34
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-28Merge branch 'master' of git://git.bogomips.org/git-svnLibravatar Junio C Hamano1-0/+3
* 'master' of git://git.bogomips.org/git-svn: git-svn: allow --version to work anywhere git-svn: document svn.authorsProg in config
2016-07-28Some fixes for 2.9.3Libravatar Junio C Hamano1-0/+58
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-28Merge branch 'nd/doc-new-command' into maintLibravatar Junio C Hamano1-1/+1
Typofix in a doc. * nd/doc-new-command: new-command.txt: correct the command description file
2016-07-28Merge branch 'mm/doc-tt' into maintLibravatar Junio C Hamano62-227/+228
More mark-up updates to typeset strings that are expected to literally typed by the end user in fixed-width font. * mm/doc-tt: doc: typeset HEAD and variants as literal CodingGuidelines: formatting HEAD in documentation doc: typeset long options with argument as literal doc: typeset '--' as literal doc: typeset long command-line options as literal doc: typeset short command-line options as literal Documentation/git-mv.txt: fix whitespace indentation
2016-07-28Merge branch 'nd/worktree-lock'Libravatar Junio C Hamano1-6/+30
"git worktree prune" protected worktrees that are marked as "locked" by creating a file in a known location. "git worktree" command learned a dedicated command pair to create and remove such a file, so that the users do not have to do this with editor. * nd/worktree-lock: worktree.c: find_worktree() search by path suffix worktree: add "unlock" command worktree: add "lock" command worktree.c: add is_worktree_locked() worktree.c: add is_main_worktree() worktree.c: add find_worktree()
2016-07-27date: clarify --date=raw descriptionLibravatar Junio C Hamano1-1/+5
"... in the internal raw Git format `%s %z` format." was clunky in repeating "format" twice, and would not have helped those who do not immediately get that these are strftime(3) conversion specifiers. Explain them with words, and demote the mention of `%s %z` to a hint to help those who know them. Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-27date: add "unix" formatLibravatar Jeff King1-0/+4
We already have "--date=raw", which is a Unix epoch timestamp plus a contextual timezone (either the author's or the local). But one may not care about the timezone and just want the epoch timestamp by itself. It's not hard to parse the two apart, but if you are using a pretty-print format, you may want git to show the "finished" form that the user will see. We can accomodate this by adding a new date format, "unix", which is basically "raw" without the timezone. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-27date: document and test "raw-local" modeLibravatar Jeff King1-2/+5
The "raw" format shows a Unix epoch timestamp, but with a timezone tacked on. The timestamp is not _in_ that zone, but it is extra information about the time (by default, the zone the author was in). The documentation claims that "raw-local" does not work. It does, but the end result is rather subtle. Let's describe it in better detail, and test to make sure it works (namely, the epoch time doesn't change, but the zone does). While we are rewording the documentation in this area, let's not use the phrase "does not work" for the remaining option, "--date=relative". It's vague; do we accept it or not? We do accept it, but it has no effect (which is a reasonable outcome). We should also refer to the option not as "--relative" (which is the historical synonym, and does not take "-local" at all), but as "--date=relative". Helped-by: Jakub Narębski <jnareb@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-26push: add shorthand for --force-with-lease branch creationLibravatar John Keeping1-1/+2
Allow the empty string to stand in for the null SHA-1 when pushing a new branch, like we do when deleting branches. This means that the following command ensures that `new-branch` is created on the remote (that is, is must not already exist): git push --force-with-lease=new-branch: origin new-branch Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-25Documentation/git-push: fix placeholder formattingLibravatar John Keeping1-1/+1
Format the placeholder as monospace to match other occurrences in this file and obey CodingGuidelines. Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-25Seventh batch of topics for 2.10Libravatar Junio C Hamano1-0/+69
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-25Merge branch 'js/fsck-name-object'Libravatar Junio C Hamano1-1/+8
When "git fsck" reports a broken link (e.g. a tree object contains a blob that does not exist), both containing object and the object that is referred to were reported with their 40-hex object names. The command learned the "--name-objects" option to show the path to the containing object from existing refs (e.g. "HEAD~24^2:file.txt"). * js/fsck-name-object: fsck: optionally show more helpful info for broken links fsck: give the error function a chance to see the fsck_options fsck_walk(): optionally name objects on the go fsck: refactor how to describe objects
2016-07-25Merge branch 'jc/doc-diff-filter-exclude'Libravatar Junio C Hamano1-0/+3
Belated doc update for a feature added in v1.8.5. * jc/doc-diff-filter-exclude: diff: document diff-filter exclusion
2016-07-25Merge branch 'jc/renormalize-merge-kill-safer-crlf'Libravatar Junio C Hamano2-13/+14
"git merge" with renormalization did not work well with merge-recursive, due to "safer crlf" conversion kicking in when it shouldn't. * jc/renormalize-merge-kill-safer-crlf: merge: avoid "safer crlf" during recording of merge results convert: unify the "auto" handling of CRLF
2016-07-22doc/pretty-formats: explain shortening of %gdLibravatar Jeff King1-3/+6
The actual shortening rules aren't that interesting and probably not worth getting into (I gloss over them here as "shortened for human readability"). But the fact that %gD shows whatever you gave on the command line is subtle and worth mentioning. Since most people will feed a shortened refname in the first place, it otherwise makes it hard to understand the difference between the two. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-22doc/pretty-formats: describe index/time formats for %gdLibravatar Jeff King1-2/+5
The "reflog selector" format changes based on a series of heuristics, and that applies equally to both stock "log -g" output, as well as "--format=%gd". The documentation for "%gd" doesn't cover this. Let's mention the multiple formats and refer the user back to the "-g" section for the complete rules. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-22doc/rev-list-options: explain "-g" output formatsLibravatar Jeff King1-4/+19
We document that asking for HEAD@{now} will switch the output to show HEAD@{timestamp}, but not that specifying `--date` has a similar effect, or that it can be overridden with HEAD@{0}. Let's do so. These rules come from 794151e (reflog-walk: always make HEAD@{0} show indexed selectors, 2012-05-04), though that is simply the culmination of years of these heuristics growing organically. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-22doc/rev-list-options: clarify "commit@{Nth}" for "-g" optionLibravatar Jeff King1-2/+2
When "log -g" shows "HEAD@{1}", "HEAD@{2}", etc, calling that "commit@{Nth}" is not really accurate. The "HEAD" part is really the refname. By saying "commit", a reader may misunderstand that to mean something related to the specific commit we are showing, not the ref whose reflog we are traversing. While we're here, let's also switch these instances to use literal backticks, as our style guide recommends. As a bonus, that lets us drop some asciidoc quoting. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-22Documentation: pack-protocol correct NAK responseLibravatar Stefan Beller1-1/+1
In the transport protocol we use NAK to signal the non existence of a common base, so fix the documentation. This helps readers of the document, as they don't have to wonder about the difference between NAK and NACK. As NACK is used in git archive and upload-archive, this is easy to get wrong. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-20receive-pack: send keepalives during quiet periodsLibravatar Jeff King1-0/+9
After a client has sent us the complete pack, we may spend some time processing the data and running hooks. If the client asked us to be quiet, receive-pack won't send any progress data during the index-pack or connectivity-check steps. And hooks may or may not produce their own progress output. In these cases, the network connection is totally silent from both ends. Git itself doesn't care about this (it will wait forever), but other parts of the system (e.g., firewalls, load-balancers, etc) might hang up the connection. So we'd like to send some sort of keepalive to let the network and the client side know that we're still alive and processing. We can use the same trick we did in 05e9515 (upload-pack: send keepalive packets during pack computation, 2013-09-08). Namely, we will send an empty sideband data packet every `N` seconds that we do not relay any stderr data over the sideband channel. As with 05e9515, this means that we won't bother sending keepalives when there's actual progress data, but will kick in when it has been disabled (or if there is a lull in the progress data). The concept is simple, but the details are subtle enough that they need discussing here. Before the client sends us the pack, we don't want to do any keepalives. We'll have sent our ref advertisement, and we're waiting for them to send us the pack (and tell us that they support sidebands at all). While we're receiving the pack from the client (or waiting for it to start), there's no need for keepalives; it's up to them to keep the connection active by sending data. Moreover, it would be wrong for us to do so. When we are the server in the smart-http protocol, we must treat our connection as half-duplex. So any keepalives we send while receiving the pack would potentially be buffered by the webserver. Not only does this make them useless (since they would not be delivered in a timely manner), but it could actually cause a deadlock if we fill up the buffer with keepalives. (It wouldn't be wrong to send keepalives in this phase for a full-duplex connection like ssh; it's simply pointless, as it is the client's responsibility to speak). As soon as we've gotten all of the pack data, then the client is waiting for us to speak, and we should start keepalives immediately. From here until the end of the connection, we send one any time we are not otherwise sending data. But there's a catch. Receive-pack doesn't know the moment we've gotten all the data. It passes the descriptor to index-pack, who reads all of the data, and then starts resolving the deltas. We have to communicate that back. To make this work, we instruct the sideband muxer to enable keepalives in three phases: 1. In the beginning, not at all. 2. While reading from index-pack, wait for a signal indicating end-of-input, and then start them. 3. Afterwards, always. The signal from index-pack in phase 2 has to come over the stderr channel which the muxer is reading. We can't use an extra pipe because the portable run-command interface only gives us stderr and stdout. Stdout is already used to pass the .keep filename back to receive-pack. We could also send a signal there, but then we would find out about it in the main thread. And the keepalive needs to be done by the async muxer thread (since it's the one writing sideband data back to the client). And we can't reliably signal the async thread from the main thread, because the async code sometimes uses threads and sometimes uses forked processes. Therefore the signal must come over the stderr channel, where it may be interspersed with other random human-readable messages from index-pack. This patch makes the signal a single NUL byte. This is easy to parse, should not appear in any normal stderr output, and we don't have to worry about any timing issues (like seeing half the signal bytes in one read(), and half in a subsequent one). This is a bit ugly, but it's simple to code and should work reliably. Another option would be to stop using an async thread for muxing entirely, and just poll() both stderr and stdout of index-pack from the main thread. This would work for index-pack (because we aren't doing anything useful in the main thread while it runs anyway). But it would make the connectivity check and the hook muxers much more complicated, as they need to simultaneously feed the sub-programs while reading their stderr. The index-pack phase is the only one that needs this signaling, so it could simply behave differently than the other two. That would mean having two separate implementations of copy_to_sideband (and the keepalive code), though. And it still doesn't get rid of the signaling; it just means we can write a nicer message like "END_OF_INPUT" or something on stdout, since we don't have to worry about separating it from the stderr cruft. One final note: this signaling trick is only done with index-pack, not with unpack-objects. There's no point in doing it for the latter, because by definition it only kicks in for a small number of objects, where keepalives are not as useful (and this conveniently lets us avoid duplicating the implementation). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-20rev-list: add optional progress reportingLibravatar Jeff King1-0/+4
It's easy to ask rev-list to do a traversal that may takes many seconds (e.g., by calling "--objects --all"). In theory you can monitor its progress by the output you get to stdout, but this isn't always easy. Some operations, like "--count", don't make any output until the end. And some callers, like check_everything_connected(), are using it just for the error-checking of the traversal, and throw away stdout entirely. This patch adds a "--progress" option which can be used to give some eye-candy for a user waiting for a long traversal. This is just a rev-list option and not a regular traversal option, because it needs cooperation from the callbacks in builtin/rev-list.c to do the actual count. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-19Sixth batch of topics for 2.10Libravatar Junio C Hamano1-0/+70
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-19Merge branch 'nd/fetch-ref-summary'Libravatar Junio C Hamano2-0/+56
Improve the look of the way "git fetch" reports what happened to each ref that was fetched. * nd/fetch-ref-summary: fetch: reduce duplicate in ref update status lines with placeholder fetch: align all "remote -> local" output fetch: change flag code for displaying tag update and deleted ref fetch: refactor ref update status formatting code git-fetch.txt: document fetch output
2016-07-19Merge branch 'nd/connect-ssh-command-config'Libravatar Junio C Hamano1-0/+7
A new configuration variable core.sshCommand has been added to specify what value for GIT_SSH_COMMAND to use per repository. * nd/connect-ssh-command-config: connect: read $GIT_SSH_COMMAND from config file
2016-07-19git-svn: document svn.authorsProg in configLibravatar Eric Wong1-0/+3
This has always been supported since we read config variables based on the command-line option parser. Document it explicitly since users usually want to maintain the same program across invocations. Signed-off-by: Eric Wong <e@80x24.org>
2016-07-18fsck: optionally show more helpful info for broken linksLibravatar Johannes Schindelin1-1/+8
When reporting broken links between commits/trees/blobs, it would be quite helpful at times if the user would be told how the object is supposed to be reachable. With the new --name-objects option, git-fsck will try to do exactly that: name the objects in a way that shows how they are reachable. For example, when some reflog got corrupted and a blob is missing that should not be, the user might want to remove the corresponding reflog entry. This option helps them find that entry: `git fsck` will now report something like this: broken link from tree b5eb6ff... (refs/stash@{<date>}~37:) to blob ec5cf80... Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-15Sync with 2.9.2Libravatar Junio C Hamano2-1/+15
* maint: Git 2.9.2 t0006: skip "far in the future" test when unsigned long is not long enough