Re: Revisiting metadata storage

On 15 December 2011 23:52, Jonathan Nieder [off-list ref] wrote:

Hilco Wijbenga wrote:

quoted

                       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