summaryrefslogtreecommitdiff
path: root/Documentation/rev-list-options.txt
AgeCommit message (Collapse)AuthorFilesLines
2017-12-28Merge branch 'sb/describe-blob'Libravatar Junio C Hamano1-0/+5
"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-05rev-list: support --no-filter argumentLibravatar Jeff Hostetler1-5/+10
Teach rev-list to support --no-filter to override a previous --filter=<filter_spec> argument. This is to be consistent with commands that use OPT_PARSE macros. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-22rev-list: add list-objects filtering supportLibravatar Jeff Hostetler1-0/+36
Teach rev-list to use the filtering provided by the traverse_commit_list_filtered() interface to omit unwanted objects from the result. Object filtering is only allowed when one of the "--objects*" options are used. When the "--filter-print-omitted" option is used, the omitted objects are printed at the end. These are marked with a "~". This option can be combined with "--quiet" to get a list of just the omitted objects. Add t6112 test. In the future, we will introduce a "partial clone" mechanism wherein an object in a repo, obtained from a remote, may reference a missing object that can be dynamically fetched from that remote once needed. This "partial clone" mechanism will have a way, sometimes slow, of determining if a missing link is one of the links expected to be produced by this mechanism. This patch introduces handling of missing objects to help debugging and development of the "partial clone" mechanism, and once the mechanism is implemented, for a power user to perform operations that are missing-object aware without incurring the cost of checking if a missing link is expected. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Reviewed-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-16revision.h: introduce blob/tree walking in order of the commitsLibravatar Stefan Beller1-0/+5
The functionality to list tree objects in the order they were seen while traversing the commits will be used in one of the next commits, where we teach `git describe` to describe not only commits, but blobs, too. The change in list-objects.c is rather minimal as we'll be re-using the infrastructure put in place of the revision walking machinery. For example one could expect that add_pending_tree is not called, but rather commit->tree is directly passed to the tree traversal function. This however requires a lot more code than just emptying the queue containing trees after each commit. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-28Merge branch 'sg/rev-list-doc-reorder-fix'Libravatar Junio C Hamano1-3/+3
Doc flow fix. * sg/rev-list-doc-reorder-fix: rev-list-options.txt: use correct directional reference
2017-10-27rev-list-options.txt: use correct directional referenceLibravatar SZEDER Gábor1-3/+3
The descriptions of the options '--parents', '--children' and '--graph' say "see 'History Simplification' below", although the referred section is in fact above the description of these options. Send readers in the right direction by saying "above" instead of "below". Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-24rev-list: expose and document --single-worktreeLibravatar Nguyễn Thái Ngọc Duy1-0/+8
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-22Merge branch 'rs/strbuf-addftime-zZ'Libravatar Junio C Hamano1-1/+2
As there is no portable way to pass timezone information to strftime, some output format from "git log" and friends are impossible to produce. Teach our own strbuf_addftime to replace %z and %Z with caller-supplied values to help working around this. * rs/strbuf-addftime-zZ: date: use localtime() for "-local" time formats t0006: check --date=format zone offsets strbuf: let strbuf_addftime handle %z and %Z itself
2017-06-15strbuf: let strbuf_addftime handle %z and %Z itselfLibravatar René Scharfe1-1/+2
There is no portable way to pass timezone information to strftime. Add parameters for timezone offset and name to strbuf_addftime and let it handle the timezone-related format specifiers %z and %Z internally. Callers can opt out for %Z by passing NULL as timezone name. %z is always handled internally -- this helps on Windows, where strftime would expand it to a timezone name (same as %Z), in violation of POSIX. Modifiers are not handled, e.g. %Ez is still passed to strftime. Use an empty string as timezone name in show_date (the only current caller) for now because we only have the timezone offset in non-local mode. POSIX allows %Z to resolve to an empty string in case of missing information. Helped-by: Ulrich Mueller <ulm@gentoo.org> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-26log: add -P as a synonym for --perl-regexpLibravatar Ævar Arnfjörð Bjarmason1-0/+1
Add a short -P option as a synonym for the longer --perl-regexp, for consistency with the options the corresponding grep invocations accept. This was intentionally omitted in commit 727b6fc3ed ("log --grep: accept --basic-regexp and --perl-regexp", 2012-10-03) for unspecified future use. Make it consistent with "grep" rather than to keep it open for future use, and to avoid the confusion of -P meaning different things for grep & log, as is the case with the -G option. As noted in the aforementioned commit the --basic-regexp option can't have a corresponding -G argument, as the log command already uses that for -G<regex>. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-21grep & rev-list doc: stop promising libpcre for --perl-regexpLibravatar Ævar Arnfjörð Bjarmason1-2/+6
Stop promising in our grep & rev-list options documentation that we're always going to be using libpcre when given the --perl-regexp option. Instead talk about using "Perl-compatible regular expressions" and using these types of patterns using "a compile-time dependency". Saying "libpcre" means that we're talking about libpcre.so, which is always going to be v1. This change is part of an ongoing saga to add support for libpcre2, which comes with PCRE v2. In the future we might use some completely unrelated library to provide perl-compatible regular expression support. By wording the documentation differently and not promising any specific version of PCRE or even PCRE at all we have more wiggle room to change the implementation. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-08rev-list-options.txt: update --all about HEADLibravatar Nguyễn Thái Ngọc Duy1-2/+2
This is the document patch for f0298cf1c6 (revision walker: include a detached HEAD in --all - 2009-01-16). Even though that commit is about detached HEAD, as Jeff pointed out, always adding HEAD in that case may have subtle differences with --source or --exclude. So the document mentions nothing about the detached-ness. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-03Merge branch 'pb/rev-list-reverse-with-count'Libravatar Junio C Hamano1-2/+3
Doc update to clarify what "log -3 --reverse" does. * pb/rev-list-reverse-with-count: rev-list-options: clarify the usage of --reverse
2016-09-27rev-list-options: clarify the usage of --reverseLibravatar Pranit Bauva1-2/+3
Users often wonder if the oldest or the newest n commits are shown by `log -n --reverse`. Clarify that --reverse kicks in only after deciding which commits are to be shown to unconfuse them. Reported-by: Ruediger Meier <sweet_f_a@gmx.de> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-08Merge branch 'po/range-doc'Libravatar Junio C Hamano1-2/+2
Clarify various ways to specify the "revision ranges" in the documentation. * po/range-doc: doc: revisions: sort examples and fix alignment of the unchanged doc: revisions: show revision expansion in examples doc: revisions - clarify reachability examples doc: revisions - define `reachable` doc: gitrevisions - clarify 'latter case' is revision walk doc: gitrevisions - use 'reachable' in page description doc: revisions: single vs multi-parent notation comparison doc: revisions: extra clarification of <rev>^! notation effects doc: revisions: give headings for the two and three dot notations doc: show the actual left, right, and boundary marks doc: revisions - name the left and right sides doc: use 'symmetric difference' consistently
2016-08-08Merge branch 'jk/reflog-date'Libravatar Junio C Hamano1-7/+33
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-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-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-20doc: use 'symmetric difference' consistentlyLibravatar Philip Oakley1-2/+2
Signed-off-by: Philip Oakley <philipoakley@iee.org> 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-06-28doc: typeset '--' as literalLibravatar Matthieu Moy1-1/+1
This was obtained with: perl -pi -e "s/'--'/\`--\`/g" *.txt Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-05Merge branch 'jk/date-local'Libravatar Junio C Hamano1-7/+16
"git log --date=local" used to only show the normal (default) format in the local timezone. The command learned to take 'local' as an instruction to use the local timezone with other formats, e.g. "git show --date=rfc-local". * jk/date-local: t6300: add tests for "-local" date formats t6300: make UTC and local dates different date: make "local" orthogonal to date format date: check for "local" before anything else t6300: add test for "raw" date format t6300: introduce test_date() helper fast-import: switch crash-report date to iso8601 Documentation/rev-list: don't list date formats Documentation/git-for-each-ref: don't list date formats Documentation/config: don't list date formats Documentation/blame-options: don't list date formats
2015-09-03date: make "local" orthogonal to date formatLibravatar Jeff King1-6/+15
Most of our "--date" modes are about the format of the date: which items we show and in what order. But "--date=local" is a bit of an oddball. It means "show the date in the normal format, but using the local timezone". The timezone we use is orthogonal to the actual format, and there is no reason we could not have "localized iso8601", etc. This patch adds a "local" boolean field to "struct date_mode", and drops the DATE_LOCAL element from the date_mode_type enum (it's now just DATE_NORMAL plus local=1). The new feature is accessible to users by adding "-local" to any date mode (e.g., "iso-local"), and we retain "local" as an alias for "default-local" for backwards compatibility. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-03Documentation/rev-list: don't list date formatsLibravatar John Keeping1-1/+1
We are about to add several new date formats which will make this list too long to display in a single line. Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-31Merge branch 'jk/rev-list-has-no-notes'Libravatar Junio C Hamano1-0/+2
"git rev-list" does not take "--notes" option, but did not complain when one is given. * jk/rev-list-has-no-notes: rev-list: make it obvious that we do not support notes
2015-08-24rev-list: make it obvious that we do not support notesLibravatar Jeff King1-0/+2
The rev-list command does not have the internal infrastructure to display notes. Running: git rev-list --notes HEAD will silently ignore the "--notes" option. Running: git rev-list --notes --grep=. HEAD will crash on an assert. Running: git rev-list --format=%N HEAD will place a literal "%N" in the output (it does not even expand to an empty string). Let's have rev-list tell the user that it cannot fill the user's request, rather than silently producing wrong data. Likewise, let's remove mention of the notes options from the rev-list documentation. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-29introduce "format" date-modeLibravatar Jeff King1-0/+5
This feeds the format directly to strftime. Besides being a little more flexible, the main advantage is that your system strftime may know more about your locale's preferred format (e.g., how to spell the days of the week). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-04-28Merge branch 'mg/show-notes-doc'Libravatar Junio C Hamano1-2/+2
Documentation fix. * mg/show-notes-doc: rev-list-options.txt: complete sentence about notes matching
2015-04-17rev-list-options.txt: complete sentence about notes matchingLibravatar Michael J Gruber1-2/+2
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-25Merge branch 'dj/log-graph-with-no-walk'Libravatar Junio C Hamano1-0/+2
"git log --graph --no-walk A B..." is a otcnflicting request that asks nonsense; no-walk tells us show discrete points in the history, while graph asks to draw connections between these discrete points. Forbid the combination. * dj/log-graph-with-no-walk: revision: forbid combining --graph and --no-walk
2015-03-25Merge branch 'kd/rev-list-bisect-first-parent'Libravatar Junio C Hamano1-3/+4
"git rev-list --bisect --first-parent" does not work (yet) and can even cause SEGV; forbid it. "git log --bisect --first-parent" would not be useful until "git bisect --first-parent" materializes, so it is also forbidden for now. * kd/rev-list-bisect-first-parent: rev-list: refuse --first-parent combined with --bisect
2015-03-19rev-list: refuse --first-parent combined with --bisectLibravatar Kevin Daudt1-3/+4
rev-list --bisect is used by git bisect, but never together with --first-parent. Because rev-list --bisect together with --first-parent is not handled currently, and even leads to segfaults, refuse to use both options together. Because this is not supported, it makes little sense to use git log --bisect --first parent either, because refs/heads/bad is not limited to the first parent chain. Helped-by: Junio C. Hamano <gitster@pobox.com> Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Kevin Daudt <me@ikke.info> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-19revision: forbid combining --graph and --no-walkLibravatar Dongcan Jiang1-0/+2
Because "--graph" is about connected history while --no-walk is about discrete points, it does not make sense to allow these two options at the same time. [1] This change makes a few calls to "show --graph" fail in t4052, but asking to show one commit with graph is a nonsensical thing to do. Thus, tests on "show --graph" in t4052 have been removed [2,3]. Same tests on "show" without --graph option have already been tested in 4052. 3 testcases have been added to test this patch. [1]: http://article.gmane.org/gmane.comp.version-control.git/216083 [2]: http://article.gmane.org/gmane.comp.version-control.git/264950 [3]: http://article.gmane.org/gmane.comp.version-control.git/265107 Helped-By: Eric Sunshine <sunshine@sunshineco.com> Helped-By: René Scharfe <l.s.r@web.de> Helped-By: Junio C Hamano <gitster@pobox.com> Signed-off-by: Dongcan Jiang <dongcan.jiang@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-02-17Merge branch 'jc/doc-log-rev-list-options'Libravatar Junio C Hamano1-5/+7
"git log --help" used to show rev-list options that are irrelevant to the "log" command. * jc/doc-log-rev-list-options: Documentation: what does "git log --indexed-objects" even mean?
2015-02-11Merge branch 'cj/log-invert-grep'Libravatar Junio C Hamano1-0/+4
"git log --invert-grep --grep=WIP" will show only commits that do not have the string "WIP" in their messages. * cj/log-invert-grep: log: teach --invert-grep option
2015-01-23Documentation: what does "git log --indexed-objects" even mean?Libravatar Junio C Hamano1-5/+7
4fe10219 (rev-list: add --indexed-objects option, 2014-10-16) adds "--indexed-objects" option to "rev-list", and it is only useful in the context of "git rev-list" and not "git log". There are other object traversal options that do not make sense for "git log" that are shown in the manual page. Move the description of "--indexed-objects" to the object traversal section so that it sits together with its friends "--objects", "--objects-edge", etc. and then show them only in "git rev-list" documentation. Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-13log: teach --invert-grep optionLibravatar Christoph Junghans1-0/+4
"git log --grep=<string>" shows only commits with messages that match the given string, but sometimes it is useful to be able to show only commits that do *not* have certain messages (e.g. "show me ones that are not FIXUP commits"). Originally, we had the invert-grep flag in grep_opt, but because "git grep --invert-grep" does not make sense except in conjunction with "--files-with-matches", which is already covered by "--files-without-matches", it was moved it to revisions structure. To have the flag there expresses the function to the feature better. When the newly inserted two tests run, the history would have commits with messages "initial", "second", "third", "fourth", "fifth", "sixth" and "Second", committed in this order. The commits that does not match either "th" or "Sec" is "second" and "initial". For the case insensitive case only "initial" matches. Signed-off-by: Christoph Junghans <ottxor@gentoo.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-29pack-objects: use --objects-edge-aggressive for shallow reposLibravatar brian m. carlson1-1/+2
When fetching into or pushing from a shallow repository, we want to aggressively mark edges as uninteresting, since this decreases the pack size. However, aggressively marking edges can negatively affect performance on large non-shallow repositories with lots of refs. Teach pack-objects a --shallow option to indicate that we're pushing from or fetching into a shallow repository. Use --objects-edge-aggressive only for shallow repositories and otherwise use --objects-edge, which performs better in the general case. Update the callers to pass the --shallow option when they are dealing with a shallow repository. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-29rev-list: add an option to mark fewer edges as uninterestingLibravatar brian m. carlson1-0/+4
In commit fbd4a70 (list-objects: mark more commits as edges in mark_edges_uninteresting - 2013-08-16), we marked an increasing number of edges uninteresting. This change, and the subsequent change to make this conditional on --objects-edge, are used by --thin to make much smaller packs for shallow clones. Unfortunately, they cause a significant performance regression when pushing non-shallow clones with lots of refs (23.322 seconds vs. 4.785 seconds with 22400 refs). Add an option to git rev-list, --objects-edge-aggressive, that preserves this more aggressive behavior, while leaving --objects-edge to provide more performant behavior. Preserve the current behavior for the moment by using the aggressive option. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-22Documentation: add missing article in rev-list-options.txtLibravatar brian m. carlson1-1/+1
Add the missing article "a". Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-04Documentation: typofixesLibravatar Thomas Ackermann1-1/+1
In addition to fixing trivial and obvious typos, be careful about the following points: - Spell ASCII, URL and CRC in ALL CAPS; - Spell Linux as Capitalized; - Do not omit periods in "i.e." and "e.g.". Signed-off-by: Thomas Ackermann <th.acker@arcor.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-19rev-list: add --indexed-objects optionLibravatar Jeff King1-0/+5
There is currently no easy way to ask the revision traversal machinery to include objects reachable from the index (e.g., blobs and trees that have not yet been committed). This patch adds an option to do so. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-19rev-list: document --reflog optionLibravatar Jeff King1-0/+4
This is mostly used internally, but it does not hurt to explain it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-08-29pretty: provide a strict ISO 8601 date formatLibravatar Beat Bolli1-2/+11
Git's "ISO" date format does not really conform to the ISO 8601 standard due to small differences, and it cannot be parsed by ISO 8601-only parsers, e.g. those of XML toolchains. The output from "--date=iso" deviates from ISO 8601 in these ways: - a space instead of the `T` date/time delimiter - a space between time and time zone - no colon between hours and minutes of the time zone Add a strict ISO 8601 date format for displaying committer and author dates. Use the '%aI' and '%cI' format specifiers and add '--date=iso-strict' or '--date=iso8601-strict' date format names. See http://thread.gmane.org/gmane.comp.version-control.git/255879 and http://thread.gmane.org/gmane.comp.version-control.git/52414/focus=52585 for discussion. Signed-off-by: Beat Bolli <bbolli@ewanet.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-08Merge branch 'jl/nor-or-nand-and'Libravatar Junio C Hamano1-1/+1
Eradicate mistaken use of "nor" (that is, essentially "nor" used not in "neither A nor B" ;-)) from in-code comments, command output strings, and documentations. * jl/nor-or-nand-and: code and test: fix misuses of "nor" comments: fix misuses of "nor" contrib: fix misuses of "nor" Documentation: fix misuses of "nor"
2014-04-03Merge branch 'nd/log-show-linear-break'Libravatar Junio C Hamano1-0/+7
Attempts to show where a single-strand-of-pearls break in "git log" output. * nd/log-show-linear-break: log: add --show-linear-break to help see non-linear history object.h: centralize object flag allocation
2014-03-31Documentation: fix misuses of "nor"Libravatar Justin Lebar1-1/+1
Signed-off-by: Justin Lebar <jlebar@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>