Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 4 May 2021 12:12:50 +0200
From:      Stefan Esser <se@freebsd.org>
To:        Mathieu Arnold <mat@freebsd.org>
Cc:        FreeBSD ports <freebsd-ports@freebsd.org>
Subject:   Re: [SOLVED?] Recovery of deleted ports fails due to pre-commit checks
Message-ID:  <c05df6a0-d471-5e27-022b-784c535c3fdb@freebsd.org>
In-Reply-To: <20210504094653.3m27ucqa3hotsusw@aching.in.mat.cc>
References:  <2c1ab5d2-d885-8f8d-94dd-99d0a5559a88@freebsd.org> <20210503070134.bydnbc2eah7st2on@aching.in.mat.cc> <6041a16c-a114-2896-7162-39b59110b782@freebsd.org> <20210504094653.3m27ucqa3hotsusw@aching.in.mat.cc>

next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--LNlZfEGy7R9r9aPlfXcSC5QrgC9hhP24i
Content-Type: multipart/mixed; boundary="rAcf3DpOZWre8p3qcZhGXayOK3bJ9HaJn";
 protected-headers="v1"
From: Stefan Esser <se@freebsd.org>
To: Mathieu Arnold <mat@freebsd.org>
Cc: FreeBSD ports <freebsd-ports@freebsd.org>
Message-ID: <c05df6a0-d471-5e27-022b-784c535c3fdb@freebsd.org>
Subject: Re: [SOLVED?] Recovery of deleted ports fails due to pre-commit
 checks
References: <2c1ab5d2-d885-8f8d-94dd-99d0a5559a88@freebsd.org>
 <20210503070134.bydnbc2eah7st2on@aching.in.mat.cc>
 <6041a16c-a114-2896-7162-39b59110b782@freebsd.org>
 <20210504094653.3m27ucqa3hotsusw@aching.in.mat.cc>
In-Reply-To: <20210504094653.3m27ucqa3hotsusw@aching.in.mat.cc>

--rAcf3DpOZWre8p3qcZhGXayOK3bJ9HaJn
Content-Type: text/plain; charset=windows-1252
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

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: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>> remote: Do not commit ports without TIMESTAMP in their distinfo file=
s.
>>>> remote: Rerun make makesum to add it.
>>>> remote: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>> 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 ha=
s
>>> no knowledge of. Once a file is deleted, or moved, the history tracki=
ng
>>> stops.
>>
>> I wanted to re-connect the resurrected files to the history of the por=
t.
>> 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.
>=20
> 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-com=
mits-arent-diffs-how-does-git-track-renames


--rAcf3DpOZWre8p3qcZhGXayOK3bJ9HaJn--

--LNlZfEGy7R9r9aPlfXcSC5QrgC9hhP24i
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEo3HqZZwL7MgrcVMTR+u171r99UQFAmCRHiIFAwAAAAAACgkQR+u171r99UQi
4QgAgTz+WYEdgus3ouCDdjNBtCr5AiERT3zMWpA5bjAX1eSmMD3HU6/IvQ6/IIZgnnsijC+td5+G
l3HNoOz3PqQhB/ljBVSw7914cNUmIJI74E/Bu6BjnWPhnVrgTGV9Xt2Vyz+V85uThkErkZ2agYkK
SHriMazTvc5JC48lPhhSYGSgYeItGJYHgxHzqVBJKxf3jLK+JVuhb5eczoJRF8NAUW8/iKzdJzyx
aL+9EGsF3nT3xI21TOp2Gqq5V/4j0pPfO40DXO7yNI1iWhI6VABKabLR9dZ5R1jhE5fufql/fQ1S
SGfPW9DaHMzSNBg2drzbWiVe2e2zmzHp2xNIE9fGVw==
=nyML
-----END PGP SIGNATURE-----

--LNlZfEGy7R9r9aPlfXcSC5QrgC9hhP24i--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c05df6a0-d471-5e27-022b-784c535c3fdb>