Junio C Hamano wrote: > "Victoria Dye via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > >> This series is a bit of an informal follow-up to [1], adding some more >> substantial optimizations and usability fixes around ref >> filtering/formatting. Some of the changes here affect user-facing behavior, >> some are internal-only, but they're all interdependent enough to warrant >> putting them together in one series. >> >> [1] >> https://lore.kernel.org/git/pull.1594.v2.git.1696888736.gitgitgadget@xxxxxxxxx/ >> >> Patch 1 changes the behavior of the '--no-sort' option in 'for-each-ref', >> 'tag', and 'branch'. Currently, it just removes previous sort keys and, if >> no further keys are specified, falls back on ascending refname sort (which, >> IMO, makes the name '--no-sort' somewhat misleading). > > We can read it changes the behaviour and what the current behaviour > is, but I presume that the untold new behaviour with --no-sort is to > show the output in an unspecified order of implementation's > convenience? I think it makes quite a lot of sense if that is what > is done. Ah sorry, I over-edited my cover letter and accidentally removed the explanation of what this patch does! Yes - the new behavior is that '--no-sort' (assuming there are no subsequent --sort=<something> options) will completely skip sorting the filtered refs. >> * I'm not attached to '--full-deref' as a name - if someone has an idea for >> a more descriptive name, please suggest it! > > Another candidate verb may be "to peel", and I have no strong > opinion between it and "to dereference". But I have a mild aversion > to an abbreviation that is not strongly established. > Makes sense. I got the "deref" abbreviation for 'update-ref --no-deref', but 'show-ref' has a "--dereference" option and protocol v2's "ls-refs" includes a "peel" arg. "Dereference" is the term already used in the 'for-each-ref' documentation, though, so if no one comes in with an especially strong opinion on this I'll change the option to '--full-dereference'. Thanks!
