--ignore-invalid flag to git log et al.?

--ignore-invalid flag to git log et al.?

[Paul Mackerras]

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.

Re: --ignore-invalid flag to git log et al.?

[Alex Riesen]

On 7/11/07, Paul Mackerras <paulus@samba.org> 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 ...?

Re: --ignore-invalid flag to git log et al.?

[Paul Mackerras]

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.

Re: --ignore-invalid flag to git log et al.?

[Junio C Hamano]

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