On Sat, Jan 21, 2017 at 5:00 AM, Jacob Keller <jacob.kel...@gmail.com> wrote: > On Fri, Jan 20, 2017 at 6:30 AM, Jeff King <p...@peff.net> wrote: >>> Imposing order between options could cause confusion, I think, if you >>> remove --decorate-reflog leaving --remotes on by accident, now you get >>> --remotes with a new meaning. We could go with something like >>> --decodate-reflog=remote, but that clashes with the number of reflog >>> entries and we may need a separator, like --decorate-reflog=remote,3. >>> Or we could add something to --decorate= in addition to >>> short|full|auto|no. Something like --decorate=full,reflog or >>> --decorate=full,reflog=remote,entries=3 if I want 3 reflog entries. >> >> I agree that making option-order important is potentially confusing. But >> it does already exist with --exclude. It's necessary to specify some >> sets of refs (e.g., all of A, except for those that match B, and then >> all of C, including those that match B). >> >> Having --decorate-reflog=remote would be similarly constrained. You >> couldn't do "decorate all remotes except for these ones". For that >> matter, I'm not sure how you would do "decorate just the refs from >> origin". >> >> I'll grant that those are going to be a lot less common than just "all >> the remotes" (or all the tags, or whatever). I'd just hate to see us >> revisiting this in a year to generalize it, and being stuck with >> historical baggage. >> >>> My hesitant to go that far is because I suspect decorating reflog >>> won't be helpful for non-remotes. But I'm willing to make more changes >>> if it opens door to master. >> >> Forgetting reflogs for a moment, I'd actually find it useful to just >> decorate tags and local branches, but not remotes. But right now there >> isn't any way to select which refs are worthy of decoration (reflog or >> not). >> >> That's why I'm thinking so much about a general ref-selection system. I >> agree the "--exclude=... --remotes" thing is complicated, but it's also >> the ref-selection system we _already_ have, which to me is a slight >> point in its favor. >> >> -Peff > > I agree that the interaction between --exclude and --remotes/etc is > confusing, but I think it's reasonable enough because we already > support it, so it makes sense to extend it with this. I also think its > better to extend here than it is to hard-code it.
OK. Next question, how do we deal with the reflog count (i..e the argument of --decorate-remote-reflog). Should it be shared for all ref type, or can be specified differently for remote, local and tags? I'm leaning towards the former. But I'll wait a bit for ideas before rewriting the patch. -- Duy
