Can I rebase a Git branch without modifying my working copy?

Question

Suppose I have my "master" branch checked out. I've committed some production changes to "master", and now I want to rebase my "experimental" branch onto the latest master. But, I want to do this without modifying any files in my working copy. Essentially, I want all the magic to happen inside the .git directory, without touching the working copy.

If not for the "don't modify my working copy" requirement, this would just be a matter of doing:

# current branch is master git checkout experimental git rebase master git checkout master 

My real problem is that this modifies timestamps in my working copy, even though I'm ending by checking out the exact same content I started with. As soon as I run "git checkout experimental", any files that contain changes in the experimental branch will get their mtime set to the current time -- and so will any files that were changed in master since the last time I rebased experimental. Because the mtimes have changed, things like build tools get the idea that there's work they need to do again, even though, by the time I'm done, the files' contents haven't actually changed. (In my case, it's that if a project file's timestamp changes, Visual Studio thinks it needs to spend a lot of time unloading and reloading the project.) I want to avoid that.

Is there a way to do all of the above in one step, without ever modifying anything in the working copy (assuming there are no conflicts during the rebase)?

(If there are conflicts, my preference would be to show the error and then abort the entire operation, without ever modifying any timestamps. But that's just my preference, not a hard requirement -- I don't know what all is possible.)

Of course I can write a script to capture the mtimes, run git, and then reset the mtimes; but it seems likely that Git would already have a way to do things like rebase without bothering the working copy, since the rebase is really about the deltas, not the files' actual contents.

Answer 1

Since git 2.5, an even better solution is to use a second worktree.

A git repository can support multiple working trees, allowing you to check out more than one branch at a time.

$ git worktree add ../second-copy experimental $ cd ../second-copy/ $ git rebase master experimental 

And that's it. Afterwards, you can rm -rf second-copy if you want, or keep it for more rebases in the future.

$ git rebase master experimental