Hilco Wijbenga wrote:
> Right now every rebase means a full (and almost
> completely unnecessary) rebuild.
It sounds like what you are suffering from is that "git rebase" uses
the worktree as its workspace instead of doing all that work
in-memory, right?
If I were in your situation, I would do the following:
1. Don't rebase so often. When wanting to take advantage of features
from a new upstream version, use "git merge" to pull it in. Only
rebase when it is time to make the history presentable for other
people.
This way, "git log --first-parent" will give easy access to
the intermediate versions you have hacked on and tested recently.
2. When history gets ugly and you want to rebase to make the series
easier to make sense of, use a separate workdir:
$ git branch tmp; # make a copy to rebase
$ cd ..
$ git new-workdir repo rebase-scratch tmp
$ cd rebase-scratch
$ git rebase -i origin/master
...
$ cd ..
$ rm -fr rebase-scratch
$ cd repo
$ git diff HEAD tmp; # Does the rebased version look better?
$ git reset --keep tmp; # Yes. Use it.
$ git branch -d tmp
3. Once the rebased history looks reasonably good, be sure to rebase
one final time and test each commit before submitting for other
people's use.
Hope that helps,
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html