On Thu, May 23, 2013 at 6:47 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>>> If the change in HEAD^ in the above example were to copy the whole A
>>> and C from a different file, then your !found_guilty logic would
>>> kick in and say all lines of A where copied from elsewhere in HEAD^
Felipe Contreras writes:
>> If the change in HEAD^ in the above example were to copy the whole A
>> and C from a different file, then your !found_guilty logic would
>> kick in and say all lines of A where copied from elsewhere in HEAD^,
>> but again we would not learn the same information for C.
On Thu, May 23, 2013 at 5:44 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>>> Then in that "next iteration", we pick blame entry for A and decide
>>> to see if HEAD^, which is the suspect for A, can be exonerated of
>>> blames for _any_ (not just A) blame entry it currently is suspected
Felipe Contreras writes:
>> Then in that "next iteration", we pick blame entry for A and decide
>> to see if HEAD^, which is the suspect for A, can be exonerated of
>> blames for _any_ (not just A) blame entry it currently is suspected
>> for. We call pass_blame() and it will find and process bo
On Thu, May 23, 2013 at 4:52 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>>> Imagine that your scoreboard originally has three blocks of text
>>> (i.e. blame_entry) A, B, and C, and the current suspect for A and C
>>> are the same, while we already know what the final guilty party for
Felipe Contreras writes:
>> Imagine that your scoreboard originally has three blocks of text
>> (i.e. blame_entry) A, B, and C, and the current suspect for A and C
>> are the same, while we already know what the final guilty party for
>> B is (which may be some descendant of the "suspect").
>
> I
On Thu, May 23, 2013 at 11:54 AM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> On Wed, May 22, 2013 at 11:07 PM, Felipe Contreras
>> wrote:
>>> On Wed, May 22, 2013 at 7:08 PM, Junio C Hamano wrote:
Felipe Contreras writes:
>> IIRC, git-gui runs two blames, one without a
Junio C Hamano writes:
> Users of full-output may want to be able to see the same thing.
... but I agree we may be able to cheat if we only want to support
interactive, and we do want to find a way to cheat when we are
running interactive without having to store much more information in
each bla
Felipe Contreras writes:
> On Wed, May 22, 2013 at 10:23 PM, Felipe Contreras
> wrote:
>> This doesn't make any sense:
>
> Ah, never mind, it's COPYING the one being modified, not EXTRACTING.
Yes.
The different levels of -C happens to correspond to the software
engineering practice from best t
Felipe Contreras writes:
> On Wed, May 22, 2013 at 11:07 PM, Felipe Contreras
> wrote:
>> On Wed, May 22, 2013 at 7:08 PM, Junio C Hamano wrote:
>>> Felipe Contreras writes:
>>>
> IIRC, git-gui runs two blames, one without any -C and one with (I do
> not offhand recall how many -C it u
On Wed, May 22, 2013 at 11:07 PM, Felipe Contreras
wrote:
> On Wed, May 22, 2013 at 7:08 PM, Junio C Hamano wrote:
>> Felipe Contreras writes:
>>
IIRC, git-gui runs two blames, one without any -C and one with (I do
not offhand recall how many -C it uses) to show both.
>>>
>>> 'git blam
On Wed, May 22, 2013 at 7:08 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>>> IIRC, git-gui runs two blames, one without any -C and one with (I do
>>> not offhand recall how many -C it uses) to show both.
>>
>> 'git blame' is a very expensive operation, perhaps we should add
>> another
On Wed, May 22, 2013 at 10:23 PM, Felipe Contreras
wrote:
> This doesn't make any sense:
Ah, never mind, it's COPYING the one being modified, not EXTRACTING.
--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.o
This doesn't make any sense:
---
cd /tmp
rm -rf blame
git init blame
cd blame
cp ~/dev/git/COPYING COPYING
git add COPYING
git commit -m initial
sed -ne 120,140p COPYING >EXTRACTING
git add EXTRACTING
git commit -m second
git log --oneline
git blame -C EXTRACTING
echo >>COPYING
git commit --a
Felipe Contreras writes:
>> IIRC, git-gui runs two blames, one without any -C and one with (I do
>> not offhand recall how many -C it uses) to show both.
>
> 'git blame' is a very expensive operation, perhaps we should add
> another option so users don't need to run two blames to find this.
Yes,
On Wed, May 22, 2013 at 6:42 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
The person who moved the code will be on the list regardless,
>>>
>>> That is exactly the point I have been trying to raise. Does the
>>> person appear in the list when you run blame with -CCC? You ask for
>>
Junio C Hamano writes:
>>> The person who moved the code will be on the list regardless,
>>
>> That is exactly the point I have been trying to raise. Does the
>> person appear in the list when you run blame with -CCC? You ask for
>
> s/person/commit/;
>
>> the body of the function, and the -C m
On Wed, May 22, 2013 at 5:53 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> On Wed, May 22, 2013 at 5:38 PM, Junio C Hamano wrote:
>> ...
>>> As I already said in the above, the answer is no, when you are
>>> trying to find who moved the code from the original place.
>>
>> But I'm not
Junio C Hamano writes:
> Felipe Contreras writes:
>
>> On Wed, May 22, 2013 at 5:38 PM, Junio C Hamano wrote:
>> ...
>>> As I already said in the above, the answer is no, when you are
>>> trying to find who moved the code from the original place.
>>
>> But I'm not trying to find who moved the c
Felipe Contreras writes:
> On Wed, May 22, 2013 at 5:38 PM, Junio C Hamano wrote:
> ...
>> As I already said in the above, the answer is no, when you are
>> trying to find who moved the code from the original place.
>
> But I'm not trying to find who moved the code, I'm trying to find
> related
On Wed, May 22, 2013 at 5:38 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>>> Depending on the nature of the change in question, it may match well
>>> or worse to what you are trying to find out. When you are trying to
>>> say "What were you smoking when you implemented this broken log
Felipe Contreras writes:
>> Depending on the nature of the change in question, it may match well
>> or worse to what you are trying to find out. When you are trying to
>> say "What were you smoking when you implemented this broken logic?",
>> using -C may be good, but when your question is "Even
On Wed, May 22, 2013 at 2:23 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> diff --git a/contrib/related/git-related b/contrib/related/git-related
>> new file mode 100755
>> index 000..b96dcdd
>> --- /dev/null
>> +++ b/contrib/related/git-related
>> @@ -0,0 +1,124 @@
>> +#!/usr/bin
Junio C Hamano writes:
> Felipe Contreras writes:
>
>> diff --git a/contrib/related/git-related b/contrib/related/git-related
>> new file mode 100755
>> index 000..b96dcdd
>> --- /dev/null
>> +++ b/contrib/related/git-related
>> @@ -0,0 +1,124 @@
>> +#!/usr/bin/env ruby
>> +
>> +# This scrip
Felipe Contreras writes:
> diff --git a/contrib/related/git-related b/contrib/related/git-related
> new file mode 100755
> index 000..b96dcdd
> --- /dev/null
> +++ b/contrib/related/git-related
> @@ -0,0 +1,124 @@
> +#!/usr/bin/env ruby
> +
> +# This script finds people that might be interest
On Sun, May 19, 2013 at 11:53 AM, Felipe Contreras
wrote:
> This script find people that might be interested in a patch, by going
s/find/finds/
> back through the history for each single hunk modified, and finding
> people that reviewed, acknowledge, signed, or authored the code the
> patch is m
This script find people that might be interested in a patch, by going
back through the history for each single hunk modified, and finding
people that reviewed, acknowledge, signed, or authored the code the
patch is modifying.
It does this by running 'git blame' incrementally on each hunk, and then
27 matches
Mail list logo
