On 15 December 2011 23:52, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: > 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? Yes, I guess the problem is that it uses the worktree as its workspace. (I know others disagree but to me it's a bug that Git touches files that it doesn't actually change.) > 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. I usually rebase in the morning to get an up-to-date tree. Is that considered too often? Perhaps it's my Subversion background but I'm not comfortable diverging too much. Is that too paranoid? :-) So IIUC, I can do "git rebase master" even after multiple "git merge master"s? > This way, "git log --first-parent" will give easy access to > the intermediate versions you have hacked on and tested recently. Why is "git log --first-parent" important? I read "git help log" on first-parent but that didn't really tell me much. Google was not very helpful either. > 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 This is in my merged branch, right? > > $ 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 Interesting. If I run the rebase after the merge, rebase appears to do much less work. I.e. it appears to only touch files that have actually changed. Is that true? > 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, Yes, thanks for pointing out yet more useful Git options. There seems no end to them. :-) Cheers, Hilco -- 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