search

HMG-Official / HMG

Other
7 stars 13 forks source link

Remove binaries from repository #9

Closed JoseQuintas closed 3 years ago

JoseQuintas commented 3 years ago

Do not include binaries, this will include 1GB for each commit to update them. You can include a link to Harbour repository, a pré-defined point, and Harbour source code will be a sub-project. Or you can create a separated repository only for Harbour/C Compiler, and add a link to it.

HMG-Official commented 3 years ago

Hi, I think apart from Executables, we can remove other Non HMG files also (like Harbour and MingW releated) What is your opinion on this?

JoseQuintas commented 3 years ago

Main point is: once they are salved, they are inside git history, to delete will not remove them from history. Best would be rewrite main history without Harbour and without C compiler.

HMG-Official commented 3 years ago

Yes, I understand. Let me try first. If you can help me out, you are welcome.

JoseQuintas commented 3 years ago

At momment forks and gitflow depends on current files. May be the best would be wait to adjust gitflow first, and rewrite the past on fucture, when all forks updates to do not have the files. The risk now is rewrite and forks sends same commits again. Not sure if a new branch could be a primary solution, and join old commits by day or month.

JoseQuintas commented 3 years ago

try several times, but no sucess. there are too many merge, and occurs conflict with no change on history. Seems that only available option is rewrite using a unique commit grouping all changes from one point to last one.

JoseQuintas commented 3 years ago

Only a news, and may be a suggestion to HMG: https://github.com/JoseQuintas/testall This project have NO FILES. But it download other projects, builds Harbour 3.4 32 bits, Harbour 3.4 64 bits, using mingw 7.3. It will build HMG, HMG Extended, HWGUI and OOHG too. It is test only.

JoseQuintas commented 3 years ago

I made a rewrite, but history of others forks will allways exists, to make syncronism. Each one is on a different point of history.

hmg
JoseQuintas commented 3 years ago

Inform users that they can merge commits before send to master. The option git rebase -i HEAD~20 // number of last commits to edit with this command, can merge (squash) commits, and delete (drop), edit, And during rebase, there is an option to abort. Do not need to send 20 tries, can send only a unique merge with result.

JoseQuintas commented 3 years ago

A comment about rewrite: I group several commits of user asistex. They continues on assistex user, but all commits are on a single commit.

The delete/rewrite commits are a checkpoint. One delete all, and another rewrite. If anybody merge wrong code, we will have a alert on theses commits, because they becomes incompatible. They are like a validation about anybody changes previous valid situation.

Now about the build: Finally my build works. On github you can use any repository, not only HMG. You can download official Harbour to make your build, or you can download mingw from another project. You can create an repository for each mingw, and use it on workflows, or MSVC, or other. You can check my testall, I create one for 3.4 and another for 3.2, and one for mingw 7.3 and another for mingw 10.2. All with mingw 32+64 bits, and all with HMG, HMG Extended, HWGUI and OOHG. - testall do not have any file, only the workflows. I want to show to libraries, that do not need setup NOTHING. It is download and use, the only thing to do, is put library on path for libraries, no other setup. And for samples, do not need setup nothing !! No batch file. On any folder of HMG or any library, you can type hbmk2 *.hbp The only setup to do, for use out of library path, can be harbour/bin/hamk.hbc, add on it libpaths=and_the_library_path for hmg.hbc (or to other library). If you do not believe, you can try it, with my changes on hbp/hbc The only thing needed is: Harbour and C compiler need to be installed and working on machine.

JoseQuintas commented 3 years ago

I will do it. Reorganizing the fork, and you will receive pull requests later.

JoseQuintas commented 3 years ago

I found some possible solutions but they allways end on a point: Repositories and forks will allways have same history. If you make a clean history on any (main or fork), on next pull request or on a user pull, all bad history will return.

Option available is download using --depth 1, to download only last 1 commit. if delete binaries from repository, users will not download all binaries on history.

Then, better option is to do nothing about history, and inform about --depth 1 option.