Hi Peff, Jeff King wrote: > It may even be possible to use > heuristics to identify when --literal-order is needed, and eventually it > could go away. Yeah, that would be really nice. > My only concern is that there are other parts of the revision machinery > that depend on the date-ordering of the commit list. Agreed. Looking at it another way, it's an opportunity to read revision.c, learn, and modernize some older parts :) > What would happen, > for example, with: > > git rev-list --literal-order --do-walk foo > > It probably doesn't make sense to allow literal-order without no-walk, > anyway (which of course is the default in cherry-pick anyway, so it's > not a big deal here). I don't know if that particular case is a problem: there are some mutually exclusive options in revision.c already like: cannot combine --reverse with --graph This'll just be another one of them. > I'm also not sure what: > > git rev-list --literal-order foo..bar > > would or should do. Instead of classifying it as an "ordering" option (as defined in Documentation/rev-list-options.txt), I think we should give it some sort of special status for now -- it can be combined with ordering options (of which date ordering is default anyway). For this specific question, I suspect that revision.c does a topo-ordering for commit ranges (I haven't read the code), so we have to make sure that whatever extra logic we add doesn't disrupt the existing logic in revision.c. -- Ram -- 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