Thread (22 messages) flat view 22 messages, 4 authors, 2017-01-18

Re: [PATCH 5/5] describe: teach describe negative pattern matches

From: Johannes Schindelin <hidden>
Date: 2017-01-18 12:44:30

Hi Jake,

On Tue, 17 Jan 2017, Jacob Keller wrote:
On Fri, Jan 13, 2017 at 1:31 PM, Johannes Sixt [off-list ref] wrote:
quoted
Am 13.01.2017 um 07:57 schrieb Jacob Keller:
quoted
On Thu, Jan 12, 2017 at 10:43 PM, Johannes Sixt [off-list ref] wrote:
quoted
 When you write

  git log --branches --exclude=origin/* --remotes

--exclude=origin/* applies only to --remotes, but not to --branches.

Well for describe I don't think the order matters.

That is certainly true today. But I would value consistency more. We would
lose it if some time in the future 'describe' accepts --branches and
--remotes in addition to --tags and --all.

-- Hannes
I am not sure that the interface for git-log and git-describe are
similar enough to make this distinction work. --match already seems to
imply that it only works on refs in refs/tags, as it says it considers
globs matching excluding the "refs/tags" prefix.

In git-describe, we already have "--tags" and "--all" but they are
mutually exclusive. We don't support using more than one at once, and
I'm not really convinced that describe will ever support more than one
at a time. Additionally, match already doesn't respect order.
I agree that it would keep the code much simpler if you kept the order
"exclude before include".

However, should you decide to look into making the logic dependent on the
order in which the flags were specified in the command-line, we do have a
data structure for such a beast: we use it in gitignore and in
sparse-checkout, it is called struct exclude_list.

Just some food for thought,
Johannes
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help