Control Freak: more accurate suggestion for bad committer metadata
In our environment we have the “Committer must be current logged-in User” policy enabled, which occasionally results in the following error message:
remote: Control Freak
remote: -----
remote: Commit <SHA> rejected: bad committer metadata.
remote: "name user@domain" does not match your
remote: credentials. You are logged in as: "name user@domain".
remote: To see the bad commit's metadata:
remote:
remote: git show -s --pretty=fuller <SHA>
remote:
remote: Have "name user@domain" push their own commits.
remote: Or use the following git commands to fix Git configuration:
remote:
remote: git config --global user.name "name"
remote: git config --global user.email user@domain
remote: git rebase --force-rebase
remote:
remote: Note: the rebase will drop unpushed merges. Usually that's fine.
remote: -----
The hint on how the fix the problematic commits is working in many cases.
However, when there’s no tracking branch in place yet, git rebase --force-rebase
fails, because it expects a branch name:
git rebase --force-rebase
There is no tracking information for the current branch.
Please specify which branch you want to rebase against.
See git-rebase(1) for details.
git rebase <branch>
If you wish to set tracking information for this branch you can do so with:
git branch --set-upstream-to=origin/<branch> mybranch
In my experience many people are confused by Git’s response in this case.
Would it be possible to return a different error message, based on if it’s a branch creation attempt or not?
For example, it would return the current hint when there’s an existing branch:
remote: git config --global user.name "name"
remote: git config --global user.email user@domain
remote: git rebase --force-rebase
But it would return a slightly different one if there’s none:
remote: git config --global user.name "name"
remote: git config --global user.email user@domain
remote: git rebase --force-rebase master
Comments (2)
-
repo owner -
repo owner - changed status to open
- Log in to comment
This is a fantastic enhancement request. Yes, we’ll do this. I wonder if our instructions can identify a good fork point to use for the rebase (“master” aka the repository’s default branch is a good heuristic, but not bullet-proof enough in my opinion).