# --ignore-invalid flag to git log et al.? 4 messages from 2007-07-11 to 2007-07-11. Participants: Paul Mackerras, Alex Riesen, Junio C Hamano. Thread: https://gitlist.dev/t/8978 ## Paul Mackerras, 2007-07-11 07:29 Subject: --ignore-invalid flag to git log et al.? Message-ID: <18068.34542.502048.222112@cargo.ozlabs.ibm.com> URL: https://gitlist.dev/e/18068.34542.502048.222112%40cargo.ozlabs.ibm.com ``` Junio, What would you think about a --ignore-invalid flag for things like git rev-list and git log, to tell it to ignore any refs on the command line that are not valid objects? Currently there is a buglet in gitk where if a user puts some sort of ref on the command line, and then makes the ref invalid (e.g. by deleting the ref if it is a head or tag, or doing a git prune if it is a sha1 ID with no head/tag pointing to it), and then does "Update" in gitk, it will get an error because of the now-invalid ref. (Yes, this is a bit of a corner case, but I have had a user point out this behaviour to me.) With a --ignore-invalid flag, gitk could use this when doing "Update" to avoid the error. An alternative would be to have some way to validate refs. I don't know how to do that efficiently. I think I would not want to have to do a fork/exec for every ref that I wanted to check. Thoughts? Paul. ``` ## Alex Riesen, 2007-07-11 07:46 Subject: Re: --ignore-invalid flag to git log et al.? Message-ID: <81b0412b0707110046n5ec27328pab0ff33c183f79e@mail.gmail.com> URL: https://gitlist.dev/e/81b0412b0707110046n5ec27328pab0ff33c183f79e%40mail.gmail.com In-Reply-To: <18068.34542.502048.222112@cargo.ozlabs.ibm.com> ``` On 7/11/07, Paul Mackerras wrote: > An alternative would be to have some way to validate refs. I don't > know how to do that efficiently. I think I would not want to have to > do a fork/exec for every ref that I wanted to check. git rev-parse --revs-only ref1 ref2 ref3 ...? ``` ## Paul Mackerras, 2007-07-11 09:07 Subject: Re: --ignore-invalid flag to git log et al.? Message-ID: <18068.40404.772354.34192@cargo.ozlabs.ibm.com> URL: https://gitlist.dev/e/18068.40404.772354.34192%40cargo.ozlabs.ibm.com In-Reply-To: <81b0412b0707110046n5ec27328pab0ff33c183f79e@mail.gmail.com> ``` Alex Riesen writes: > git rev-parse --revs-only ref1 ref2 ref3 ...? That stops when it sees an invalid ref and doesn't check the rest. Also if you give it a string of 40 hex digits it will print it out whether it's a valid object ID or not. Paul. ``` ## Junio C Hamano, 2007-07-11 21:26 Subject: Re: --ignore-invalid flag to git log et al.? Message-ID: <7vvecq3a4o.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vvecq3a4o.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <18068.34542.502048.222112@cargo.ozlabs.ibm.com> ``` Paul Mackerras writes: > What would you think about a --ignore-invalid flag for things like git > rev-list and git log, to tell it to ignore any refs on the command > line that are not valid objects? > > Currently there is a buglet in gitk where if a user puts some sort of > ref on the command line, and then makes the ref invalid (e.g. by > deleting the ref if it is a head or tag, or doing a git prune if it is > a sha1 ID with no head/tag pointing to it), and then does "Update" in > gitk, it will get an error because of the now-invalid ref. (Yes, this > is a bit of a corner case, but I have had a user point out this > behaviour to me.) With a --ignore-invalid flag, gitk could use this > when doing "Update" to avoid the error. I suspect a much less corner case schenario is an old saved view where you used to care about "master..experimental -- gitweb/", but now you are done with gitweb experiments and got rid of the branch. Then choosing that view would say "experimental? what are you talking about?". I wonder what the "--ignore-invalid" option should do. If it silently ignores, the command line to rev-list from the saved view would become "^master -- gitweb" and the user is left with emptiness without any indication of errors. Is that a better behaviour? I would think not. Giving results from a command that is different from what the user thought is done without telling the user is not very nice, so I think you would instead need "--error-on-invalid". > An alternative would be to have some way to validate refs. I don't > know how to do that efficiently. I think I would not want to have to > do a fork/exec for every ref that I wanted to check. Is it a possibility to let the rev-list do its job when there is no error, but catch the error if it does not understand the command line, because of a revision that is now made invalid, and then in the error path validate the revs one by one? At that point in the error path you do not particularly care about the efficiency I would think. ```