Junio C Hamano <gits...@pobox.com> writes: > Rafael Ascensão <rafa.al...@gmail.com> writes: > ... >> Because changing the default behavior of that function has >> implications on multiple commands which I think shouldn't change. But >> at the same time, would be nice to have the logic that deals with >> glob-ref patterns all in one place. >> >> What's the sane way to do this? > > Learn to type "--decorate-refs="refs/heads/[m]aster", and not twewak > the code at all, perhaps. The users of existing "with no globbing, > /* is appended" interface are already used to that way and they do > not have to learn a new and inconsistent interface. > > After all, "I only want to see 'git log' output with 'master' > decorated" (i.e. not specifying "this class of refs I can glob by > using the naming convention I am using" and instead enumerating the > ones you care about) does not sound like a sensible thing people > often want to do, so making it follow the other codepath so that > people can say "refs/tags" to get "refs/tags/*", while still allowing > such a rare but specific and exact one possible, may not sound too > bad to me.
Having said all that, I can imagine another way out might be to change the behaviour of this "normalize" thing to add two patterns, the original pattern in addition to the original pattern plus "/*", when it sees a pattern without any glob. Many users who relied on the current behaviour fed "refs/tags" knowing that it will match everything under "refs/tags" i.e. "refs/tags/*", and they cannot have a ref that is exactly "refs/tags", so adding the original pattern without an extra trailing "/*" would not hurt them. And this will allow you to say "refs/heads/master" when you know you want that exact ref, and in such a repository where that original pattern without trailing "/*" would be useful, because you cannot have "refs/heads/master/one" at the same time, having an extra pattern that is the original plus "/*" would not hurt you, either. This however needs a bit of thought to see if there are corner cases that may result in unexpected and unwanted fallout, and something I am reluctant to declare unilaterally that it is a better way to go. Thoughts?
