* [PATCH] repo-config: give value_ a sane default so regexec won't segfault
From: Jonas Fonseca @ 2006-03-06 5:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
repo-config.c | 5 ++++-
t/t1300-repo-config.sh | 8 ++++++++
2 files changed, 12 insertions(+), 1 deletions(-)
7fcdb6b9c8c75a0c84076b4a0ebc46b4c7383906
diff --git a/repo-config.c b/repo-config.c
index 9cf6519..c5ebb76 100644
--- a/repo-config.c
+++ b/repo-config.c
@@ -14,6 +14,9 @@ static enum { T_RAW, T_INT, T_BOOL } typ
static int show_config(const char* key_, const char* value_)
{
+ if (value_ == NULL)
+ value_ = "";
+
if (!strcmp(key_, key) &&
(regexp == NULL ||
(do_not_match ^
@@ -35,7 +38,7 @@ static int show_config(const char* key_,
sprintf(value, "%s", git_config_bool(key_, value_)
? "true" : "false");
} else {
- value = strdup(value_ ? value_ : "");
+ value = strdup(value_);
}
seen++;
}
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index 207dd3d..ab4dd5c 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -247,5 +247,13 @@ EOF
test_expect_success 'hierarchical section value' 'cmp .git/config expect'
+cat > .git/config << EOF
+[novalue]
+ variable
+EOF
+
+test_expect_success 'get variable with no value' \
+ 'git-repo-config --get novalue.variable ^$'
+
test_done
--
1.2.4.g9201
--
Jonas Fonseca
^ permalink raw reply related
* [PATCH] Add git-annotate(1) and git-blame(1)
From: Jonas Fonseca @ 2006-03-06 5:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
Documentation/git-annotate.txt | 44 ++++++++++++++++++++++++++++++++++++++++
Documentation/git-blame.txt | 31 ++++++++++++++++++++++++++++
2 files changed, 75 insertions(+), 0 deletions(-)
create mode 100644 Documentation/git-annotate.txt
create mode 100644 Documentation/git-blame.txt
c280414507b072689afd3061a2d43527ebab292e
diff --git a/Documentation/git-annotate.txt b/Documentation/git-annotate.txt
new file mode 100644
index 0000000..1cfc3e3
--- /dev/null
+++ b/Documentation/git-annotate.txt
@@ -0,0 +1,44 @@
+git-annotate(1)
+===============
+
+NAME
+----
+git-annotate - annotate file lines with commit info
+
+SYNOPSIS
+--------
+git-annotate [options] file [revision]
+
+DESCRIPTION
+-----------
+Annotates each line in the given file with information from the commit
+which introduced the line. Optionally annotate from a given revision.
+
+OPTIONS
+-------
+-l, --long::
+ Show long rev (Defaults off).
+
+-t, --time::
+ Show raw timestamp (Defaults off).
+
+-r, --rename::
+ Follow renames (Defaults on).
+
+-S, --rev-file <revs-file>::
+ Use revs from revs-file instead of calling git-rev-list.
+
+-h, --help::
+ Show help message.
+
+SEE ALSO
+--------
+gitlink:git-blame[1]
+
+AUTHOR
+------
+Written by Ryan Anderson <ryan@michonline.com>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
diff --git a/Documentation/git-blame.txt b/Documentation/git-blame.txt
new file mode 100644
index 0000000..bdf28d9
--- /dev/null
+++ b/Documentation/git-blame.txt
@@ -0,0 +1,31 @@
+git-blame(1)
+============
+
+NAME
+----
+git-blame - blame file lines on commits
+
+SYNOPSIS
+--------
+git-blame revision file
+
+DESCRIPTION
+-----------
+Annotates each line in the given file with information from the commit
+which introduced the line. Start annotation from the given revision.
+
+OPTIONS
+-------
+No options.
+
+SEE ALSO
+--------
+gitlink:git-annotate[1]
+
+AUTHOR
+------
+Written by Fredrik Kuivinen <freku045@student.liu.se>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
--
1.2.4.g9201
--
Jonas Fonseca
^ permalink raw reply related
* Re: [PATCH] annotate: Support annotation of files on other revisions.
From: A Large Angry SCM @ 2006-03-06 5:31 UTC (permalink / raw)
To: Ryan Anderson; +Cc: Martin Langhoff, Fredrik Kuivinen, git, junkio
In-Reply-To: <20060306024353.GA23001@mythryan2.michonline.com>
Ryan Anderson wrote:
...
>
> For annotate, the syntax I was using was:
> git annotate Makefile headname
>
> I'm not married to it, so please, send a patch to change it if you want
> (Please fix up the test case I'm sending in this patch, as well.)
>
Wouldn't
git annotate <headname> <filename(s?)>
be more consistent with other git commands?
^ permalink raw reply
* Re: [PATCH] Add git-annotate(1) and git-blame(1)
From: Junio C Hamano @ 2006-03-06 5:35 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <20060306052444.GC6487@diku.dk>
Jonas Fonseca <fonseca@diku.dk> writes:
> Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
Wonderful, but I was hoping the "deathmatch" would leave only
one that needs to be documented and we could wait documenting
until then ;-).
^ permalink raw reply
* Re: [PATCH] annotate: Support annotation of files on other revisions.
From: Ryan Anderson @ 2006-03-06 5:40 UTC (permalink / raw)
To: gitzilla; +Cc: Martin Langhoff, Fredrik Kuivinen, git, junkio
In-Reply-To: <440BC92E.4060306@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 640 bytes --]
A Large Angry SCM wrote:
> Ryan Anderson wrote:
> ...
>
>>
>> For annotate, the syntax I was using was:
>> git annotate Makefile headname
>>
>> I'm not married to it, so please, send a patch to change it if you want
>> (Please fix up the test case I'm sending in this patch, as well.)
>>
>
> Wouldn't
> git annotate <headname> <filename(s?)>
> be more consistent with other git commands?
>
Yes, but <headname> (really, a commitish) needs to be optional.
I should probably switch to:
git annotate [-c|--commit <committish>] <filename>
but that's partly why I'm asking for feedback.
--
Ryan Anderson
sometimes Pug Majere
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]
^ permalink raw reply
* Re: [PATCH] annotate: Support annotation of files on other revisions.
From: Shawn Pearce @ 2006-03-06 5:50 UTC (permalink / raw)
To: Ryan Anderson; +Cc: gitzilla, Martin Langhoff, Fredrik Kuivinen, git, junkio
In-Reply-To: <440BCB67.4070406@michonline.com>
Ryan Anderson <ryan@michonline.com> wrote:
> A Large Angry SCM wrote:
>
> > Ryan Anderson wrote:
> > ...
> >
> >>
> >> For annotate, the syntax I was using was:
> >> git annotate Makefile headname
> >>
> >> I'm not married to it, so please, send a patch to change it if you want
> >> (Please fix up the test case I'm sending in this patch, as well.)
> >>
> >
> > Wouldn't
> > git annotate <headname> <filename(s?)>
> > be more consistent with other git commands?
> >
> Yes, but <headname> (really, a commitish) needs to be optional.
>
> I should probably switch to:
> git annotate [-c|--commit <committish>] <filename>
> but that's partly why I'm asking for feedback.
Yes but doesn't git-diff accept:
git-diff Makefile
git-diff HEAD Makefile
? (Which is rather ugly as what if you have a tracked file actually
called HEAD and you want the first form when the commit-ish is
omitted.) So accepting an optional commit-ish before the filename
would be in line with what git-diff accepts today.
But maybe breaking convention from git-diff now is a good thing,
with a future change to cleanup git-diff.
--
Shawn.
^ permalink raw reply
* [PATCH] annotate/blame tests updates.
From: Junio C Hamano @ 2006-03-06 6:12 UTC (permalink / raw)
To: Ryan Anderson; +Cc: Fredrik Kuivinen, git, junkio
In-Reply-To: <440BA4DA.9060101@michonline.com>
Ryan Anderson <ryan@michonline.com> writes:
>>+test_expect_success \
>>+ 'check all lines blamed on A' \
>>+ '[ $(git annotate file | awk "{print \$3}" | grep -c "A") == 2 ]'
>>
>>
> This should be $PROG as well, I suspect.
True. Also I am suspecting this awk being a but unsafe. The
default author is "A U Thor <author@example.com>", and without
FS specified awk would split at whitespaces.
I haven't pushed out the test-case sharing by Fredrik yet, but I
have already taken it. This patch is on top of it.
-- >8 --
This rewrites the result check code a bit. The earlier one
using awk was splitting columns at any whitespace, which
confused lines attributed incorrectly to the merge made by the
default author "A U Thor <author@example.com>" with lines
attributed to author "A".
The latest test by Ryan to add the "starting from older commit"
test is also included, with another older commit test.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
t/annotate-tests.sh | 81 ++++++++++++++++++++++++++++-----------------------
1 files changed, 44 insertions(+), 37 deletions(-)
92a903acfd0904e6dd6d18112428429938783d19
diff --git a/t/annotate-tests.sh b/t/annotate-tests.sh
index 54a4dfb..d25a7a1 100644
--- a/t/annotate-tests.sh
+++ b/t/annotate-tests.sh
@@ -1,6 +1,37 @@
# This file isn't used as a test script directly, instead it is
# sourced from t8001-annotate.sh and t8001-blame.sh.
+check_count () {
+ head=
+ case "$1" in -h) head="$2"; shift; shift ;; esac
+ $PROG file $head | perl -e '
+ my %expect = (@ARGV);
+ my %count = ();
+ while (<STDIN>) {
+ if (/^[0-9a-f]+\t\(([^\t]+)\t/) {
+ my $author = $1;
+ for ($author) { s/^\s*//; s/\s*$//; }
+ if (exists $expect{$author}) {
+ $count{$author}++;
+ }
+ }
+ }
+ my $bad = 0;
+ while (my ($author, $count) = each %count) {
+ my $ok;
+ if ($expect{$author} != $count) {
+ $bad = 1;
+ $ok = "bad";
+ }
+ else {
+ $ok = "good";
+ }
+ print STDERR "Author $author (expected $expect{$author}, attributed $count) $ok\n";
+ }
+ exit($bad);
+ ' "$@"
+}
+
test_expect_success \
'prepare reference tree' \
'echo "1A quick brown fox jumps over the" >file &&
@@ -10,7 +41,7 @@ test_expect_success \
test_expect_success \
'check all lines blamed on A' \
- '[ $(git annotate file | awk "{print \$3}" | grep -c "A") == 2 ]'
+ 'check_count A 2'
test_expect_success \
'Setup new lines blamed on B' \
@@ -19,12 +50,8 @@ test_expect_success \
GIT_AUTHOR_NAME="B" git commit -a -m "Second."'
test_expect_success \
- 'Two lines blamed on A' \
- '[ $($PROG file | awk "{print \$3}" | grep -c "A") == 2 ]'
-
-test_expect_success \
- 'Two lines blamed on B' \
- '[ $($PROG file | awk "{print \$3}" | grep -c "B") == 2 ]'
+ 'Two lines blamed on A, two on B' \
+ 'check_count A 2 B 2'
test_expect_success \
'merge-setup part 1' \
@@ -34,16 +61,8 @@ test_expect_success \
GIT_AUTHOR_NAME="B1" git commit -a -m "Branch1-1"'
test_expect_success \
- 'Two lines blamed on A' \
- '[ $($PROG file | awk "{print \$3}" | grep -c "^A$") == 2 ]'
-
-test_expect_success \
- 'Two lines blamed on B' \
- '[ $($PROG file | awk "{print \$3}" | grep -c "^B$") == 2 ]'
-
-test_expect_success \
- 'Two lines blamed on B1' \
- '[ $($PROG file | awk "{print \$3}" | grep -c "^B1$") == 2 ]'
+ 'Two lines blamed on A, two on B, two on B1' \
+ 'check_count A 2 B 2 B1 2'
test_expect_success \
'merge-setup part 2' \
@@ -53,34 +72,22 @@ test_expect_success \
GIT_AUTHOR_NAME="B2" git commit -a -m "Branch2-1"'
test_expect_success \
- 'Two lines blamed on A' \
- '[ $($PROG file | awk "{print \$3}" | grep -c "^A$") == 2 ]'
-
-test_expect_success \
- 'One line blamed on B' \
- '[ $($PROG file | awk "{print \$3}" | grep -c "^B$") == 1 ]'
-
-test_expect_success \
- 'One line blamed on B2' \
- '[ $($PROG file | awk "{print \$3}" | grep -c "^B2$") == 1 ]'
-
+ 'Two lines blamed on A, one on B, one on B2' \
+ 'check_count A 2 B 1 B2 1'
test_expect_success \
'merge-setup part 3' \
'git pull . branch1'
test_expect_success \
- 'Two lines blamed on A' \
- '[ $($PROG file | awk "{print \$3}" | grep -c "^A$") == 2 ]'
+ 'Two lines blamed on A, one on B, two on B1, one on B2' \
+ 'check_count A 2 B 1 B1 2 B2 1'
test_expect_success \
- 'One line blamed on B' \
- '[ $($PROG file | awk "{print \$3}" | grep -c "^B$") == 1 ]'
+ 'Annotating an old revision works' \
+ 'check_count -h master A 2 B 2'
test_expect_success \
- 'Two lines blamed on B1' \
- '[ $($PROG file | awk "{print \$3}" | grep -c "^B1$") == 2 ]'
+ 'Annotating an old revision works' \
+ 'check_count -h master^ A 2'
-test_expect_success \
- 'One line blamed on B2' \
- '[ $($PROG file | awk "{print \$3}" | grep -c "^B2$") == 1 ]'
--
1.2.4.g4668
^ permalink raw reply related
* Re: [PATCH] annotate: Support annotation of files on other revisions.
From: Junio C Hamano @ 2006-03-06 6:16 UTC (permalink / raw)
To: git
In-Reply-To: <20060306055036.GB26820@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> git-diff Makefile
> git-diff HEAD Makefile
>
> ? (Which is rather ugly as what if you have a tracked file actually
> called HEAD and you want the first form when the commit-ish is
> omitted.) So accepting an optional commit-ish before the filename
> would be in line with what git-diff accepts today.
The use of "start of filelist" marker "--" is optional when
unambiguous, and that is why "git-diff Makefile" works. To view
the change you still haven't update-index'ed to the path called
"HEAD", you would naturally say "git-diff -- HEAD"
^ permalink raw reply
* Re: [PATCH] annotate: Support annotation of files on other revisions.
From: A Large Angry SCM @ 2006-03-06 6:21 UTC (permalink / raw)
To: Shawn Pearce
Cc: Ryan Anderson, Martin Langhoff, Fredrik Kuivinen, git, junkio
In-Reply-To: <20060306055036.GB26820@spearce.org>
Shawn Pearce wrote:
> Ryan Anderson <ryan@michonline.com> wrote:
>>A Large Angry SCM wrote:
>>
>>>Ryan Anderson wrote:
>>>...
>>>
>>>>For annotate, the syntax I was using was:
>>>> git annotate Makefile headname
>>>>
>>>>I'm not married to it, so please, send a patch to change it if you want
>>>>(Please fix up the test case I'm sending in this patch, as well.)
>>>>
>>>Wouldn't
>>> git annotate <headname> <filename(s?)>
>>>be more consistent with other git commands?
>>>
>>Yes, but <headname> (really, a commitish) needs to be optional.
>>
>>I should probably switch to:
>> git annotate [-c|--commit <committish>] <filename>
>>but that's partly why I'm asking for feedback.
That works.
Or maybe:
git-annotate [<committish> --] <filename(s?)>
or:
git-annotate [<committish>] -- <filename(s?)>
>
> Yes but doesn't git-diff accept:
>
> git-diff Makefile
> git-diff HEAD Makefile
>
> ? (Which is rather ugly as what if you have a tracked file actually
> called HEAD and you want the first form when the commit-ish is
> omitted.) So accepting an optional commit-ish before the filename
> would be in line with what git-diff accepts today.
>
> But maybe breaking convention from git-diff now is a good thing,
> with a future change to cleanup git-diff.
>
Looking at the documentation, it looks like all of the commands that
take paths do so as the last arguments. With any commit/tree arguments
being, either, required or flagged.
Is there any reason that git-{annotate,blame} can't take more than one
filename, ever?
^ permalink raw reply
* Re: [PATCH] annotate: Support annotation of files on other revisions.
From: Junio C Hamano @ 2006-03-06 6:28 UTC (permalink / raw)
To: gitzilla; +Cc: git
In-Reply-To: <440BD4F4.3060906@gmail.com>
> Is there any reason that git-{annotate,blame} can't take more than one
> filename, ever?
I do not see it would be much useful -- the output does not
have a sign to show file boundary.
^ permalink raw reply
* Re: [PATCH] Add git-annotate(1) and git-blame(1)
From: Ryan Anderson @ 2006-03-06 6:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonas Fonseca, git
In-Reply-To: <7v3bhwcezy.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 514 bytes --]
Junio C Hamano wrote:
>Jonas Fonseca <fonseca@diku.dk> writes:
>
>
>
>>Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
>>
>>
>
>Wonderful, but I was hoping the "deathmatch" would leave only
>one that needs to be documented and we could wait documenting
>until then ;-).
>
>
heh. If I'm not mistaken, blame is still lacking rename following (at
least, in master), and annotate is still misrepresenting things on
merges, so we've got a bit of a ways to go still.
--
Ryan Anderson
sometimes Pug Majere
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]
^ permalink raw reply
* Re: [PATCH] annotate: Support annotation of files on other revisions.
From: Shawn Pearce @ 2006-03-06 6:32 UTC (permalink / raw)
To: git
In-Reply-To: <7vpsl0ayij.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
> > git-diff Makefile
> > git-diff HEAD Makefile
> >
> > ? (Which is rather ugly as what if you have a tracked file actually
> > called HEAD and you want the first form when the commit-ish is
> > omitted.) So accepting an optional commit-ish before the filename
> > would be in line with what git-diff accepts today.
>
> The use of "start of filelist" marker "--" is optional when
> unambiguous, and that is why "git-diff Makefile" works. To view
> the change you still haven't update-index'ed to the path called
> "HEAD", you would naturally say "git-diff -- HEAD"
Naturally. :-)
After getting along fine with `git-diff foo` for months I would
natually not be surprised when `git-diff foo` didn't work because
I performed a `git-checkout -b foo pu` one day.
--
Shawn.
^ permalink raw reply
* Re: Looking for SCM that lets me publish part of a repository
From: Alan Chandler @ 2006-03-06 6:54 UTC (permalink / raw)
To: git
In-Reply-To: <1141608679.16980.12.camel@mattlaptop>
On Monday 06 March 2006 01:31, Matt McCutchen wrote:
> Dear GIT people,
>
> For the last week or so, I have been looking for a SCM system to hold
> many of my projects, some of which are available to the public and
> others of which are not. It would be nice if I could use a single large
> private repository on my computer with each project in a separate
> folder.
Not sure why you would want to do this against having lots of smaller
repositories - (I have lots of small repositories - its mostly java, and my
shared library files have their own repository which is automatically
exported to where my projects can access it when I commit to it via a post
commit hook - you can see the public version of them on my web site) but ...
Create each project on a separate branch of the common repository and ensure
only the files you want in each project remains on each branch (and any
shared files can exist in all branches).
In your "remotes" files you list the branches that you want to push to your
public repository.
--
Alan Chandler
http://www.chandlerfamily.org.uk
Open Source. It's the difference between trust and antitrust.
^ permalink raw reply
* What's in git.git
From: Junio C Hamano @ 2006-03-06 7:13 UTC (permalink / raw)
To: git
The "deathmatch" between Ryan's annotate and Fredrik's blame is
officially on. Currently the last test in all three branches
fail. Please do not get alarmed.
I'd like asciidoc tweaks in "next" by Francis Daly tested by
people who have access to different vintages of docbook-xsl by
trying to build manpages. Look for displayed examples, such as
the one in git-branch documentation. I've tried it with v1.68
and getting far better results than before, and Francis says
v1.69 works fine with or without the change. IOW this is a
workaround for a problem in v1.68.
I've been tweaking on-and-off the similarity estimator in the
"next" branch. It has become independent from the xdelta code
used for pack generation. It may detect more renames that it
missed before, and it may miss some other renames and copies.
In general, it seems that the algorithm tends to detect slightly
more breaks than before. I'd appreciate feedback from people
interested in this area.
Another thing I have started in "pu" branch is to stop placing
an object we decided to delta that is already max-depth deep
back in the delta-base window, because such a thing only wastes
the delta base slot. The changed pack-objects does pick up more
delta, but the resulting pack seems bigger and I am puzzled why.
This may suggest that our criteria to delta should be tightened
a bit (the value of max_size in try_delta should be decreased).
We are better off storing a plain deflated representation instad
of generating a bad, bigger delta. Insights?
-- -- --
* The 'master' branch has these since the last announcement.
- Documentation fixes (Dmitry V. Levin, Mark Wooding, Martin
Langhoff, Jeff Muizelaar)
git/Documentation: fix SYNOPSIS style bugs
Documentation/Makefile: Some `git-*.txt' files aren't manpages.
cvsserver: updated documentation
cosmetics: change from 'See-Also' to 'See Also'
documentation: add 'see also' sections to git-rm and git-add
- The deathmatch between annotate/blame (Ryan Anderson, Fredrik
Kuivinen, me cheerleading)
annotate: Support annotation of files on other revisions.
git-blame: Make the output human readable
git-blame: Use the same tests for git-blame as for git-annotate
blame: avoid -lm by not using log().
blame and annotate: show localtime with timezone.
blame: avoid "diff -u0".
annotate/blame tests updates.
annotate-blame test: don't "source", but say "."
annotate-blame test: add evil merge.
- Tweak rev-list (Linus Torvalds)
get_revision(): do not dig deeper when we know we are at the end.
- Fix git-commit --amend (me)
git-commit --amend: allow empty commit.
- Misc fixes and cleanups (Mark Wooding and me)
gitignore: Ignore some more boring things.
contrib/emacs/Makefile: Provide tool for byte-compiling files.
Const tightening.
* The 'next' branch, in addition, has these.
- Fix manpage formatting (Francis Daly)
Tweak asciidoc output to work with broken docbook-xsl
- Tweak break/rename/copy similarity estimator tweaks (me)
diffcore-rename: similarity estimator fix.
count-delta: no need for this anymore.
diffcore-break: similarity estimator fix.
diffcore-delta: make change counter to byte oriented again.
- Help pack generation tweaks (me)
verify-pack -v: show delta-chain histogram.
- checkout-index --temp (Shawn Pearce)
Add --temp and --stage=all options to checkout-index.
* The 'pu' branch, in addition, has these.
- WIP: pack generation tweak (me)
[WIP] do not waste delta window with objects with already at max-depth.
^ permalink raw reply
* Re: [PATCH] annotate: Support annotation of files on other revisions.
From: Fredrik Kuivinen @ 2006-03-06 7:49 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Ryan Anderson, Fredrik Kuivinen, git, junkio
In-Reply-To: <46a038f90603052018n76d316eclf84b6921c9595f16@mail.gmail.com>
On Mon, Mar 06, 2006 at 05:18:35PM +1300, Martin Langhoff wrote:
> On 3/6/06, Ryan Anderson <ryan@michonline.com> wrote:
> > annotate was *trying* to handle that cleanly, but failed due to a silly
>
> Great stuff, thanks! I'll let it hit master and then I'll drop the
> messy part of req_annotate() in cvsserver.
>
> > For annotate, the syntax I was using was:
> > git annotate Makefile headname
> >
> > I'm not married to it, so please, send a patch to change it if you want
> > (Please fix up the test case I'm sending in this patch, as well.)
>
> That's _perfect_. I was just making the syntax up.
>
That syntax should work with git-blame too. If it doesn't, it's a bug.
- Fredrik
^ permalink raw reply
* [PATCH] blame: unbreak "diff -U 0".
From: Junio C Hamano @ 2006-03-06 8:45 UTC (permalink / raw)
To: git; +Cc: Fredrik Kuivinen
In-Reply-To: <7v1wxg82r3.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> The "deathmatch" between Ryan's annotate and Fredrik's blame is
> officially on. Currently the last test in all three branches
> fail. Please do not get alarmed.
It turns out the breakage was caused after merging Fredrik's
improvements. I'm double-checking the fix and will be pushing
out corrected "master", "next" and "pu" shortly.
Sorry, Fredrik.
-- >8 --
Subject: [PATCH] blame: unbreak "diff -U 0".
The commit 604c86d15bb319a1e93ba218fca48ce1c500ae52 changed the
original "diff -u0" to "diff -u -U 0" for portability.
A big mistake without proper testing.
The form "diff -u -U 0" shows the default 3-line contexts,
because -u and -U 0 contradicts with each other; "diff -U 0" (or
its longhand "diff --unified=0") is what we meant.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
blame.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
690e307f54b4aa84349b89e8552b25e7495f1cd6
diff --git a/blame.c b/blame.c
index fca22f9..90338af 100644
--- a/blame.c
+++ b/blame.c
@@ -92,7 +92,7 @@ static struct patch *get_patch(struct co
die("write failed: %s", strerror(errno));
close(fd);
- sprintf(diff_cmd, "diff -u -U 0 %s %s", tmp_path1, tmp_path2);
+ sprintf(diff_cmd, "diff -U 0 %s %s", tmp_path1, tmp_path2);
fin = popen(diff_cmd, "r");
if (!fin)
die("popen failed: %s", strerror(errno));
@@ -234,7 +234,7 @@ static void print_patch(struct patch *p)
}
}
-#if 0
+#if DEBUG
/* For debugging only */
static void print_map(struct commit *cmit, struct commit *other)
{
--
1.2.4.g3bcd
^ permalink raw reply related
* Re: What's in git.git
From: Martin Langhoff @ 2006-03-06 9:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wxg82r3.fsf@assigned-by-dhcp.cox.net>
On 3/6/06, Junio C Hamano <junkio@cox.net> wrote:
> - The deathmatch between annotate/blame (Ryan Anderson, Fredrik
> Kuivinen, me cheerleading)
Add fuel to the fire ;-) Can git-blame take cached git-rev-list
output like annotate does with -S?
m
^ permalink raw reply
* Re: What's in git.git
From: Johannes Schindelin @ 2006-03-06 9:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wxg82r3.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sun, 5 Mar 2006, Junio C Hamano wrote:
> Another thing I have started in "pu" branch is to stop placing
> an object we decided to delta that is already max-depth deep
> back in the delta-base window, because such a thing only wastes
> the delta base slot. The changed pack-objects does pick up more
> delta, but the resulting pack seems bigger and I am puzzled why.
Not that I know much about the pack format, but is it possible that the
deltas are deflated? In that case, a possible explanation is that a better
delta is less compressible (and taken together, this could amount to more
bytes).
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] annotate: Support annotation of files on other revisions.
From: Johannes Schindelin @ 2006-03-06 9:18 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git
In-Reply-To: <20060306024353.GA23001@mythryan2.michonline.com>
Hi,
On Sun, 5 Mar 2006, Ryan Anderson wrote:
> +use Data::Dumper;
You really need this?
Ciao,
Dscho
P.S.: Not to be left behind, I also weigh in into the other discussion:
I'd like "git-{annotate,blame} [HEAD [--]] [filenames...]".
^ permalink raw reply
* Re: git clone downloads objects that are in GIT_OBJECT_DIRECTORY
From: Johannes Schindelin @ 2006-03-06 9:20 UTC (permalink / raw)
To: sean; +Cc: Shawn Pearce, junkio, git
In-Reply-To: <BAYC1-PASMTP05F90E7F1807F05A274507AEE90@CEZ.ICE>
Hi,
On Sun, 5 Mar 2006, sean wrote:
> However, it might be nice to have a command that allows you to
> change origin information for a repo without needing to know git
> internals; maybe something like:
>
> $ git set-origin <URL>
>
> Or maybe better:
>
> $ git set-remote --pull master:origin origin <URL>
FWIW, I once sent patches to make this easier by placing this information
into the config file, but for reasons I did not understand, they were
rejected. Sigh!
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] annotate: Support annotation of files on other revisions.
From: Johannes Schindelin @ 2006-03-06 9:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: gitzilla, git
In-Reply-To: <7vk6b8axz4.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sun, 5 Mar 2006, Junio C Hamano wrote:
> > Is there any reason that git-{annotate,blame} can't take more than one
> > filename, ever?
>
> I do not see it would be much useful -- the output does not
> have a sign to show file boundary.
CVS does it. Why shouldn't git, too?
Ciao,
Dscho
P.S.: The output for more than one file is separated by something like
Annotations for <filename.txt>
***************
^ permalink raw reply
* Re: cvsimport woes
From: Martin Langhoff @ 2006-03-06 9:24 UTC (permalink / raw)
To: Rajkumar S; +Cc: git
In-Reply-To: <44094618.6070404@asianetindia.com>
Hi Raj,
you don't seem to be making any silly mistake. Make sure you are using
a recent git, and a recent cvsps. Actually you want the _latest_ cvsps
(2.1 I think).
A good thing to check is what cvsps is telling cvsimport.
Now, here you are not showing us your cvsimport commandline:
> cvs_direct initialized to CVSROOT /home/raj/cvsroot
> cvs rlog: Logging src
> skip patchset 1: 1141457879 before 1141457879
> skip patchset 2: 1141457879 before 1141457879
Ahhh... ok, you are doing it all very fast. Is this a script you are
running? add sleep 1 before you call cvsimport.
cheers,
martin
^ permalink raw reply
* Re: cvsimport woes
From: Martin Langhoff @ 2006-03-06 9:37 UTC (permalink / raw)
To: Rajkumar S; +Cc: git
In-Reply-To: <46a038f90603060124h4ea1c3c6gaa5d8b52ed311230@mail.gmail.com>
On 3/6/06, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> you don't seem to be making any silly mistake. Make sure you are using
> a recent git, and a recent cvsps. Actually you want the _latest_ cvsps
> (2.1 I think).
Scratch this bit, naturally. I wasn't 100% paying attention. Still,
the rest of the answer should kinda/sorta make sense.
sorry!
martin
^ permalink raw reply
* Re: What's in git.git
From: Lukas Sandström @ 2006-03-06 10:29 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
In-Reply-To: <7v1wxg82r3.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> I'd like asciidoc tweaks in "next" by Francis Daly tested by
> people who have access to different vintages of docbook-xsl by
> trying to build manpages. Look for displayed examples, such as
> the one in git-branch documentation. I've tried it with v1.68
> and getting far better results than before, and Francis says
> v1.69 works fine with or without the change. IOW this is a
> workaround for a problem in v1.68.
>
I tested it with asciidoc 7.0.1 and the examples in the git-branch
man page look better with the fix.
/Lukas
Before:
Examples
Start development off of a know tag
$ git clone git://git.kernel.org/pub/scm/.../linux-2.6 my2.6 $
cd my2.6 $ git branch my2.6.14 v2.6.14 $ git checkout my2.6.14
These two steps are the same as "checkout -b my2.6.14 v2.6.14".
Delete unneeded branch
$ git clone git://git.kernel.org/.../git.git my.git $ cd my.git
$ git branch -D todo
delete todo branch even if the "master" branch does not have
all commits from todo branch.
After:
Examples
Start development off of a know tag
$ git clone git://git.kernel.org/pub/scm/.../linux-2.6 my2.6
$ cd my2.6
$ git branch my2.6.14 v2.6.14
$ git checkout my2.6.14
These two steps are the same as "checkout -b my2.6.14 v2.6.14".
Delete unneeded branch
$ git clone git://git.kernel.org/.../git.git my.git
$ cd my.git
$ git branch -D todo
delete todo branch even if the "master" branch does not have all
commits from todo branch.
^ permalink raw reply
* Re: [PATCH] Add git-annotate(1) and git-blame(1)
From: Jonas Fonseca @ 2006-03-06 11:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3bhwcezy.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote Sun, Mar 05, 2006:
> Jonas Fonseca <fonseca@diku.dk> writes:
>
> > Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
>
> Wonderful, but I was hoping the "deathmatch" would leave only
> one that needs to be documented and we could wait documenting
> until then ;-).
Why not let them compete on providing the best documentation as well? ;)
But ok, I can understand your point.
--
Jonas Fonseca
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox