Is there some kind of 'git rebase –dry-run', which would notify me of conflicts in advance?

I’m trying to script rebasing and my script will take different paths depending on if the rebase results in any conflicts.

Is there a way to determine if a rebase would result in conflicts before executing the rebase?

  • Can I clone from remote repository, but treat my local version as if it was created using 'git init'?
  • removing a repo from a group in gitolite
  • git: how to retrieve all files as of a certain date
  • Using git filter-branch with Python subprocess module
  • How to partially stage a file with LibGit2Sharp?
  • How do I fast foward branches without switching to them?
  • Github-like Issue and Milestones Tracking in Xcode 5
  • Can't get stdout/stderr from (Python) subprocess.check_output()
  • Basic Git without the porcelain?
  • Merge (no branch) into master
  • How does git compare files?
  • Git rebase ignoring same changed lines
  • 3 Solutions collect form web for “Is there some kind of 'git rebase –dry-run', which would notify me of conflicts in advance?”

    At the time of writing (Git v2.6.1 v2.10.0), the git rebase command offers no --dry-run option. There is no way of knowing, before actually attempting a rebase, whether or not you’re going to run into conflicts.

    However, if you run git rebase and hit a conflict, the process will stop and exit with a nonzero status. What you could do is check the exit status of the rebase operation, and, if it is nonzero, run git rebase --abort to cancel the rebase:

    git rebase ... || git rebase --abort

    I suspect that git rebase ... --dry-run is not possible, for the following reason.

    When you’re doing a git rebase, git will rollback to the starting point, then incrementally apply patches for each commit to bring the branch up to date. If it hits a conflict, it will stop & wait for you to resolve the conflict before continuing. The path that the rebase takes after that conflict depends upon how you resolve the conflict – if you resolve it a certain way, that might introduce (or eliminate) later conflicts.

    Thus, git rebase ... --dry-run would only be able to give you the first conflict – reports of later conflicts will depend upon how that first conflict is resolved.

    The only way I can think of doing this would be via git diff between the current position and the last commit in the branch you’re rebasing to. But that won’t really give you what you’re looking for – you really just need a list of conflicting changes between the two points. There might be a way to do it with git diff, but it’s not a normal patch.

    You still can do git rebase, play with it as you want, than recover all the changes from before.
    Assuming you have done your rebase of some branch into the master, and you don’t like it:

    1. git reflog -20 – gives you last 20 positions of your HEAD with a little description
    2. git checkout <the_branch_name> – places your HEAD on the branch
    3. git reset --hard <old_sha1_found_in_reflog> – places your HEAD and branch on the old ref, this way you can recover old branch.

    There are some mechanics to understand here:

    1. You NEVER delete anything in git, not with commands, anyway. Its the garbage collector that comes through and deletes unreferenced branches (default 3 months). So your branch, from before the rebase, still exists.
    2. Same goes for the on same branch rebase, its just a new tree rewritten next to the old one.
    3. All the history of rebase and your other on HEAD manipulations is written in the reflog
    4. You can use @{N} annotations from reflog

    So, nothing is lost after the rebase, you just have to know how to find and recover it.

    For example you can place yourself a tag before the rebase than revert to it or delete it. it evades you all the SHA1 research step.

    Git Baby is a git and github fan, let's start git clone.