Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> writes: > Karthik Nayak <karthik.188@xxxxxxxxx> writes: > >> So either we could introduce a new atom for sorting something like >> `branch_sort` which uses the FILTER_REFS_(DETACHED_HEAD | BRANCHES | >> REMOTES) > > I don't think you need a new atom. You can just change the sorting > function to consider that detached HEAD is always first, and when > comparing two non-detached-HEAD branches, use the atom supplied by the > user. > > That would mean the detached HEAD would be displayed first regardless of > --sort (which is the case right now). I am a bit fuzzy about this. I do not understand why Karthik thinks a new atom is necessary in the first place, and I do agree that the best way to go would be to teach the sort function to do "the right thing", but I am not sure why it has to be "regardless of --sort". In the original for-each-ref (before it was butchered^W updated with ref-filter), we grab refs and sort with default_sort() when "--sort" is not given. When --sort is given, we just use atoms to compare. I do not think ref-filter broke that pattern, and as long as it kept that pattern, I do not think the solution has to be more than just "teach that default_sort() function, which sorts by refname, to always show HEAD first". When you throw HEAD into the mix, instead of grabbing only from refs/*, you can still give that set to a sorting function, which by default puts "HEAD" before others (just like the sorting function for "branch -a" by default puts local before remote-tracking), and you are done, no? When the user does give a custom --sort criteria, the logic in default_sort() would not kick in, so there is no need for special casing for "HEAD" like the code I questioned in this thread. What am I missing? > Introducing a new atom would mean that "git branch --sort authorname" > would not use this new atom, hence the HEAD would be sorted like the > others. I think that is exactly what people would expect. Perhaps a slightly tricky would be "git branch -a --sort refname". If you have HEAD, refs/heads/master, and refs/remotes/origin/master, I'd expect that it would sort these in that order purely because that is the textual/ascii sort order of the FULL refname. And then at the presentation level you would strip refs/heads and refs/remotes from local and remote-tracking branches, just like "git branch -a" output has always done, from the sorted result when showing. "git branch -a --sort refname:short" would sort using HEAD vs master vs origin/master in the above example and would end up mixing loal and remote-tracking together, but that is what the user is asking for, and the user deserves to get what s/he asked for. Somewhat confused.... -- 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