Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move old VCS text #100

Closed
Nakhr11n opened this issue Apr 20, 2024 · 3 comments · Fixed by #293
Closed

Move old VCS text #100

Nakhr11n opened this issue Apr 20, 2024 · 3 comments · Fixed by #293
Labels
suggestion Suggestion open for discussion

Comments

@Nakhr11n
Copy link
Contributor

The old VCS text in most source files is in the way of the code.
But it is useful to keep it around for context, just not in the source files themselves.

For example it could be put in an adjacent file:
Descent3/LoadLevel.cpp (1200 lines of old VCS)
-> Descent3/LoadLevel.cpp.old-vcs

@winterheart
Copy link
Collaborator

I don't think that extracting old changelogs from source files into another is good idea. In other hand, they dot not affects on building of project. I'd keep them in source for historical purpose.

@th1000s
Copy link
Contributor

th1000s commented Apr 20, 2024

Most IDEs hide the first comment, expecting it to be some uninteresting copyright blurb - but here it is the historical VCS log.

Unfortunately, this just broke when @kevinbentley added an actual GPLv3 header :). This could be remedied by joining these two comments with a ---- separator and maybe adding a note that these are historical so nobody extends or modifies them.

@JeodC
Copy link
Member

JeodC commented Apr 25, 2024

Most IDEs hide the first comment, expecting it to be some uninteresting copyright blurb - but here it is the historical VCS log.

Unfortunately, this just broke when @kevinbentley added an actual GPLv3 header :). This could be remedied by joining these two comments with a ---- separator and maybe adding a note that these are historical so nobody extends or modifies them.

I like this, although I'm not sure if license headers are required to be in their own comment section. If this is ok to do, perhaps a script could be made to walk through everything with ease.

@JeodC JeodC added the suggestion Suggestion open for discussion label Apr 25, 2024
@JeodC JeodC closed this as completed in #293 May 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
suggestion Suggestion open for discussion
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants