Re: git annotate runs out of memory
- From
- Marco Costalba <mcostalba@gmail.com>
- Date
- Dec 11, 2007, 20:29 UTC
- Message-ID
- <e5bfff550712111229i227361e9s1a6dcbed9a13019d@mail.gmail.com>
- In-Reply-To
- <4aca3dc20712111109y5d74a292rf29be6308932393c@mail.gmail.com>
On Dec 11, 2007 8:09 PM, Daniel Berlin <dberlin@dberlin.org> wrote:
Show 5 quoted lines
> > In GCC history, it is likely you will be able to cut off at least 30% > of the time if you do this, because files often have changed entirely > multiple times. >
This could be useful for a command line tool but for a GUI the top down approach is a myth IMHO.
In the GUI case what you actually end up doing (because a GUI allows it) is to start from the latest file version, check the code region you are interested then when you find the changed lines you _may_ want to double click and go to see how it was the file before that change and then perhaps start a new digging.
I found this is my typical workflow with annotation info because I'm more interested not in what lines have changed but _why_ have changed and to do this you naturally end up digging in the past (and checking also the corresponding revisions patch as example in another tab)
In this case the advantage of oldest to newest annotation algorithm is that you have _already_ annotated all the history so you can walk and dig back and forth among the different file versions without *any* additional delay.
Marco