29.11.17 20:47, Ryan Gonzalez пише:

Doesn't Git make this rather easy, though?

e.g. you can find all deleted files with:

git log --diff-filter=D --summary

and find a specific file with (showing glob patterns):

git log --all --full-history -- **/thefile.*

and then show it:

git show <SHA> -- <path-to-file>

or restore it:

git checkout <SHA>^ -- <path-to-file>

https://stackoverflow.com/questions/7203515/git-how-to-search-for-a-deleted-...

Thank you Ryan. I didn't know this. But the first command produces much noise. It includes reverted changes that added new files (they could be reapplied again), files Misc/NEWS.d/next/ which were merged into Misc/NEWS, and full content of deleted directories. If the list of deleted files be supported manually, it would contain only the root of deleted directories, and wouldn't contain files which were not released.

Hi, Serhiy opened this thread after I removed tools for CVS and Subversion from the master branch: two scripts and a svnmap.txt file. I removed Misc/svnmap.txt, a mapping of Subversion commits to Mercurial commits. The change was approved by 3 core dev, but then I was asked to restore (only) the svnmap.txt and so I reverted it. See the issue and the pull request for the full story: https://bugs.python.org/issue32159 https://github.com/python/cpython/pull/4615 I misunderstood the purpose of the file. I understood that it was used by removed scripts, whereas it was kept for historic purpose, to find Suversion commits like r12345. The mapping maps to Mercurial commits, whereas the CPython repository was converted to Git in the meanwhile. The last 3 years, I someone need to get access to an old r12345 commit, but it was always in messages on the bug tracker which is able to give me a working link to the actual change. Victor Le 29 nov. 2017 8:03 PM, "Guido van Rossum" a écrit :

That sounds a bit excessive. Is there a recent incident that inspired this proposal?

On Wed, Nov 29, 2017 at 10:26 AM, Serhiy Storchaka wrote:

...

After removing files from the repository they disappear from the source tree, and it is even hard to notice this if you don't use it regularly. It is hard to track the history of the removed file even if you know it exact path. If you know it only approximate this is harder.

I think that any file removals from the repository should pass some PEP-like process. Declaring the intention with the rationale, taking a feedback, discussing, and finally documenting the removal. Perhaps it is worth to track all removals in a special file, so if later you will find that the removed file can be useful you could restore it instead of recreating its functionality from zero in the case if you even don't know that similar file existed.

_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40p ython.org

-- --Guido van Rossum (python.org/~guido)

_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ victor.stinner%40gmail.com

Hm. For the file used for lookup, I see the point of keeping it. But in general, I don't see the point of keeping files we no longer need -- that's what VCS systems are for! On Wed, Nov 29, 2017 at 2:28 PM, Serhiy Storchaka wrote:

29.11.17 21:00, Guido van Rossum пише:

...

That sounds a bit excessive. Is there a recent incident that inspired this proposal?

The concrete inspiration is issue32159 [1]. I am still not sure that removing these scripts is needed. But there were other cases in which I was not sure about the rationale of removing files.

https://bugs.python.org/issue32159

_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido% 40python.org

-- --Guido van Rossum (python.org/~guido)