Hi Jake, On Tue, 17 Jan 2017, Jacob Keller wrote: > On Fri, Jan 13, 2017 at 1:31 PM, Johannes Sixt <j6t@xxxxxxxx> wrote: > > Am 13.01.2017 um 07:57 schrieb Jacob Keller: > >> > >> On Thu, Jan 12, 2017 at 10:43 PM, Johannes Sixt <j6t@xxxxxxxx> wrote: > >>> > >>> 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