From: Hilco Wijbenga Date: Fri, 16 Dec 2011 18:55:52 GMT Subject: Re: Revisiting metadata storage Message-ID: In-Reply-To: <20111216075251.GA4048@elie.hsd1.il.comcast.net> On 15 December 2011 23:52, Jonathan Nieder 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