{"thread":{"id":"59276","subject":"git rev-list --no-walk RANGE not working as documented","startedAt":"2023-02-21T00:00:29Z","lastAt":"2024-10-02T19:18:21Z","messageCount":3,"participants":["squeaky","Kristoffer Haugsbakk","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"472361","messageId":"24417-1676937251-531825@sneakemail.com","threadId":"59276","inReplyTo":null,"subject":"git rev-list --no-walk RANGE not working as documented","fromName":"squeaky","fromEmail":"334eevw4vj@liamekaens.com","sentAt":"2023-02-20T23:54:11Z","receivedAt":"2023-02-21T00:00:29Z","isPatch":false,"sender":{"key":"334eevw4vj@liamekaens.com","avatar":null},"body":"Thank you for filling out a Git bug report!\nPlease answer the following questions to help us understand your issue.\n\nWhat did you do before the bug happened? (Steps to reproduce your issue)\n\ngit rev-list HERE..THERE --no-walk\n\nWhat did you expect to happen? (Expected behavior)\n\nShow the commits between HERE and THERE. \n\nWhat happened instead? (Actual behavior)\n\nOnly THERE is shown.\n\nWhat's different between what you expected and what actually happened?\n\nThe documentation for --no-walk says, \"This has no effect if a range is specified.\"\nSince HERE..THERE is a range, --no-walk should have no effect. This isn't working as documented.\n\nAnything else you want to add:\n\nPlease review the rest of the bug report below.\nYou can delete any lines you don't wish to share.\n\n\n[System Info]\ngit version:\ngit version 2.39.2.501.gd9d677b2d8\ncpu: x86_64\nbuilt from commit: d9d677b2d8cc5f70499db04e633ba7a400f64cbf\nsizeof-long: 8\nsizeof-size_t: 8\nshell-path: /bin/sh\nuname: Linux 6.1.6-200.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Sat Jan 14 16:55:06 UTC 2023 x86_64\ncompiler info: gnuc: 12.2\nlibc info: glibc: 2.36\n$SHELL (typically, interactive shell): /bin/bash\n\n\n[Enabled Hooks]\n[root@xps git] \n\n"},{"id":"503842","messageId":"7fddacf9-55f6-4520-a288-279d3784badb@app.fastmail.com","threadId":"59276","inReplyTo":"24417-1676937251-531825@sneakemail.com","subject":"Re: git rev-list --no-walk RANGE not working as documented","fromName":"Kristoffer Haugsbakk","fromEmail":"kristofferhaugsbakk@fastmail.com","sentAt":"2024-10-01T15:04:15Z","receivedAt":"2024-10-01T15:04:36Z","isPatch":false,"sender":{"key":"kristofferhaugsbakk@fastmail.com","avatar":null},"body":"On Tue, Feb 21, 2023, at 00:54, squeaky wrote:\n> Thank you for filling out a Git bug report!\n> Please answer the following questions to help us understand your issue.\n>\n> What did you do before the bug happened? (Steps to reproduce your issue)\n>\n> git rev-list HERE..THERE --no-walk\n>\n> What did you expect to happen? (Expected behavior)\n>\n> Show the commits between HERE and THERE.\n>\n> What happened instead? (Actual behavior)\n>\n> Only THERE is shown.\n>\n> What's different between what you expected and what actually happened?\n>\n> The documentation for --no-walk says, \"This has no effect if a range is\n> specified.\"\n> Since HERE..THERE is a range, --no-walk should have no effect. This\n> isn't working as documented.\n>\n> Anything else you want to add:\n>\n> Please review the rest of the bug report below.\n> You can delete any lines you don't wish to share.\n>\n>\n> [System Info]\n> git version:\n> git version 2.39.2.501.gd9d677b2d8\n> cpu: x86_64\n> built from commit: d9d677b2d8cc5f70499db04e633ba7a400f64cbf\n> sizeof-long: 8\n> sizeof-size_t: 8\n> shell-path: /bin/sh\n> uname: Linux 6.1.6-200.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Sat Jan 14\n> 16:55:06 UTC 2023 x86_64\n> compiler info: gnuc: 12.2\n> libc info: glibc: 2.36\n> $SHELL (typically, interactive shell): /bin/bash\n>\n>\n> [Enabled Hooks]\n> [root@xps git]\n\nHi, I get different results based on the order:\n\n    git rev-list HERE..THERE --no-walk\n\nThis (like you say) only outputs “there”.\n\nBut this one outputs several:\n\n    git rev-list --no-walk HERE..THERE\n\n-- \nKristoffer Haugsbakk\n"},{"id":"503971","messageId":"xmqqzfnml3es.fsf@gitster.g","threadId":"59276","inReplyTo":"7fddacf9-55f6-4520-a288-279d3784badb@app.fastmail.com","subject":"Re: git rev-list --no-walk RANGE not working as documented","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-10-02T19:18:19Z","receivedAt":"2024-10-02T19:18:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Kristoffer Haugsbakk\" <kristofferhaugsbakk@fastmail.com> writes:\n\n> Hi, I get different results based on the order:\n>\n>     git rev-list HERE..THERE --no-walk\n>\n> This (like you say) only outputs “there”.\n>\n> But this one outputs several:\n>\n>     git rev-list --no-walk HERE..THERE\n\nThanks, Kristoffer, for looking at the report.\n\nThe subject line says \"rev-list --no-walk RANGE\", but that command\nline works as documented.  The real complaint in the report is about\n\"rev-list RANGE --no-walk\".  This thread is titled incorrectly.\n\nIn this particular case, because HERE..THERE implies \"--walk\" (and\nthat is how \"git show A\" and \"git show A..B\" behave the way users\nare used to.  \"git show\" itself behaves as if it has an implicit\n\"--no-walk\" at the beginning, and later \"--walk\" overrides it), it\nis understandable that\n\n    rev-list --no-walk HERE..THERE\n\nwalks (following the usual \"last one wins\" rule, allowing the later\nimplicit \"--walk\" to override \"--no-walk\"), while\n\n    rev-list HERE..THERE --no-walk\n\ndoes not walk (again, following the usual \"last one wins\" rule,\nthe implicit \"--walk\" given by HERE..THERE gets overriden by an\nexplicit \"--no-walk\" that comes later).\n\nBut in general, the documentation assumes that the user follows the\nusual command-line convention used throughout Git (see git help\ncli---dashed options come before revs and paths).  The command line\nparser still accepts command line arguments in non-canonical order\n(i.e. revs are given and then an option, in the problematic example\nin this thread) without complaining, but this is done primarily to\ncater to old timers, those who expect the commands to keep behaving\nthe way they happened to behave, which may or may not appear \"sane\"\nto untrained eyes ;-).\n\nThanks.\n"}]}