Purge team.txt from Git's history #25
Conversation
Conflicts: src/GiveCRM.DataAccess/Members.cs
Conflicts: src/GiveCRM.Web/Views/Campaign/Show.cshtml
Conflicts: src/GiveCRM.Web/Views/Campaign/Show.cshtml
Conflicts: src/GiveCRM.Web/Views/Campaign/Show.cshtml
Update ExcelImportService to use IMemberService for data access
…sponsive UI during long-running processes
…ough the UI - default range is still 5 to 100
…gn; generate some donations with fractions of a Pound/dollar
…rovider and Forms authentication. Provided tests for contoller and new urlValidation service
Make ExcelImportController asynchronous again
Reviewed code changes that refactored out membership dependency.
Removing the need to use Moq as we had settled on NSubstitute
|
Will do; I'll have to do the merge manually due to its nature. -----Original Message----- Kendall (or whoever merges this pull request), please deal with this before the other outstanding pull request. This pull request purges the team.txt file from having ever existed in our git repository. As a result, it rewrites all 539 preceding commits to the repository. Hopefully, it will merge cleanly! IMPORTANT NOTE: If you have created a branch off master that is still active, you will need to You can merge this Pull Request by running: git pull https://github.com/alastairs/GiveCRM 7642eba Or you can view, comment on it, or merge it online at: -- Commit Summary --
-- File Changes -- M .gitignore (17) |
|
Ok im concerned about this pull request - I understand peoples email addresses are in the repo but with 14 forks already out there it seems dangerous to purge the entire system - 539 commits - in order to remove something that has been in circulation in over a week Shall we just delete the file and not worry about the ourge to save the hassle of a manual merge? If everyone feels strongly about removing the file then I can take care of the merge |
|
Personally, I'd prefer it to have never existed in the repository so it can't be brought back from the dead sometime in the future. I do get that it's a tricky thing to apply, though, and will likely be for people's forked repositories too. If I'm in the minority in my view, I'll cope :-) I thought it was better to get it done now whilst activity is (relatively speaking) low rather than later on when the repository is larger and there are potentially even more forks. |
|
I can see the potential for concern so if the merge can be done quickly then I think it's worth it. |
|
-1 from me for same reasons as @stack72. One of the central tenants of rebasing is "you don't change what is already public". The genie is out of the bottle and it is impossible to get back in. People are already working on forks and it shall be all but impossible to stop them. The cleanest way to resolve this if it does go ahead is to make this change, get everyone to remove their forks, refork, then clone their new repo. Which imo is too ugly, convoluted and error prone to actually work in practice. On the other hand the longer we leave this, the more of a headache it shall become, if we do choose to do this then we should document that this is breaking change get everyone to stop work and recreate their forks and get it done sooner rather than later (as any new commits after this shall render this rebase invalid I believe). //My email never got into team.txt, my opinion is invalid |
|
I'm currently doing this now - Git is just working through ALL of the commit history - over 1000 commits :) |
Kendall (or whoever merges this pull request), please deal with this before the other outstanding pull request.
This pull request purges the team.txt file from having ever existed in our git repository. As a result, it rewrites all 539 preceding commits to the repository. Hopefully, it will merge cleanly!
IMPORTANT NOTE: If you have created a branch off master that is still active, you will need to
rebaseand not merge to incorporate this pull request. Merging will most likely cause horrible conflicts.