4

I created a project on GitHub, which other people contributed to. Now I realized I have been logged into the wrong GitHub user on my laptop where I have committed to this repository from.

There are other people in the commit history at this point as well. As the owner of the repository(from the actual user I intended to commit from), is there any way I can "transfer" my commits from one user to another retrospectively, removing everything from the "WRONG_USER", and adding it to "RIGHT_USER" without deleting the entire .git, and starting from scratch(since the other contributors commits would have to remain)?

Thanks :)

cbll
  • 6,499
  • 26
  • 74
  • 117
  • Changing the details of commits (like the user, mail address, ...) changes the history of the corresponding branch. In most cases this is undesired, and I suggest you clarify if this would be OK. – C-Otto Jan 22 '18 at 13:49
  • It would be fine. Where does one do so? – cbll Jan 22 '18 at 13:49
  • Possible duplicate of [Change commit author at one specific commit](https://stackoverflow.com/questions/3042437/change-commit-author-at-one-specific-commit) – phd Jan 22 '18 at 14:25

3 Answers3

3

You are in a bit of a pickle.

Commits are immutable, and author information is on the commit.

This means that you can't move commits to a different author without rewriting history.

If you are the owner of the "wrong" email-address another solution would be to add that secondary email-address to your GitHub account.

This can be seen in this image: Multiple Emails on one account

This will not change the author of the commit, but will in GitHubs interface make you appear as the author.

RandomSort
  • 600
  • 7
  • 22
  • How can I add the other email as a secondary address, when it's already used for another Github user? It will throw an error. – cbll Jan 22 '18 at 13:58
  • Yes, that is unlikely to be successful. As said you are in a pickle. There are no good solutions :) – RandomSort Jan 23 '18 at 06:58
3

You can not add WRONG_EMAIL as a secondary email for the RIGHT_ACCOUNT since you have already used WRONG_EMAIL created another github account (let’s call it WRONG_ACCOUNT here).

There are ways to change the commits from WRONG_USER to RIGHT_USER:

Option 1: delete the WRONG_ACCOUNT

If it’s unnecessary to use the WRONG_ACCOUNT, you can delete the account.

In the WRONG_ACCOUNT settings page -> Account -> Delete your account.

enter image description here

Then you can add the WRONG_EMAIL as a secondary email address for the RIGHT_ACCOUNT.

Option 2: rewrite commit history

You can use below script to change the WRONG_USER to RIGHT_USER:

git filter-branch --commit-filter '
        if [ "$GIT_AUTHOR_EMAIL" = "WRONG_EMAIL" ];
        then
                GIT_AUTHOR_NAME="RIGHT_USERNAME";
                GIT_AUTHOR_EMAIL="RIGHT_EMAIL";
                git commit-tree "$@";
        else
                git commit-tree "$@";
        fi' HEAD

Then you can force push the changes to your github repo by git push -f --all.

Community
  • 1
  • 1
Marina Liu
  • 36,876
  • 5
  • 61
  • 74
  • Option 1 is a possibility; in a week I will no longer need the account. So I will delete it, and transfer the email to my main account. Thank you! – cbll Jan 23 '18 at 08:23
1

Well, someone asked you if rewriting history is ok (but didn't explain the consequences), and you replied that it is ok (though I doubt you understand the consequences), so let's clarify that.

If you rewrite history, then every other user's repository will be broken. Not "broken beyond repair", but broken nonetheless. They'll have to take steps to fix them; and if you want them to fix them "the right way" - which is to say, without undoing your history rewrite - then you'll need to let them know in advance what's happening and what they need to do.

If that still seems ok, and worth the trouble for what you'll gain, then it can be done. I'll go ahead and point out that if I were a contributor to your project, I would not be pleased having the decision forced on me, that extra effort on my part is "worth it" to correct an aesthetic problem that was not of my making.

The situation in which your users will find themselves is described in the git rebase docs under Recovering from Upstream Rebase. So I'd start by looking that over. When rewriting the entire repository history, my general advice is to have everyone push all of their code to origin and discard their clones, then do the rewrite, then have everyone re-clone; because repairing an old clone after the rewrite is likely to be a serious hassle.

If, in the end, you decide to do the rewrite anyway, you would use git filter-branch with the --env-filter argument.

metamattj
  • 148
  • 9
Mark Adelsberger
  • 42,148
  • 4
  • 35
  • 52