mirror of
https://gerrit.googlesource.com/git-repo
synced 2024-12-21 07:16:21 +00:00
8ad8a0e61d
The trick of looking at the reflog for the remote tracking branch and only going back one commit works some of the time, but not all of the time. Its sort of relying on the fact that the user didn't use `repo sync -n` or `git fetch` to only update the tracking branches and skip the working directory update. Doing this right requires looking through the history of the SHA-1 source (what the upstream used to be) and finding a spot where the DAG diveraged away suddenly, and consider that to be the rewind point. That's really difficult to do, as we don't have a clear picture of what that old point was. A close approximation is to list all of the commits that are in HEAD, but not the new upstream, and rebase all of those where the committer email address is this user's email address. In most cases, this will effectively rebase only the user's new original work. If the user is the project maintainer and rewound the branch themselves, and they don't want all of the commits they have created to be rebased onto the new upstream, they should handle the rebase on their own, after the sync is complete. Signed-off-by: Shawn O. Pearce <sop@google.com> |
||
|---|---|---|
| docs | ||
| hooks | ||
| subcmds | ||
| .gitignore | ||
| color.py | ||
| command.py | ||
| COPYING | ||
| editor.py | ||
| error.py | ||
| git_command.py | ||
| git_config.py | ||
| git_refs.py | ||
| git_ssh | ||
| main.py | ||
| manifest_xml.py | ||
| pager.py | ||
| progress.py | ||
| project.py | ||
| repo | ||
| trace.py | ||