git log --follow for directories

git log --follow for directories

[Laszlo Papp]

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.

Re: git log --follow for directories

[Junio C Hamano]

Laszlo Papp <lpapp@kde.org> writes:

> Is there any benefit about having it like it is today or is it just
> the usual "no one has implemented it yet"?

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.

Re: git log --follow for directories

[Laszlo Papp]

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

> 
> Laszlo Papp <lpapp <at> kde.org> writes:
> 
> > Is there any benefit about having it like it is today or is it just
> > the usual "no one has implemented it yet"?
> 
> 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.
> 

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.

Re: git log --follow for directories

[Jeff King]

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