[SOLVED?] Recovery of deleted ports fails due to pre-commit checks

[Mathieu Arnold]

On Tue, May 04, 2021 at 12:12:50PM +0200, Stefan Esser wrote:
> Am 04.05.21 um 11:46 schrieb Mathieu Arnold:
> > On Mon, May 03, 2021 at 09:54:36PM +0200, Stefan Esser wrote:
> >> Am 03.05.21 um 09:01 schrieb Mathieu Arnold:
> >>> On Sat, May 01, 2021 at 09:01:02PM +0200, Stefan Esser wrote:
> >>>> The recovery of deleted ports in their previous form is rejected
> >>>> by the pre-commit checks on the repository server:
> >>>>
> >>>> remote:
> >>>> remote: ================================================================
> >>>> remote: Do not commit ports without TIMESTAMP in their distinfo files.
> >>>> remote: Rerun make makesum to add it.
> >>>> remote: ================================================================
> >>>> remote:
> >>>>
> >>>> I have tried to revert the deletion with unchanged files and then
> >>>> updated the ports' Makefiles and distinfo files in a later commit.
> >>>>
> >>>> Pushing those commits all together fails with the message above,
> >>>> and in order to not confuse GIT, deleted files should be committed
> >>>> first, before applying any changes.
> >>>
> >>> This is not needed at all, Git cannot get confused by something it has
> >>> no knowledge of. Once a file is deleted, or moved, the history tracking
> >>> stops.
> >>
> >> I wanted to re-connect the resurrected files to the history of the port.
> >> And that works best, if unmodified files are committed first, changes
> >> applied and committed thereafter.
> >>
> >> Did you try "git log multimedia/transcode"?
> >>
> >> The history is there, back to 2002.
> > 
> > Yeah, but this has nothing to do with you commiting unmodified files.
> > Git does not track file renames or moves (or resurrection), it blindly
> > looks at what you told it and goes as far as it can find things.
> 
> Yes, sure, but the general advice when moving around files in GIT
> repositories is: First move and commit unchanged, then modify in
> place and commit again. And I was under the impression that the
> same advice applies to files that have been deleted and are brought
> back - GIT can identify and reconnect them in a way that preserves
> history only by guessing, and I wanted to make it as easy as possible
> for GIT, since I have watched GIT to get trivial operations of that
> kind wrong in grotesque ways ...
> 
> https://github.blog/2020-12-17-commits-are-snapshots-not-diffs/#since-commits-arent-diffs-how-does-git-track-renames

Note that there are two caveats. Git will only look for files to compare
to in the parent of the commit where the files are added, so if it is a
resurrection, Git will never find out where the file came from.  Git
will only look around for a few files, like a few thousands, see
diff.renameLimit in git-config(1), as we have something like 140k files
in the tree, there is no chance for Git to actually find the original
file you moved the new file from.

So, let me say it once again, if you want to record where a file was
moved/resurrected from, describe it in the commit message.  Don't try to
be clever with special commits, Git won't care and won't find where the
file came from.

-- 
Mathieu Arnold
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20210504/1ac74a59/attachment.sig>