-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Sunday, November 17th, 2024 at 05:24, A bughunter <A_bughunter@xxxxxxxxx> wrote: > Maybe if I ask a queation a different way? What is the problem? > ADD, ADD, ADD why cant they get that: ADD. ADD tracks files for commit. It's already been commit : push failed. Failed pushes piled up. I need them untracked. How do you undo an add ( many adds) simple question. Without deleting any files, to repush 1 by 1. A. You can't fully undo an 'add' because it creates a sha-object and objects are immutable. While objects are immutable, if I do mixed mode reset switching to an old-commit under HEAD then 'add' the same files again Q. Will it keep two copies as objects? A. No because when an identical file is added the object file is identical. These become tree entries pointing to the same object. Q. May this overwrite the same object file because it is the same file? or because it is immutable will it reuse the old object file? A. When an identical file is added the old object shall be _ANSWER_HERE_ I need to delete (or switch) the commit tree object to undo the 'add' (tracking) and delete the index (staged) that references the files which failed to push. The objects can be ignored because they are the same anyway when re-adding. After the tree and index are erased I can re add-commit-push. I need to identify the tree-objects to ignore and which tree to revert to. Use git status to compare with remote. For repush the commit-id should be reverted to match with the commit-id of the remote. This resets the HEAD to reference sha-id-something for the tree-object of <old-commit-id>. Effectively untracking and leaving the git ready to re-try those failed pushs. Q. how does git status compare if it does not ssh use git log to find the commit-id? A. git status uses _ANSWER_HERE_ to compare with remote. In precaution I moved the files which had not been pushed out of the git working tree to a safer dir. ( important note: this is a precaution which the user should not need to do ) So still not sure if these files would be deleted by reset. ```--mixed Resets the index but not the working tree (i.e., the changed files are preserved but not marked for commit) and reports what has not been updated. This is the default action. If -N is specified, removed paths are marked as intent-to-add (see git-add(1)). git reset --mixed <commit-id> worked but had some funny results. The results were git status showing only the file of that revert-commit marked as deleted - presumably compared the last index from before reset, however the next 285 files were not mentioned - why . Because the status reported a match with remote I proceeded anyway not knowing why all of the files not mentioned. Q. After a reset why does status only mention a single file of the many files which are now ignored? A. The reason git status only showed, after reset, a single file marked as deleted is because _ANSWER_HERE_ Then I moved the files which had not been pushed and resumed working: workaround complete. Use-case[C] workaround completed. bugreport[A] and question[B] remain with these more questions here in this post yet unanswered. -----BEGIN PGP SIGNATURE----- Version: ProtonMail wnUEARYKACcFgmc+QCAJkKkWZTlQrvKZFiEEZlQIBcAycZ2lO9z2qRZlOVCu 8pkAAI99AQDhOYZBjPexoTNI3Vtk1kMk3fncUaR4AwmI5cWbTJzfQAEAjGKQ fZ6e65REGnoEoSq5Ml3czcG9tI+sEK+SI2f5ygA= =FW62 -----END PGP SIGNATURE-----
Attachment:
publickey - A_bughunter@proton.me - 0x66540805.asc
Description: application/pgp-keys
Attachment:
publickey - A_bughunter@proton.me - 0x66540805.asc.sig
Description: PGP signature