On Tue, May 19, 2015 at 02:56:48PM +0100, Laszlo Papp wrote:
> I have just realized that this would not work on directories
> triggering directory renames somewhat pointless for those who want to
> keep track of a group of files in directories.
>
> It is unfortunate when you have a directory with many files and more
> often than not, you would like to look at the history of all rather
> than individually.
>
> Is there any benefit about having it like it is today or is it just
> the usual "no one has implemented it yet"?
I have fooled around with accepting a full pathspec for --follow, rather
than a single file. In the single-file case, if we see a rename of "A"
to "B" (and we are following "B"), we switch to following "A". With a
pathspec, that is not right. If you are following "foo" and "foo/A" is
renamed to "bar/A", you would want to start following "bar/A", but you
would _not_ want to stop matching "foo" (because you want to still look
at "foo/B").
The most correct thing would be to match ("!foo/A", "foo", "bar/A").
That is, once we follow a rename, it is explicitly excluded from the
pathspec. It is much simpler to just do ("foo", "bar/A"). I.e., just
always add to the pathspec, but never take away. It is not correct, but
it works OK in practice (and it always shows more than you might be
interested in, not less).
Junio mentioned the other problem: our pathspec is global, but it
actually should follow the graph itself. This is orthogonal to the
question of whether we are matching one file or several, but in practice
I suspect matching several files may make it worse (that is, the
inaccuracies would surface more frequently).
The right way to do --follow is something like:
1. Topo-sort the commits. Attach the initial pathspec to each of the
initial tip commits. Do our usual walk backwards (respecting the
topo-sort).
2. If there are no renames to follow in a commit, attach the pathspec to
its parents.
3. If there is a rename, make a new pathspec (as above) to attach to
the parents.
4. When we try to attach a pathspec to a commit that already has one,
we need to reconcile the two. I haven't thought hard about it, but
it's probably something like a union of the two pathspecs. E.g.,
consider a traversal starting at two tips, and we're interested in
path "B". One line of commits renamed "A" to "B", so we start
matching "A". The other created it from scratch. When we come to
the shared ancestor of the two branches, we are probably interested
in both "A" and "B".
But like I said, I haven't really thought hard about it. That's
just my intuition.
-Peff
--
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