git log --follow for directories

Hi,

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"?

Cheers, L.

PS.: I will not stand up for implement this though, but of course I will be very grateful if someone else decides to do so.

Laszlo Papp <lpapp@kde.org> writes:

It actually is even more sketchy than that. A single file following was done merely as a checkbox item that works majority of the time, and any mergy history that renames the file on one side of the side branch but not on the other may not truly follow it.

Junio C Hamano <gitster <at> pobox.com> writes:

Well, in worst case, why not have something like --follow-dirs, then?

The case at hand is that we unfortunately named a directory based on the codename of some software for the time.

Now, we have improved that software and the codename is different accordingly. Now, instead of "pastcodename", I would change the directory name to "src" to be future proof, but here, I face these difficulties:

1) The directory name is stuck with some ancient codename and it therefore
will be confusing for the rest of the life cycle for this project.

2) We get unfollowable directories. At best, we could use some scripts to
work this around, but why not address this directly in git?

I think renaming a directory without losing the history would be really cool to have, one way or another. If that requires a separate option, I am happy with that, but what I would really like to avoid is not being able to rename directories without losing the history.

Note that I am speaking from user point of view. I do not know the nitty-gritty technical details, but that is just implementation details as far as I am concerned, anyway.

On Tue, May 19, 2015 at 02:56:48PM +0100, Laszlo Papp wrote:

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