Commit Graph

51 Commits

Author SHA1 Message Date
Junio C Hamano
44a6b6ce17 ref-filter: resurrect "strip" as a synonym to "lstrip"
We forgot that "strip" was introduced at 0571979bd6 ("tag: do not
show ambiguous tag names as "tags/foo"", 2016-01-25) as part of Git
2.8 (and 2.7.1) when we started calling this "lstrip" to make it
easier to explain the new "rstrip" operation.

We shouldn't have renamed the existing one; "lstrip" should have
been a new synonym that means the same thing as "strip".  Scripts
in the wild are surely using the original form already.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-07 11:50:34 -08:00
Karthik Nayak
1a34728e6b ref-filter: add an 'rstrip=<N>' option to atoms which deal with refnames
Complimenting the existing 'lstrip=<N>' option, add an 'rstrip=<N>'
option which strips `<N>` slash-separated path components from the end
of the refname (e.g., `%(refname:rstrip=2)` turns `refs/tags/foo` into
`refs`).

Signed-off-by: Karthik Nayak <Karthik.188@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-31 12:42:33 -08:00
Karthik Nayak
1a0ca5e358 ref-filter: modify the 'lstrip=<N>' option to work with negative '<N>'
Currently the 'lstrip=<N>' option only takes a positive value '<N>'
and strips '<N>' slash-separated path components from the left. Modify
the 'lstrip' option to also take a negative number '<N>' which would
strip from the left as necessary and _leave_ behind only 'N'
slash-separated path components from the right-most end.

For e.g. %(refname:lstrip=-1) would make 'foo/goo/abc' into 'abc'.

Add documentation and tests for the same.

Signed-off-by: Karthik Nayak <Karthik.188@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-31 12:38:59 -08:00
Karthik Nayak
3a42980f9e ref-filter: Do not abruptly die when using the 'lstrip=<N>' option
Currently when we use the 'lstrip=<N>' option, if 'N' is greater than
the number of components available in the refname, we abruptly end
program execution by calling die().

This behavior is undesired since a single refname with few components
could end program execution. To avoid this, return an empty string
whenever the value 'N' is greater than the number of components
available, instead of calling die().

Signed-off-by: Karthik Nayak <Karthik.188@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-10 12:44:31 -08:00
Karthik Nayak
17938f171f ref-filter: rename the 'strip' option to 'lstrip'
In preparation for the upcoming patch, where we introduce the 'rstrip'
option. Rename the 'strip' option to 'lstrip' to remove ambiguity.

Signed-off-by: Karthik Nayak <Karthik.188@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-10 12:44:31 -08:00
Karthik Nayak
3ba308cb4b ref-filter: make remote_ref_atom_parser() use refname_atom_parser_internal()
Use the recently introduced refname_atom_parser_internal() within
remote_ref_atom_parser(), this provides a common base for all the ref
printing atoms, allowing %(upstream) and %(push) to also use the
':strip' option.

The atoms '%(push)' and '%(upstream)' will retain the ':track' and
':trackshort' atom modifiers to themselves as they have no meaning in
context to the '%(refname)' and '%(symref)' atoms.

Update the documentation and tests to reflect the same.

Signed-off-by: Karthik Nayak <Karthik.188@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-10 12:44:31 -08:00
Karthik Nayak
a798410184 ref-filter: introduce refname_atom_parser()
Using refname_atom_parser_internal(), introduce refname_atom_parser()
which will parse the %(symref) and %(refname) atoms. Store the parsed
information into the 'used_atom' structure based on the modifiers used
along with the atoms.

Now the '%(symref)' atom supports the ':strip' atom modifier. Update the
Documentation and tests to reflect this.

Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Karthik Nayak <Karthik.188@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-10 12:44:31 -08:00
Karthik Nayak
01f95825d5 ref-filter: make "%(symref)" atom work with the ':short' modifier
The "%(symref)" atom doesn't work when used with the ':short' modifier
because we strictly match only 'symref' for setting the 'need_symref'
indicator. Fix this by comparing with the valid_atom rather than the
used_atom.

Add tests for %(symref) and %(symref:short) while we're here.

Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Karthik Nayak <Karthik.188@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-10 12:44:31 -08:00
Karthik Nayak
7743fcca5b ref-filter: add support for %(upstream:track,nobracket)
Add support for %(upstream:track,nobracket) which will print the
tracking information without the brackets (i.e. "ahead N, behind M").
This is needed when we port branch.c to use ref-filter's printing APIs.

Add test and documentation for the same.

Mentored-by: Christian Couder <christian.couder@gmail.com>
Mentored-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
Signed-off-by: Karthik Nayak <karthik.188@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-10 12:44:31 -08:00
Karthik Nayak
ffd921d311 ref-filter: make %(upstream:track) prints "[gone]" for invalid upstreams
Borrowing from branch.c's implementation print "[gone]" whenever an
unknown upstream ref is encountered instead of just ignoring it.

This makes sure that when branch.c is ported over to using ref-filter
APIs for printing, this feature is not lost.

Make changes to t/t6300-for-each-ref.sh and
Documentation/git-for-each-ref.txt to reflect this change.

Mentored-by: Christian Couder <christian.couder@gmail.com>
Mentored-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
Helped-by : Jacob Keller <jacob.keller@gmail.com>
Signed-off-by: Karthik Nayak <karthik.188@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-10 12:44:31 -08:00
Karthik Nayak
42d0eb05ee ref-filter: modify "%(objectname:short)" to take length
Add support for %(objectname:short=<length>) which would print the
abbreviated unique objectname of given length. When no length is
specified, the length is 'DEFAULT_ABBREV'. The minimum length is
'MINIMUM_ABBREV'. The length may be exceeded to ensure that the
provided object name is unique.

Add tests and documentation for the same.

Mentored-by: Christian Couder <christian.couder@gmail.com>
Mentored-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
Helped-by: Jacob Keller <jacob.keller@gmail.com>
Signed-off-by: Karthik Nayak <karthik.188@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-10 12:44:31 -08:00
Junio C Hamano
f008159fc2 Merge branch 'jk/trailers-placeholder-in-pretty'
In addition to %(subject), %(body), "log --pretty=format:..."
learned a new placeholder %(trailers).

* jk/trailers-placeholder-in-pretty:
  ref-filter: add support to display trailers as part of contents
  pretty: add %(trailers) format for displaying trailers of a commit message
2016-12-19 14:45:34 -08:00
Jacob Keller
b1d31c8954 ref-filter: add support to display trailers as part of contents
Add %(trailers) and %(contents:trailers) to display the trailers as
interpreted by trailer_info_get. Update documentation and add a test for
the new feature.

Signed-off-by: Jacob Keller <jacob.keller@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-11 13:58:41 -08:00
Junio C Hamano
84679d470d for-each-ref: do not segv with %(HEAD) on an unborn branch
The code to flip between "*" and " " prefixes depending on what
branch is checked out used in --format='%(HEAD)' did not consider
that HEAD may resolve to an unborn branch and dereferenced a NULL.

This will become a lot easier to trigger as the codepath will be
used to reimplement "git branch [--list]" in the future.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-11-18 15:21:12 -08:00
Jeff King
0571979bd6 tag: do not show ambiguous tag names as "tags/foo"
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-26 13:34:10 -08:00
Jeff King
1d094db936 t6300: use test_atom for some un-modern tests
Because this script has to test so many formatters, we have
the nice "test_atom" helper, but we don't use it
consistently. Let's do so. This is shorter, gets rid of some
tests that have their "expected" setup outside of a
test_expect_success block, and lets us organize the changes
better (e.g., putting "refname:short" near "refname").

We also expand the "%(push)" tests a little to match the
"%(upstream)" ones.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-25 12:33:45 -08:00
Junio C Hamano
7b09c459d3 Merge branch 'jk/date-local'
"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-10-05 12:30:13 -07:00
John Keeping
99264e93fc t6300: add tests for "-local" date formats
Signed-off-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-03 15:46:55 -07:00
John Keeping
db7bae25ed t6300: make UTC and local dates different
By setting the UTC time to 23:18:43 the date in +0200 is the following
day, 2006-07-04.  This will ensure that the test for "short-local" to be
added in the following patch tests for different output from the "short"
format.

Signed-off-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-03 15:45:35 -07:00
John Keeping
f3c1ba5026 t6300: add test for "raw" date format
Signed-off-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-03 15:36:57 -07:00
John Keeping
f95cecf433 t6300: introduce test_date() helper
This moves the setup of the "expected" file inside the test case.  The
helper function has the advantage that we can use SQ in the file content
without needing to escape the quotes.

Signed-off-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-03 15:36:38 -07:00
Jeff King
e4f031e34b strbuf: make strbuf_addftime more robust
The return value of strftime is poorly designed; when it
returns 0, the caller cannot tell if the buffer was not
large enough, or if the output was actually 0 bytes. In the
original implementation of strbuf_addftime, we simply punted
and guessed that our 128-byte hint would be large enough.

We can do better, though, if we're willing to treat strftime
like less of a black box. We can munge the incoming format
to make sure that it never produces 0-length output, and
then "fix" the resulting output.  That lets us reliably grow
the buffer based on strftime's return value.

Clever-idea-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-20 22:17:06 -07:00
Jeff King
aa1462cc3d introduce "format" date-mode
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-06-29 11:39:10 -07:00
Jeff King
29bc88505f for-each-ref: accept "%(push)" format
Just as we have "%(upstream)" to report the "@{upstream}"
for each ref, this patch adds "%(push)" to match "@{push}".
It supports the same tracking format modifiers as upstream
(because you may want to know, for example, which branches
have commits to push).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-22 09:33:09 -07:00
Raphael Kubo da Costa
b6160d950c for-each-ref: always check stat_tracking_info()'s return value
The code handling %(upstream:track) and %(upstream:trackshort)
assumed that it always had a valid branch that had been sanitized
earlier in populate_value(), and thus did not check the return value
of the call to stat_tracking_info().

While there is indeed some sanitization code that basically
corresponds to stat_tracking_info() returning 0 (no base branch
set), the function can also return -1 when the base branch did exist
but has since then been deleted.

In this case, num_ours and num_theirs had undefined values and a
call to `git for-each-ref --format="%(upstream:track)"` could print
spurious values such as

  [behind -111794512]
  [ahead 38881640, behind 5103867]

even for repositories with one single commit.

Verify stat_tracking_info()'s return value and do not print anything
if it returns -1. This behavior also matches the documentation ("has
no effect if the ref does not have tracking information associated
with it").

Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-12 15:10:46 -08:00
Junio C Hamano
cb6bd5722f Merge branch 'rr/for-each-ref-decoration'
Add a few formatting directives to "git for-each-ref --format=...",
to paint them in color, etc.

* rr/for-each-ref-decoration:
  for-each-ref: avoid color leakage
  for-each-ref: introduce %(color:...) for color
  for-each-ref: introduce %(upstream:track[short])
  for-each-ref: introduce %(HEAD) asterisk marker
  t6300 (for-each-ref): don't hardcode SHA-1 hexes
  t6300 (for-each-ref): clearly demarcate setup
2013-12-06 11:07:21 -08:00
Ramkumar Ramachandra
db64eb655b for-each-ref: avoid color leakage
To make sure that an invocation like the following doesn't leak color,

  $ git for-each-ref --format='%(subject)%(color:green)'

auto-reset at the end of the format string when the last color token
seen in the format string isn't a color-reset.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-11-19 10:14:15 -08:00
Ramkumar Ramachandra
fddb74c947 for-each-ref: introduce %(color:...) for color
Enhance 'git for-each-ref' with color formatting options.  You can now
use the following format in for-each-ref:

  %(color:green)%(refname:short)%(color:reset)

where color names are described in color.branch.*.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-11-19 10:14:15 -08:00
Ramkumar Ramachandra
b28061ce0d for-each-ref: introduce %(upstream:track[short])
Introduce %(upstream:track) to display "[ahead M, behind N]" and
%(upstream:trackshort) to display "=", ">", "<", or "<>"
appropriately (inspired by contrib/completion/git-prompt.sh).

Now you can use the following format in for-each-ref:

  %(refname:short)%(upstream:trackshort)

to display refs with terse tracking information.

Note that :track and :trackshort only work with "upstream", and error
out when used with anything else.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-11-19 10:14:15 -08:00
Ramkumar Ramachandra
7a48b83219 for-each-ref: introduce %(HEAD) asterisk marker
'git branch' shows which branch you are currently on with an '*', but
'git for-each-ref' misses this feature.  So, extend its format with
%(HEAD) for the same effect.

Now you can use the following format in for-each-ref:

  %(HEAD) %(refname:short)

to display an asterisk next to the current ref.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-11-18 13:49:42 -08:00
Ramkumar Ramachandra
189a546797 t6300 (for-each-ref): don't hardcode SHA-1 hexes
Use rev-parse in its place, making it easier for future patches to
modify the test script.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-11-18 13:49:42 -08:00
Ramkumar Ramachandra
bc147968a4 t6300 (for-each-ref): clearly demarcate setup
Condense the two-step setup into one step, and give it an appropriate
name.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-11-18 13:49:42 -08:00
Jeff King
b74cf64803 for-each-ref: avoid loading objects to print %(objectname)
If you ask for-each-ref to print each ref and its object,
like:

  git for-each-ref --format='%(objectname) %(refname)'

this should involve little more work than looking at the ref
files (and packed-refs) themselves. However, for-each-ref
will actually load each object from disk just to print its
sha1. For most repositories, this isn't a big deal, but it
can be noticeable if you have a large number of refs to
print. Here are best-of-five timings for the command above
on a repo with ~10K refs:

  [before]
  real    0m0.112s
  user    0m0.092s
  sys     0m0.016s

  [after]
  real    0m0.014s
  user    0m0.012s
  sys     0m0.000s

This patch checks for %(objectname) and %(objectname:short)
before we actually parse the object (and the rest of the
code is smart enough to avoid parsing if we have filled all
of our placeholders).

Note that we can't simply move the objectname parsing code
into the early loop. If the "deref" form %(*objectname) is
used, then we do need to parse the object in order to peel
the tag. So instead of moving the code, we factor it out
into a separate function that can be called for both cases.

While we're at it, we add some basic tests for the
dereferenced placeholders, which were not tested at all
before. This helps ensure we didn't regress that case.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-30 10:33:46 -07:00
Kacper Kornet
3b51222cec for-each-ref: Fix sort with multiple keys
The linked list describing sort options was not correctly set up in
opt_parse_sort. In the result, contrary to the documentation, only the
last of multiple --sort options to git-for-each-ref was taken into
account. This commit fixes it.

Signed-off-by: Kacper Kornet <draenog@pld-linux.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-21 14:42:12 -07:00
Kacper Kornet
912072d53a t6300: test sort with multiple keys
Documentation of git-for-each-ref says that --sort=<key> option can be
used multiple times, in which case the last key becomes the primary key.
However this functionality was never checked in test suite and is
currently broken. This commit adds appropriate test in preparation for fix.

Signed-off-by: Kacper Kornet <draenog@pld-linux.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-21 14:42:11 -07:00
Michał Górny
e2b239722a for-each-ref: add split message parts to %(contents:*).
The %(body) placeholder returns the whole body of a tag or
commit, including the signature. However, callers may want
to get just the body without signature, or just the
signature.

Rather than change the meaning of %(body), which might break
some scripts, this patch introduces a new set of
placeholders which break down the %(contents) placeholder
into its constituent parts.

[jk: initial patch by mg, rebased on top of my refactoring
and with tests by me]

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-08 13:56:19 -07:00
Jeff King
7f6e275bc0 for-each-ref: handle multiline subjects like --pretty
Generally the format of a git tag or commit message is:

  subject

  body body body
  body body body

However, we occasionally see multiline subjects like:

  subject
  with multiple
  lines

  body body body
  body body body

The rest of git treats these multiline subjects as something
to be concatenated and shown as a single line (e.g., "git
log --pretty=format:%s" will do so since f53bd74). For
consistency, for-each-ref should do the same with its
"%(subject)".

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-08 13:52:00 -07:00
Jeff King
7140c22c8e t6300: add more body-parsing tests
The current tests don't actually check parsing commit and
tag messages that have both a subject and a body (they just
have single-line messages).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-08 13:51:15 -07:00
Michael J Gruber
67687feae5 for-each-ref: Field with abbreviated objectname
Introduce a :short modifier to objectname which outputs the abbreviated
object name.

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-05-18 21:49:04 -07:00
Bert Wesarg
2bb98169be for-each-ref: utilize core.warnAmbiguousRefs for :short-format
core.warnAmbiguousRefs is used to select strict mode for the
abbreviation for the ":short" format specifier of "refname" and "upstream".

In strict mode, the abbreviated ref will never trigger the
'warn_ambiguous_refs' warning. I.e. for these refs:

  refs/heads/xyzzy
  refs/tags/xyzzy

the abbreviated forms are:

  heads/xyzzy
  tags/xyzzy

Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-13 09:36:52 -07:00
Jeff King
8cae19d987 for-each-ref: add "upstream" format field
The logic for determining the upstream ref of a branch is
somewhat complex to perform in a shell script. This patch
provides a plumbing mechanism for scripts to access the C
logic used internally by git-status, git-branch, etc.

For example:

  $ git for-each-ref \
       --format='%(refname:short) %(upstream:short)' \
       refs/heads/
  master origin/master

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-07 23:22:15 -07:00
Bert Wesarg
7d66f21a1b for-each-ref: :short format for refname
Tries to shorten the refname to a non-ambiguous name.

Szeder Gábor noticed that the git bash completion takes a
tremendous amount of time to strip leading components from
heads and tags refs (i.e. refs/heads, refs/tags, ...). He
proposed a new atom called 'refbasename' which removes at
most two leading components from the ref name.

I myself, proposed a more dynamic solution, which strips off
common leading components with the matched pattern.

But the current bash solution and both proposals suffer from
one mayor problem: ambiguous refs.

A ref is ambiguous, if it resolves to more than one full refs.
I.e. given the refs refs/heads/xyzzy and refs/tags/xyzzy. The
(short) ref xyzzy can point to both refs.

( Note: Its irrelevant whether the referenced objects are the
  same or not. )

This proposal solves this by checking for ambiguity of the
shorten ref name.

The shortening is done with the same rules for resolving refs
but in the reverse order. The short name is checked if it
resolves to a different ref.

To continue the above example, the output would be like this:

heads/xyzzy
xyzzy

So, if you want just tags, xyzzy is not ambiguous, because it
will resolve to a tag. If you need the heads you get a also
a non-ambiguous short form of the ref.

To integrate this new format into the bash completion to get
only non-ambiguous refs is beyond the scope of this patch.

Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-09-05 23:06:37 -07:00
Nanako Shiraishi
3604e7c5c6 tests: use "git xyzzy" form (t3600 - t6999)
Converts tests between t3600-t6300.

Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-09-03 14:13:59 -07:00
Junio C Hamano
e276c26b4b for-each-ref: cope with tags with incomplete lines
If you have a tag with a single, incomplete line as its payload, asking
git-for-each-ref for its %(body) element accessed a NULL pointer.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-20 13:29:30 -07:00
Jeff King
d2bf48d2ad improve for-each-ref test script
Previously, we did a sanity check by doing for-each-ref
using each possible format atom. However, we never checked
the actual output produced by that atom, which recently let
an obvious bug go undetected for some time.

While we're at it, also clean up a few '!' into
test_must_fail.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-26 12:13:03 -07:00
Junio C Hamano
3af828634f tests: do not use implicit "git diff --no-index"
As a general principle, we should not use "git diff" to validate the
results of what git command that is being tested has done.  We would not
know if we are testing the command in question, or locating a bug in the
cute hack of "git diff --no-index".

Rather use test_cmp for that purpose.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-24 00:01:56 -07:00
Junio C Hamano
41ac414ea2 Sane use of test_expect_failure
Originally, test_expect_failure was designed to be the opposite
of test_expect_success, but this was a bad decision.  Most tests
run a series of commands that leads to the single command that
needs to be tested, like this:

    test_expect_{success,failure} 'test title' '
	setup1 &&
        setup2 &&
        setup3 &&
        what is to be tested
    '

And expecting a failure exit from the whole sequence misses the
point of writing tests.  Your setup$N that are supposed to
succeed may have failed without even reaching what you are
trying to test.  The only valid use of test_expect_failure is to
check a trivial single command that is expected to fail, which
is a minority in tests of Porcelain-ish commands.

This large-ish patch rewrites all uses of test_expect_failure to
use test_expect_success and rewrites the condition of what is
tested, like this:

    test_expect_success 'test title' '
	setup1 &&
        setup2 &&
        setup3 &&
        ! this command should fail
    '

test_expect_failure is redefined to serve as a reminder that
that test *should* succeed but due to a known breakage in git it
currently does not pass.  So if git-foo command should create a
file 'bar' but you discovered a bug that it doesn't, you can
write a test like this:

    test_expect_failure 'git-foo should create bar' '
        rm -f bar &&
        git foo &&
        test -f bar
    '

This construct acts similar to test_expect_success, but instead
of reporting "ok/FAIL" like test_expect_success does, the
outcome is reported as "FIXED/still broken".

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-01 20:49:34 -08:00
Johannes Sixt
c9ecf4f12a for-each-ref: Fix quoting style constants.
for-each-ref can accept only one quoting style. For this reason it uses
OPT_BIT for the quoting style switches so that it is easy to check for
more than one bit being set. However, not all symbolic constants were
actually single bit values. In particular:

    $ git for-each-ref --python
    error: more than one quoting style ?

This fixes it.

While we are here, let's also remove the space before the question mark.

Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-12-06 07:53:20 -08:00
Lars Hjemli
c899a57c28 for-each-ref: fix setup of option-parsing for --sort
The option value for --sort is already a pointer to a pointer to struct
ref_sort, so just use it.

Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-10 11:04:24 -08:00
Pierre Habouzit
c3428da87f Make builtin-for-each-ref.c use parse-opts.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-10-29 21:03:31 -07:00