Hi Bo, *
As a brief introduction to people who haven't been following, and
partially answering an earlier question in another thread:
David Lang wrote:
> what is this series?
>
> this is all good incramental information, but there's no info indicating
> what this is updating.
For me it replaces a manual iterative process to find out in what ways
a function was patched until it came to have its current shape:
git-blame the area, find the most recent commit C
while 1:
git show C
if that explains the code: break
git-blame the area in C^
find the most recent commit and call it C again
I do this a lot when a particular section of code puzzles me or seems
buggy, to see if any commit message provides a reason for it. I think
(but I never got good with it) the "blame parent" feature of 'git gui
blame' covers a similar use-case.
All of this can now be replaced by a simple
git log -L <range> <filename>
A good example that I did a lot of testing with:
git log --graph be58e70d^ -L /builtin_funcname_pattern/,/^}/ diff.c
Try it. I can follow up with more examples if you're interested, but
it's much more fun if you're actually looking for some explanations.
As for the project: First off, many thanks Bo for all the work you put
into it. I think you planned and executed this project very well.
There were some minor changes to the original drafts, but comparing
the feature list from the project proposal (this is only an abstract,
the real list was much longer):
} 1. Line-history (main work :-)
} 2. -M/-C support
} 3. Configurable context
} 4. -C -C support
} 5. Fuzzy matching for -M/-C
} 6. Configurable display (--graph)
} 7. Machine-readable output (--porcelain)
} 8. Support git-log options where possible
with the feature list you posted
Bo Yang wrote:
> And now, we have supports in detail:
> 1. 'git log -L' can trace multiple ranges from multiple files;
> 2. we support the same syntax with 'git blame' '-L' options;
> 3. we integrate the 'git log -L' with '--graph' options with
> parent-rewriting to make the history looks better and clear;
> 4. move/copy detect is in its half way. We get a nearly workable
> version of it, and now it is in a phrase of refactor, so in the scope
> of GSoC, move/copy detect only partly complete.
we see that while there's still some work to be done in the -C -C
area, most of the features are there. The ones that didn't make it
are 5 (fuzzy matching) and to some extent 3 (context control; there is
--full-line-diff). We agreed to drop 7 (--porcelain) in private
conversation when we found out that gitk is already halfway ready to
read --format=full output. Combined-diff style output for merges was
also added to the list sometime in summer, then dropped again because
of time constraints.
Next, thanks also to Jens who co-mentored. Things went very smooth
despite my roughly 4 weeks of absence during the GSoC months thanks to
his efforts.
Finally, I'd like to outline some of my dreams^Wfuture directions for
this feature. Some of them have been promised by Bo privately, but
let's not put any pressure on him now that the project is officially
over.
* Support in gitk to read --format=full output (within some
constraints maybe), thus letting us see the output more
conveniently.
* Support in gitk to parse the -L option and pass it to the right
git-log invocation.
* Combined-diff style output for merges.
* As Junio has suggested in a thread about the option parsing, it
should be possible to extend this to scan history both ways, i.e.,
"I have lines 11-19 in commit abcdef, explain how they came and
where they went".
I think that's all for today, thanks for reading so much text.
Regards
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html