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

Remove myself from AUTHORS #544

Closed
wants to merge 62 commits into from
Closed

Remove myself from AUTHORS #544

wants to merge 62 commits into from

Conversation

sorbits
Copy link
Contributor

@sorbits sorbits commented Jun 27, 2016

This removes my email from AUTHORS as I do not want it there.

This rewrites two commits that change AUTHORS and must be force-pushed to GitHub to erase the old history (that has my email).

Suggested instructions for “merging” this change:

git remote add -f sorbits [email protected]:sorbits/git-extras.git
# Verify there is only one change (to AUTHORS)
git diff origin/master sorbits/master
git push -f origin sorbits/master:master

al-the-x and others added 30 commits June 27, 2016 09:38

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
Blind first pass so that I have a PR to remind me...
Make `git-touch` behave like `touch` when passed multiple files.
Update windows install instructions.
User visible:
* Also accept the git install path (and not the mingw64 subdir) as a user
  supplied install location. Make it the new default and warn the user if
  a mingw64 dir is supplied (=this dir is not checked, so it might be
  anywhere...)
* Find git.exe in path and use that as an install location
* Add error|status messages and output less noise (robocopy)
* do some check if column.exe is not found...
* adjust the installation text for windows...

not user visible:
* more.exe does not work when used in a cmd which has a unicode codepage
  -> save the current codepage and set a sane default during the install
* do some "magic" with quotes around path variables -> makes it work with
  pathes with spaces in it (both final git dir and the git-extra checkout)
* Do not leak variables to the sourounding interpreter
Makefile: fix inverted list of commands that use is_git_repo
Make the win installer more robust
Add BSD installation instructions.
This was a regression introduced by the useage of `enabledelayedexpansion`,
which results in `!` treated as variable identifier like `%`. The result
was that git didn't treat the scripts as git commands...
This was happening earlier as well, but the error messages were the
raw messages from the failed writes...
column.exe will be available in the next git release:
git-for-windows/build-extra#92

Also convert tabs to spaces... Was mixed up to now :-/
Update git PR manual to mention URLs
There is no pgrep in git for windows
hemanth and others added 22 commits June 27, 2016 09:39
Add Fedora package-manager installation instruction
Update with the upstream
Mention initial copyright year and add contributors to copyright
Fix ignore-io searching bug
	Modify git-clear to indicate default behavior of removing git ignored files
Add -m flag to git-setup to set the initial commit message.
Add git clear-soft, modify git clear to indicate explicit removal of files
update documentation. fix "git ignore-io" flags
fix the support for forking via ssh
@sorbits
Copy link
Contributor Author

sorbits commented Jul 10, 2016

When can I expect you to remove my email address?

@nicolaiskogheim
Copy link
Collaborator

Hi, and sorry for taking so long. We shall try to be swift about this, but this demands a little planning from our side so I will need to discuss how to approach this. The discussion is mainly targeted at the contributors who, in the end, will have to clean up the mess we've created, but if you @sorbits, or anyone else have questions we should consider, or experience with doing this (force pushing to an active remote branch with multiple PRs pointed at it) it's of course welcome.


I'm not entirely sure about how to best do this, but it seems there are two options. Either way we will have to force push rewritten history which will break all pull requests.

So let's say I force push the rewritten history. Now all pull requests will be conflicting, and it will look like everyone is trying to submit about 50 commits. This will confuse those not familiar with the situation.

Our options:

  1. We can ask pull requesters to fix their PR, by pulling down the new master, and re-applying their commits onto that, in the branch the PR is pointing at. This may be uncomfortable for certain users.
  2. We as contributors can close all PRs, and label them for re-opening perhaps, and create new PRs with the history fixed. This may or may not be more work on our hand. We have to it properly, though; use the commits and not just make the changes manually. We wouldn't want to "steal" commits of people by accidentally having the author id being set to some of ours.

There is maybe a third option: Let's say we write a little text explaining what has happened, and post it in every open PR. It would go something like "fix this and update the PR or ask for help" and we could provide commands for doing it, but advise that they let us do it if they're afraid to mess things up.

We have about 20 open PRs, but most of them are old and should be closed. This is an opportunity get rid of dead PRs, and we could always cherry-pick stuff if we want it.


Another issue is what to do with the 584 forks we invalidate. I think it warrants an explanation in the Readme at the least. People can either delete the fork and fork anew, or git reset --hard upstream/master and juggle their way from there if they have commits they want to preserve.

@szpak
Copy link

szpak commented Jul 21, 2016

@nicolaiskogheim In general pushing with force to master is a very bad idea for every project. You mentioned PRs, but there are also hundreds of forks with changes made by other people. In addition, a lot of people for sure have local clones of this repo and after the next "git pull" they would get very strange and confusing error message. Having local changes it will be really hard to merge them with the new upstream (after the history rewrite) and it definitely will not help project to attract external contributions.

@sorbits In the Internet things made publicly tend to stay in that or another form (e.g. compromising photos). Even rewriting this repository lefts 500+ other forks. At least part of them have that ill-fated commit. I bet that you will not be able to convince all those people to do the same. Apart from that there is RSS feed for every GitHub repository and that information has been propagated to many external systems aggregating data from GitHub (here's a story about stealing EC2 token even after the author rewrite the history with "push force").

To sum it up. IMHO this is (technically) a very bad idea to do push with force to master, especially that the expected results (removing email address definitely) will not be achieved. I would propose to just remove an email in one "normal" commit to not have it available in the current version.

@nicolaiskogheim
Copy link
Collaborator

@szpak I did mention the forks, but you pointed out something that slipped my mind which is very important here, and that is that whatever we do here, the commit will still exist in the forks.

@sorbits
Copy link
Contributor Author

sorbits commented Aug 3, 2016

I created PR #564 to remove my email from AUTHORS without rewriting history.

Though had I added someone’s non-public email address to a repository that I control I would not hesitate to rewrite history. For semi-experienced git users it should not be difficult to handle rewritten history.

@hemanth hemanth closed this Aug 5, 2016
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

Successfully merging this pull request may close these issues.

None yet