Paul Mackerras <paulus@xxxxxxxxx> 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. - 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
