Re: Revisiting metadata storage
- From
- Hilco Wijbenga <hilco.wijbenga@gmail.com>
- Date
- Dec 16, 2011, 18:55 UTC
- Message-ID
- <CAE1pOi2GW=3o7QgTEcUYbjif3WokpVdgL6UdKXu9x0yKH-vrGw@mail.gmail.com>
- In-Reply-To
- <20111216075251.GA4048@elie.hsd1.il.comcast.net>
On 15 December 2011 23:52, Jonathan Nieder <jrnieder@gmail.com> wrote:
Show 8 quoted lines
> 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.)
Show 6 quoted lines
> 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?
Show 13 quoted lines
> > $ 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?
Show 5 quoted lines
> 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