Re: [SOLVED?] Recovery of deleted ports fails due to pre-commit checks
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 signature.asc Description: PGP signature
Re: [SOLVED?] Recovery of deleted ports fails due to pre-commit checks
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 OpenPGP_signature Description: OpenPGP digital signature
Re: [SOLVED?] Recovery of deleted ports fails due to pre-commit checks
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. -- Mathieu Arnold signature.asc Description: PGP signature
Re: [SOLVED?] Recovery of deleted ports fails due to pre-commit checks
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. OpenPGP_signature Description: OpenPGP digital signature
Re: [SOLVED?] Recovery of deleted ports fails due to pre-commit checks
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. -- Mathieu Arnold signature.asc Description: PGP signature
[SOLVED?] Recovery of deleted ports fails due to pre-commit checks
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. Apparently this is not possible, and I cannot re-order the commits in such a way, that the distinfo change is merged in to the initial commit. I'm now going to try with 10 commits squashed into 1, to make the distinfo update appear to be part of the initial commit. This will make it much harder to distinguish the reversal of the deletion from later changes, though. The squashed commit has worked - the multimedia/transcode port and dependent ports that had been deleted should be restored and fixed. It is thus possible to commit a reverted port, but I had rather kept the commit log entries separate and more comprehensible. Regards, STefan OpenPGP_signature Description: OpenPGP digital signature
