On Mon, Jun 26, 2023 at 06:42:17PM +0200, Sebastian Schuberth wrote:
> On Mon, Jun 26, 2023 at 5:55 PM Junio C Hamano <gitster@xxxxxxxxx> wrote:
>
> > > PS: As a future idea, it might be good if "git mv" gives a hint about
> > > updating .gitattributes if files matching .gitattributes pattern are
> > > moved.
> >
> > Interesting. "git mv hello.jpg hello.jpeg" would suggest updating
> > a "*.jpg <list of attribute definitions>" line in the .gitattributes
> > to begin with "*.jpeg"?
>
> Yes, right. Or as a simpler variant to start with (as patterns might
> match files in different directories, and not all of the matching
> files might be moved), just say that a specific .gitattributes line
> needs updating (or needs to be duplicated / generalized in case files
> in both the old and new location match).
Yeah, I don't think we could ever do anything automated here; a human
needs to judge the intent and how the patterns should be adapted.
But perhaps something like:
1. When git-commit makes a new commit that removes paths (whether they
were totally removed, or renamed), find all gitattribute lines
whose patterns match those paths.
2. For each such pattern, see if it still matches anything in the
resulting tree.
3. If not, print advise() lines showing the file/line of the pattern
which is no longer used.
Doing so naively (by checking matches for each file in the tree) would
be a little expensive, but maybe OK in practice. It could perhaps be
done more efficiently with specialized code, but it might be tricky to
right (and you still end up O(size of tree) in the worst case, because
something like "*.jpg" needs to be compared against every entry).
Of course on the way there you should end up with a decent tool for
"which patterns are not currently used?". And you could just
periodically run that manually if you want to clean up (or even from a
post-commit hook).
Re-reading your email, though, I wonder if you meant something a little
simpler, like:
1. When a path is moved via git-mv, see if the attributes before/after
are the same.
2. If not, then mention which ones matched the old path via advise().
That is probably easier to write, though it does not help the "git rm"
case (where attributes may become obsolete).
-Peff
