Re: GSoC draft proposal: Line-level history browser
- From
Bo Yang <struggleyb.nku@gmail.com>
- Date
- Mar 24, 2010, 02:30 UTC
- Message-ID
- <41f08ee11003231930t3508994atb7cfc6bb354048@mail.gmail.com>
- In-Reply-To
- <20100323195724.GA1843@progeny.tock>
Hi,
On Wed, Mar 24, 2010 at 3:57 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
Show 27 quoted lines
> Bo Yang wrote: > >> It traces the preimage of the minimum related diff hunk carefully, if >> there is any case that there are more than one commit intersect with >> the preimage, we will stop and ask the users to select which way to go >> on tracing. > > That might be necessary, but I will admit that I suspect it to be > harder to make useful. One of the very nice things about ‘git log’ is > that it is easy to browse through history in a nonlinear way in a > pager (by using a pager’s search functionality). The “backend” ‘git > rev-list’ is easy to write scripts with, also because of its simple > input and output. > > If your program requires input from the user, how will it paginate its > output? Most pagers expect the standard input to be available for > input from the user. > > One approach (I will not say it is a good one) to the problem of > ambiguous origins for a line is to blame _both_ parents. That is, > start following both lines of history in your revision walking. > Perhaps higher-level tools like ‘git log --graph’ and gitk could > visually represent the branched history you are showing. > > Another approach is to just choose one parent automatically: for > example, prefer the first parent, or assign some score representing > the relatedness of each parent and choose the most related one.
Both the approach is very precious for me. I think maybe I will propose the first one in my real proposal to Git, thanks a lot! You really help my too much! Thanks!
Regards! Bo