From: "Jakub Narębski" <jnareb@gmail.com>
To: Stefan Beller <sbeller@google.com>,
Junio C Hamano <gitster@pobox.com>,
Jonathan Nieder <jrnieder@gmail.com>
Cc: git@vger.kernel.org, mfick@codeaurora.org
Subject: Re: [PATCH v2] builtin/describe: introduce --broken flag
Date: Wed, 22 Mar 2017 22:50:01 +0100 [thread overview]
Message-ID: <b418a7ec-a8e5-1702-1a1f-3e9c8b8a2f7e@gmail.com> (raw)
In-Reply-To: <20170321225718.18633-1-sbeller@google.com>
W dniu 21.03.2017 o 23:57, Stefan Beller pisze:
> --- a/Documentation/git-describe.txt
> +++ b/Documentation/git-describe.txt
> @@ -30,9 +30,14 @@ OPTIONS
> Commit-ish object names to describe. Defaults to HEAD if omitted.
>
> --dirty[=<mark>]::
> - Describe the working tree.
> - It means describe HEAD and appends <mark> (`-dirty` by
> - default) if the working tree is dirty.
> +--broken[=<mark>]::
> + Describe the state of the working tree. When the working
> + tree matches HEAD, the output is the same as "git describe
> + HEAD". If the working tree has local modification "-dirty"
> + is appended to it. If a repository is corrupt and Git
> + cannot determine if there is local modification, Git will
> + error out, unless `--broken' is given, which appends
> + the suffix "-broken" instead.
The common description reads better... but unfortunately it lost
information about the optional parameter, namely <mark>. The
'-dirty' is just the default for <dirty-mark>, and '-broken' is
the default for <broken-mark>.
Maybe /the suffix "-broken"/<broken-mark> suffix ('-broken' by default)/
and similarly for "-dirty"?
Best,
--
Jakub Narębski
next prev parent reply other threads:[~2017-03-22 21:50 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-21 0:11 [PATCH 0/3] git-describe deals gracefully with broken submodules Stefan Beller
2017-03-21 0:11 ` [PATCH 1/3] submodule.c: port is_submodule_modified to use porcelain 2 Stefan Beller
2017-03-21 0:11 ` [PATCH 2/3] revision machinery: gentle submodule errors Stefan Beller
2017-03-21 0:11 ` [PATCH 3/3] builtin/describe: introduce --submodule-error-as-dirty flag Stefan Beller
2017-03-21 6:28 ` [PATCH 0/3] git-describe deals gracefully with broken submodules Junio C Hamano
2017-03-21 6:54 ` Junio C Hamano
2017-03-21 18:51 ` [PATCH] builtin/describe: introduce --broken flag Stefan Beller
2017-03-21 21:51 ` Junio C Hamano
2017-03-21 22:27 ` Stefan Beller
2017-03-21 22:41 ` Junio C Hamano
2017-03-21 22:50 ` Stefan Beller
2017-03-21 22:57 ` [PATCH v2] " Stefan Beller
2017-03-22 17:21 ` Junio C Hamano
2017-03-22 21:50 ` Jakub Narębski [this message]
2017-03-21 17:46 ` [PATCH 0/3] git-describe deals gracefully with broken submodules Stefan Beller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b418a7ec-a8e5-1702-1a1f-3e9c8b8a2f7e@gmail.com \
--to=jnareb@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jrnieder@gmail.com \
--cc=mfick@codeaurora.org \
--cc=sbeller@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).