Santi Béjar wrote: > 2009/2/15 Junio C Hamano <gitster@xxxxxxxxx>: > > Many options you add here are useful for git-log and not present in its > > completion, but as you point out not all git-log options necessarily make > > sense for gitk. I think it would make sense to introduce an extra > > variable $__git_log_basic_options that holds the basic ones that can be in > > both, and add the ones that are specific to gitk or git-log in their own > > completion functions. I suspect gitk's addition will be nil, while > > git-log would add --graph, --walk-reflogs and --no-merges to the basic > > set. Right. Somehow git patches have a tendency to grow in scope; while I was trying to refactor them in good ways, I couldn't help notice that shortlog falls in the same category. (Probably there's another log-like command that I missed?) > I sometimes use the --no-merges with gitk, normally within a range > (the last 'next' update or so). For me that falls in the "mangles history in horrible ways" category, but since you use it, I put it in. 2/2 is new; I figured since gitk has this bit of code already, why not have git-log do it the same way? Thomas Rast (2): bash completion: refactor common log, shortlog and gitk options bash completion: only show 'log --merge' if merging contrib/completion/git-completion.bash | 56 ++++++++++++++++++++++--------- 1 files changed, 40 insertions(+), 16 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
