Felipe Contreras felipe.contre...@gmail.com writes:
On Wed, May 22, 2013 at 11:07 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Wed, May 22, 2013 at 7:08 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
IIRC, git-gui runs two
Felipe Contreras felipe.contre...@gmail.com writes:
On Wed, May 22, 2013 at 10:23 PM, Felipe Contreras
felipe.contre...@gmail.com 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
Junio C Hamano gits...@pobox.com 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
On Thu, May 23, 2013 at 11:54 AM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
On Wed, May 22, 2013 at 11:07 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Wed, May 22, 2013 at 7:08 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe
Felipe Contreras felipe.contre...@gmail.com 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
On Thu, May 23, 2013 at 4:52 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com 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
Felipe Contreras felipe.contre...@gmail.com 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
On Thu, May 23, 2013 at 5:44 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com 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
On Thu, May 23, 2013 at 6:47 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com 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
Felipe Contreras felipe.contre...@gmail.com 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
Junio C Hamano gits...@pobox.com writes:
Felipe Contreras felipe.contre...@gmail.com 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 @@
On Wed, May 22, 2013 at 2:23 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com 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
@@
Felipe Contreras felipe.contre...@gmail.com 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
On Wed, May 22, 2013 at 5:38 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com 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
Felipe Contreras felipe.contre...@gmail.com writes:
On Wed, May 22, 2013 at 5:38 PM, Junio C Hamano gits...@pobox.com 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
Junio C Hamano gits...@pobox.com writes:
Felipe Contreras felipe.contre...@gmail.com writes:
On Wed, May 22, 2013 at 5:38 PM, Junio C Hamano gits...@pobox.com 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.
On Wed, May 22, 2013 at 5:53 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
On Wed, May 22, 2013 at 5:38 PM, Junio C Hamano gits...@pobox.com wrote:
...
As I already said in the above, the answer is no, when you are
trying to find who moved
Junio C Hamano gits...@pobox.com 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
Felipe Contreras felipe.contre...@gmail.com 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
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
On Wed, May 22, 2013 at 10:23 PM, Felipe Contreras
felipe.contre...@gmail.com 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
On Wed, May 22, 2013 at 7:08 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com 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,
On Wed, May 22, 2013 at 11:07 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Wed, May 22, 2013 at 7:08 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
IIRC, git-gui runs two blames, one without any -C and one with (I do
not offhand
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
24 matches
Mail list logo
