Thomas Rast <trast@xxxxxxxxxxx> writes: > Lukas Fleischer <git@xxxxxxxxxxxxxx> writes: > >> On Tue, Jul 02, 2013 at 10:19:36AM +0100, John Keeping wrote: > [...] >>> $ git log --oneline --follow builtin/clone.c | wc -l >>> 125 >>> $ git log --oneline --follow --reverse builtin/clone.c | wc -l >>> 3 >> >> I just wanted to point out that it works fine when specifying the *original* >> file name (which kind of makes sense given that everything is done in reverse >> order): > [...] >> However, that also doesn't seem to work for builtin/clone.c: >> >> $ git log --oneline --follow --reverse -- builtin-clone.c | wc -l >> 65 > > I'm pretty sure that is simply because --follow iis a horrible hack, > known to be broken in many ways. The machinery the follow uses simplifies the history with dynamic pathspec correctly (in a simple history, at least), but the output is coupled too strongly to the traversal. If you collect all the revs you will show first, reverse them and then try to show (which is what --reverse essentially is), the dynamic pathspec used for each rev is long gone. Perhaps we should make --follow mutually incompatible with problematic options (I suspect --reverse is not the only case) at the command line parser level to avoid hurting users. -- 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