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

rewrite history #5

Closed
glensc opened this issue Mar 27, 2015 · 6 comments
Closed

rewrite history #5

glensc opened this issue Mar 27, 2015 · 6 comments

Comments

@glensc
Copy link
Collaborator

glensc commented Mar 27, 2015

hi @mrclay,

i was wondering, if you be interesting doing git filter branch to trim history to include only files that are jsmin-php related.

it would be probably very good idea to do that before you merge any of the PRs here.

@mrclay
Copy link
Owner

mrclay commented Mar 27, 2015

Is this really necessary? This seems quite difficult since the files have been moved around several times. The stuff I'd want to keep:

(all current files)
min/lib/JSMin.php
lib/JSMin.php
lib/jsmin.php
lib/Minify/3rd_party/jsmin.php
lib/Minify/Javascript.php
min_unit_tests/test_JSMin.php
min_extras/unit_tests/test_JSMin.php
min_unit_tests/_test_files/js/
min_extras/unit_tests/_test_files/js/

@glensc
Copy link
Collaborator Author

glensc commented Mar 27, 2015

yes, git ls-files from current master should be kept

i'll try to make up something in my fork and see

@glensc
Copy link
Collaborator Author

glensc commented Mar 27, 2015

here's something i quickly throw together: https://github.com/glensc/jsmin-php/tree/rebase
and one with files on master only: https://github.com/glensc/jsmin-php/tree/rebase-only-master
and the above with empty commits removed: https://github.com/glensc/jsmin-php/tree/rebase-only-master-no-merges2

and finally as you wanted it:
https://github.com/glensc/jsmin-php/tree/rebase2
(but it seems broken, will check tomorrow this)

@glensc
Copy link
Collaborator Author

glensc commented Mar 27, 2015

so if you still think it's good idea, you should probably fetch the wanted master branch, git reset hard and push -f to github to ovewrite your master with the new one. (can give exact commands if needed).

and after that the pull requests should work fine.

@mrclay
Copy link
Owner

mrclay commented Mar 28, 2015

Your filtering looks good. Still not convinced it's a good idea. This is being used on Packagist; how will it affect those users?

@glensc
Copy link
Collaborator Author

glensc commented Mar 28, 2015

really up to you. but packagist problem is what? if tag by same version is recreated, it should no problem for clients to understand git forced push.

close if you reject the idea. otherwise i will have to work more on this, as somewhy last commit removed all files. huh

@mrclay mrclay closed this as completed Mar 28, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants