This causes run-command-on-git-revisions master $some_old_tag $cmd to work as if
executed as run-command-on-git-revisions $some_old_tag master $cmd
run-command-on-git-revisions master $some_old_tag $cmd
run-command-on-git-revisions $some_old_tag master $cmd
Allow specifying the earliest revision in either position.
This causes `run-command-on-git-revisions master $some_old_tag $cmd` to work as if
executed as `run-command-on-git-revisions $some_old_tag master $cmd`
I'm skeptical about this, because I'd expect run-command-on-git-revisions master some_old_tag to run backwards: to start with master and go back in time. That could definitely be useful (e.g., as a rigorous replacement for bisect, where you suspect that a bug came and went multiple times). Of course, that doesn't work as it is because rev-list doesn't know how to list things backward, but I think that doing it forward automatically could be deceiving.
run-command-on-git-revisions master some_old_tag
It seems like causing the script to behave as you have described would be pretty simple.
This script currently invokes rev-list with --reverse in order to cause it to run from some_old_tag to master, ending on master. What prevents it from working when given master..some_old_tag is that rev-list returns nothing.
Removing --reverse from the if statement in the proposed patch should do the trick. When provided master some_old_tag it will run backward from master to some_old_tag, and when provided some_old_tag master it would behave as it currently does, ending with master.
I'll update the pull request.
Work when provided a newer revision first, running from new revision …
…-> old revision
Argh... I just checked, and log returns nothing in this case. I could've sworn it was smart ("smart"?) enough to list commits backward. I think it'd be best to match the behavior of log. Sorry, I should've checked that first.
How about just printing a message telling the user that his range didn't include any commits?
I actually prefer your original suggestion to loop from whatever they provide first to whatever they provide second, whether it has to go forward or backward from the first commit to the second.
Of course, this is your script, so if it doesn't suit your desires feel free to keep the current behavior and close this pull request and I can happily continue to use my forked variant for my purposes. If you do like the behavior to loop in either direction, the current patch does it.