On Wed, Jan 18, 2017 at 4:44 AM, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > 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 That might help make it easier to go this route. I'll take a look. Thanks, Jake