Re: git blame not respecting --find-copies-harder ?

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 31, 2008, 07:36 UTC
Message-ID: <7v8wvi33ok.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <20080731072149.GA2304@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 5 quoted lines

> I took a look at implementing a "don't parse the diff options" flag, but
> it is much larger than that. The revision parser understands a lot of
> options that don't really make sense for blame (or shortlog), like
> "--full-diff". So perhaps it is best to just fix this one (which we have
> actually had a bug report about) and not worry about the rest.

That reminds me of an issue with shortlog.

I often wish to do this:

	git shortlog --since=3.day --all | sort | uniq -c

This is to catch a stupid mistake of (1) applying a few patches to 'master', (2) forking a new topic from 'master' and applying a few patches there, (3) realizing a few commits on 'master' that haven't been pushed out was faulty and rewrite the 'master' history. Such a new topic made in step (2) must be rebased on the updated 'master' built in step (3); otherwise merging the topic to 'next' will contaminate it with the old version of patches that have been rewritten on 'master'.

Alas, shortlog does not take --all.  Yes, I know

	git log --since=3.day --all | git shortlog | sort | uniq -c

is an obvious workaround, but it is mildly irritating.