* [PATCH] gitweb: Fix git_blame
From: Aneesh Kumar K.V @ 2006-09-01 3:43 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #2: 0001-gitweb-Fix-git_blame.txt --]
[-- Type: text/plain, Size: 1806 bytes --]
Converting the default values to array broke the git blame enable
disable support. Fix the same.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
---
gitweb/gitweb.perl | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 0984e85..57ffa25 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2251,7 +2251,8 @@ sub git_blame2 {
my $fd;
my $ftype;
- if (!gitweb_check_feature('blame')) {
+ my ($have_blame) = gitweb_check_feature('blame');
+ if (!$have_blame) {
die_error('403 Permission denied', "Permission denied");
}
die_error('404 Not Found', "File name not defined") if (!$file_name);
@@ -2320,7 +2321,8 @@ HTML
sub git_blame {
my $fd;
- if (!gitweb_check_feature('blame')) {
+ my ($have_blame) = gitweb_check_feature('blame');
+ if (!$have_blame) {
die_error('403 Permission denied', "Permission denied");
}
die_error('404 Not Found', "File name not defined") if (!$file_name);
@@ -2494,7 +2496,7 @@ sub git_blob {
die_error(undef, "No file name defined");
}
}
- my $have_blame = gitweb_check_feature('blame');
+ my ($have_blame) = gitweb_check_feature('blame');
open my $fd, "-|", git_cmd(), "cat-file", "blob", $hash
or die_error(undef, "Couldn't cat $file_name, $hash");
my $mimetype = blob_mimetype($fd, $file_name);
@@ -2570,7 +2572,7 @@ sub git_tree {
my $ref = format_ref_marker($refs, $hash_base);
git_header_html();
my $base = "";
- my $have_blame = gitweb_check_feature('blame');
+ my ($have_blame) = gitweb_check_feature('blame');
if (defined $hash_base && (my %co = parse_commit($hash_base))) {
git_print_page_nav('tree','', $hash_base);
git_print_header_div('commit', esc_html($co{'title'}) . $ref, $hash_base);
--
1.4.2.rc1.g83e1-dirty
^ permalink raw reply related
* Re: problem with git-cvsserver
From: Martin Langhoff @ 2006-09-01 0:07 UTC (permalink / raw)
To: Marco Roeland; +Cc: Junio C Hamano, aonghus, git, Johannes Schindelin
In-Reply-To: <46a038f90608311600p747c8a3anbe90dbac928e9923@mail.gmail.com>
On 9/1/06, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> I have to say though: Ouch. Do you know if there's an upgrade path for
> apps? Does v3 detect you've got a v2 file and do something smart
> (upgrade in place / spit out a readable error)?
Oh, grumble. See the comment at the bottom of
http://www.sqlite.org/formatchng.html
We may need to add something in the doco pointing to this "technique",
and perhaps the URL as later versions may do something different.
I do wonder what the debian packaging does, perhaps the v3 package
forces an upgrade to the v2 package that renames the cli binary? I
guess the drawback of having the DBs anywhere in the FS is that the
packaging can't upgrade them for you as it does with Pg for instance
:(
m
^ permalink raw reply
* [PATCH] t5710: fix two thinkos.
From: Junio C Hamano @ 2006-09-01 0:07 UTC (permalink / raw)
To: git; +Cc: Martin Waitz
The intention of the test seems to be to build a long chain of
clones that locally borrow objects from their parents and see the
system give up dereferencing long chains. There were two problems:
(1) it did not test the right repository;
(2) it did not build a chain long enough to trigger the limitation.
I do not think it is a good test to make sure the limitation the
current implementation happens to have still exists, but that is
a topic at a totally different level.
At least this fixes the broken test.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* Spotted this after the fix to git-fsck-objects by Linus not
to require a valid HEAD.
t/t5710-info-alternate.sh | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/t/t5710-info-alternate.sh b/t/t5710-info-alternate.sh
index 2e1b48a..b9f6d96 100755
--- a/t/t5710-info-alternate.sh
+++ b/t/t5710-info-alternate.sh
@@ -58,6 +58,8 @@ test_expect_failure 'creating too deep n
git clone -l -s D E &&
git clone -l -s E F &&
git clone -l -s F G &&
+git clone -l -s G H &&
+cd H &&
test_valid_repo'
cd "$base_dir"
--
1.4.2.g2782
^ permalink raw reply related
* Re: [PATCH] Support author and commiter based revision list limiting
From: Junio C Hamano @ 2006-09-01 0:07 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <20060831225714.GD482@diku.dk>
Jonas Fonseca <fonseca@diku.dk> writes:
> Adds the two options: --author=string and --committer=string, which can
> be used to limit the set of interesting commits to the ones matching the
> given idents.
>
> diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt
> index d6c86db..4d5f5ab 100644
> --- a/Documentation/git-rev-list.txt
> +++ b/Documentation/git-rev-list.txt
> @@ -12,6 +12,8 @@ SYNOPSIS
> 'git-rev-list' [ \--max-count=number ]
> [ \--max-age=timestamp ]
> [ \--min-age=timestamp ]
> + [ \--author=string ]
> + [ \--committer=string ]
> [ \--sparse ]
> [ \--no-merges ]
> [ \--remove-empty ]
These two separate options are Ok at the level of front-end,
but...
> diff --git a/builtin-rev-list.c b/builtin-rev-list.c
> index 402af8e..09e3d37 100644
> --- a/builtin-rev-list.c
> +++ b/builtin-rev-list.c
> @@ -352,7 +352,8 @@ int cmd_rev_list(int argc, const char **
> revs.diff)
> usage(rev_list_usage);
>
> - save_commit_buffer = revs.verbose_header;
> + if (!revs.author_pattern && !revs.committer_pattern)
> + save_commit_buffer = revs.verbose_header;
> track_object_refs = 0;
> if (bisect_list)
> revs.limited = 1;
I wonder if it is simpler and yet more powerful to internally
use a regex to match the contents of commit buffer, not just
specific its header fields.
When --author or --committer is given, you internally synthesize
a regex "^author Jonas Fonseca <fonseca@" from the string.
And then, instead of doing commit_match_ident() twice like this:
> @@ -1074,6 +1123,10 @@ struct commit *get_revision(struct rev_i
> if (revs->no_merges &&
> commit->parents && commit->parents->next)
> continue;
> + if (!commit_match_ident(commit, "author", revs->author_pattern))
> + continue;
> + if (!commit_match_ident(commit, "committer", revs->committer_pattern))
> + continue;
you would just do:
if (revs->commit_filter_pattern &&
commit_search_message(commit, revs->commit_filter_pattern))
continue;
instead.
For an extra bonus point, the matching logic might want to steal
from builtin-grep to allow multiple regular expressions, case
insensitive match and other bells and whistles. You probably
could lift the whole grep_buffer() -- add another option that
behaves similarly to opt->name_only (name it opt->status_only)
but make it not even print anything upon hit, so that you can
tell from the return value if it found the pattern in the
buffer, like this:
diff --git a/builtin-grep.c b/builtin-grep.c
index 8213ce2..714ad50 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -128,6 +128,7 @@ struct grep_opt {
unsigned linenum:1;
unsigned invert:1;
unsigned name_only:1;
+ unsigned status_only:1;
unsigned unmatch_name_only:1;
unsigned count:1;
unsigned word_regexp:1;
@@ -492,6 +493,8 @@ static int grep_buffer(struct grep_opt *
}
if (hit) {
count++;
+ if (opt->status_only)
+ return 1;
if (binary_match_only) {
printf("Binary file %s matches\n", name);
return 1;
Hmm?
^ permalink raw reply related
* Re: [PATCH] git-rev-list(1): group options; reformat; document more options
From: Junio C Hamano @ 2006-09-01 0:06 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jonas Fonseca, Git Mailing List, Timo Hirvonen
In-Reply-To: <Pine.LNX.4.64.0608311611440.27779@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Fri, 1 Sep 2006, Jonas Fonseca wrote:
>> Linus Torvalds <torvalds@osdl.org> wrote Thu, Aug 31, 2006:
>> >
>> > Umm? You should get a "usage" error, no?
>>
>> Yes, ok, they do not seem to make sense for git-rev-list, however if you
>> pass either to git-log, the output seems to make room for a diff, adding
>> one extra newline, but without appending any diff.
>
> Ahh. I think that a "-r" without any other request for patches (or
> "--name-status" or similar) should probably imply "--raw". At least that
> was how it historically worked..
>
> Anyway, _if_ it ever worked (and I think it did, but I'm way too lazy to
> bother checking), this may have been broken by the extensive diff option
> cleanups by Timo in June. Timo? Junio?
I think it did too. I am kind of surprised that nobody noticed
and t4013 test (which was done specifically to catch potential
behaviour change by Timo's patch) did not check for this
particular case.
^ permalink raw reply
* Re: [PATCH] git-rev-list(1): group options; reformat; document more options
From: Linus Torvalds @ 2006-08-31 23:15 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: Git Mailing List, Junio C Hamano, Timo Hirvonen
In-Reply-To: <20060831230811.GE482@diku.dk>
On Fri, 1 Sep 2006, Jonas Fonseca wrote:
> Linus Torvalds <torvalds@osdl.org> wrote Thu, Aug 31, 2006:
> >
> > Umm? You should get a "usage" error, no?
>
> Yes, ok, they do not seem to make sense for git-rev-list, however if you
> pass either to git-log, the output seems to make room for a diff, adding
> one extra newline, but without appending any diff.
Ahh. I think that a "-r" without any other request for patches (or
"--name-status" or similar) should probably imply "--raw". At least that
was how it historically worked..
Anyway, _if_ it ever worked (and I think it did, but I'm way too lazy to
bother checking), this may have been broken by the extensive diff option
cleanups by Timo in June. Timo? Junio?
Linus
^ permalink raw reply
* [PATCH] git(7): move gitk(1) to the list of porcelain commands
From: Jonas Fonseca @ 2006-08-31 23:15 UTC (permalink / raw)
To: git
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
Documentation/git.txt | 10 +++-------
1 files changed, 3 insertions(+), 7 deletions(-)
... in lack of a better place to put it.
Anyway, last patch from me for tonight.
diff --git a/Documentation/git.txt b/Documentation/git.txt
index a9c87e3..76b41c8 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -303,6 +303,9 @@ gitlink:git-format-patch[1]::
gitlink:git-grep[1]::
Print lines matching a pattern.
+gitlink:gitk[1]::
+ The git repository browser.
+
gitlink:git-log[1]::
Shows commit logs.
@@ -483,13 +486,6 @@ gitlink:git-stripspace[1]::
Filter out empty lines.
-Commands not yet documented
----------------------------
-
-gitlink:gitk[1]::
- The gitk repository browser.
-
-
Configuration Mechanism
-----------------------
--
Jonas Fonseca
^ permalink raw reply related
* Re: problem with git-cvsserver
From: Johannes Schindelin @ 2006-08-31 23:13 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Marco Roeland, Junio C Hamano, aonghus, git
In-Reply-To: <46a038f90608311600p747c8a3anbe90dbac928e9923@mail.gmail.com>
Hi,
On Fri, 1 Sep 2006, Martin Langhoff wrote:
> Pg/MySQL aren't really supported, though it wouldn't be that hard.
AFAIK Pg/MySQL/all-the-others want to have a common place where to put the
database files. This is a huge disadvantage over SQLite, where you can put
it anywhere you want (e.g. /blabla/.git/...). This also makes installation
way easier.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-rev-list(1): group options; reformat; document more options
From: Jonas Fonseca @ 2006-08-31 23:08 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0608311557470.27779@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> wrote Thu, Aug 31, 2006:
>
>
> On Fri, 1 Sep 2006, Jonas Fonseca wrote:
> >
> > An attempted facelift to the neglected git-rev-list manpage. One
> > question if I may, the diff-related -r and -t options, how are they
> > supposed to work?
>
> Umm? You should get a "usage" error, no?
Yes, ok, they do not seem to make sense for git-rev-list, however if you
pass either to git-log, the output seems to make room for a diff, adding
one extra newline, but without appending any diff.
--
Jonas Fonseca
^ permalink raw reply
* Re: [PATCH] git-rev-list(1): group options; reformat; document more options
From: Linus Torvalds @ 2006-08-31 23:02 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <20060831223715.GC482@diku.dk>
On Fri, 1 Sep 2006, Jonas Fonseca wrote:
>
> An attempted facelift to the neglected git-rev-list manpage. One
> question if I may, the diff-related -r and -t options, how are they
> supposed to work?
Umm? You should get a "usage" error, no?
Linus
^ permalink raw reply
* Re: problem with git-cvsserver
From: Martin Langhoff @ 2006-08-31 23:00 UTC (permalink / raw)
To: Marco Roeland; +Cc: Junio C Hamano, aonghus, git, Johannes Schindelin
In-Reply-To: <20060831090333.GA28445@fiberbit.xs4all.nl>
On 8/31/06, Marco Roeland <marco.roeland@xs4all.nl> wrote:
> Yes, SQLite v2 and SQLite v3 are different and binary incompatible.
>
> However, on Debian 'etch' you can install packages for both versions
> concurrently; most packages for SQLite have either a '2' or a '3' in the
> name. Packages without the number use the "best current choice" which is
> "3" in 'etch' at the moment but was "2" not too long ago.
Thanks for the info!
I have to say though: Ouch. Do you know if there's an upgrade path for
apps? Does v3 detect you've got a v2 file and do something smart
(upgrade in place / spit out a readable error)?
...
> I'd guess that you were unfortunate enough to just install some packages
> during the transition
Problem is that we have to help with the transition for users that
started with v2 and get upgraded to v3 at the app level I suspect.
> Incidentally I'd guess that in itself SQLite2 (so version 2) would also
> function perfectly well for git-cvsserver (as would PostgreSQL or
> MySQL)
This was developed against v2. If v3 is backwards compatible, it'll
just work. If not... we'll hear about it soon ;-) Pg/MySQL aren't
really supported, though it wouldn't be that hard.
martin
^ permalink raw reply
* [PATCH] Support author and commiter based revision list limiting
From: Jonas Fonseca @ 2006-08-31 22:57 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jeff King, Kai Blin, git
In-Reply-To: <Pine.LNX.4.64.0608281147420.27779@g5.osdl.org>
Adds the two options: --author=string and --committer=string, which can
be used to limit the set of interesting commits to the ones matching the
given idents.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
[ On top of the git-rev-list(1) update posted earlier ... ]
Linus Torvalds <torvalds@osdl.org> wrote Mon, Aug 28, 2006:
> Th[e] trivial approach doesn't allow "gitk" to show the results sanely,
> though (to do that, you'd need to make the commit matching be part of the
> parent simplification instead - that would be extra bonus points for the
> intrpid git hacker-wannabe)
Hereby serving one patch doing the trivial thing very stupid, since I
didn't have the imagination to go and hunt for the bonus points just
yet.
Documentation/git-rev-list.txt | 6 +++++
builtin-rev-list.c | 3 ++
revision.c | 53 ++++++++++++++++++++++++++++++++++++++++
revision.h | 2 ++
4 files changed, 63 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt
index d6c86db..4d5f5ab 100644
--- a/Documentation/git-rev-list.txt
+++ b/Documentation/git-rev-list.txt
@@ -12,6 +12,8 @@ SYNOPSIS
'git-rev-list' [ \--max-count=number ]
[ \--max-age=timestamp ]
[ \--min-age=timestamp ]
+ [ \--author=string ]
+ [ \--committer=string ]
[ \--sparse ]
[ \--no-merges ]
[ \--remove-empty ]
@@ -153,6 +155,10 @@ limiting may be applied.
Limit the commits output to specified time range.
+--author='string', --committer='string'::
+
+ Limit the commits output to specified author and/or committer.
+
--remove-empty::
Stop when a given path disappears from the tree.
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index 402af8e..09e3d37 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -352,7 +352,8 @@ int cmd_rev_list(int argc, const char **
revs.diff)
usage(rev_list_usage);
- save_commit_buffer = revs.verbose_header;
+ if (!revs.author_pattern && !revs.committer_pattern)
+ save_commit_buffer = revs.verbose_header;
track_object_refs = 0;
if (bisect_list)
revs.limited = 1;
diff --git a/revision.c b/revision.c
index b588f74..31618fe 100644
--- a/revision.c
+++ b/revision.c
@@ -671,6 +671,14 @@ int setup_revisions(int argc, const char
revs->min_age = approxidate(arg + 8);
continue;
}
+ if (!strncmp(arg, "--author=", 9)) {
+ revs->author_pattern = arg + 9;
+ continue;
+ }
+ if (!strncmp(arg, "--committer=", 12)) {
+ revs->committer_pattern = arg + 12;
+ continue;
+ }
if (!strcmp(arg, "--all")) {
handle_all(revs, flags);
continue;
@@ -1015,6 +1023,47 @@ static void mark_boundary_to_show(struct
}
}
+static int commit_match_ident(struct commit *commit, const char *field, const char *pattern)
+{
+ const char *pos;
+ int field_len;
+ int pattern_len;
+
+ if (!pattern)
+ return 1;
+
+ field_len = strlen(field);
+ pattern_len = strlen(pattern);
+
+ for (pos = commit->buffer; *pos != '\n'; pos++) {
+ const char *line_end = strchr(pos, '\n');
+
+ if (!strncmp(pos, field, field_len) &&
+ pos[field_len] == ' ') {
+ const char *ident_end = line_end;
+
+ pos += field_len;
+ while (ident_end > pos && ident_end[-1] != '>')
+ ident_end--;
+
+ /* A slow "strncasestr" */
+ while (pos + pattern_len <= ident_end) {
+ if (!strncasecmp(pos, pattern, pattern_len))
+ return 1;
+ pos++;
+ }
+
+ /* Assumes that fields that should be matched only
+ * appear once in the commit header. */
+ return 0;
+ }
+
+ pos = line_end;
+ }
+
+ return 0;
+}
+
struct commit *get_revision(struct rev_info *revs)
{
struct commit_list *list = revs->commits;
@@ -1074,6 +1123,10 @@ struct commit *get_revision(struct rev_i
if (revs->no_merges &&
commit->parents && commit->parents->next)
continue;
+ if (!commit_match_ident(commit, "author", revs->author_pattern))
+ continue;
+ if (!commit_match_ident(commit, "committer", revs->committer_pattern))
+ continue;
if (revs->prune_fn && revs->dense) {
/* Commit without changes? */
if (!(commit->object.flags & TREECHANGE)) {
diff --git a/revision.h b/revision.h
index d289781..7688e3a 100644
--- a/revision.h
+++ b/revision.h
@@ -71,6 +71,8 @@ struct rev_info {
int max_count;
unsigned long max_age;
unsigned long min_age;
+ const char *author_pattern;
+ const char *committer_pattern;
/* diff info for patches and for paths limiting */
struct diff_options diffopt;
--
1.4.2.g2ba6b-dirty
--
Jonas Fonseca
^ permalink raw reply related
* [PATCH] git-rev-list(1): group options; reformat; document more options
From: Jonas Fonseca @ 2006-08-31 22:37 UTC (permalink / raw)
To: git
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
Documentation/git-rev-list.txt | 254 ++++++++++++++++++++++++++++++----------
1 files changed, 188 insertions(+), 66 deletions(-)
An attempted facelift to the neglected git-rev-list manpage. One
question if I may, the diff-related -r and -t options, how are they
supposed to work?
diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt
index a446a6b..d6c86db 100644
--- a/Documentation/git-rev-list.txt
+++ b/Documentation/git-rev-list.txt
@@ -27,111 +27,233 @@ SYNOPSIS
DESCRIPTION
-----------
+
Lists commit objects in reverse chronological order starting at the
given commit(s), taking ancestry relationship into account. This is
useful to produce human-readable log output.
-Commits which are stated with a preceding '{caret}' cause listing to stop at
-that point. Their parents are implied. "git-rev-list foo bar {caret}baz" thus
+Commits which are stated with a preceding '{caret}' cause listing to
+stop at that point. Their parents are implied. Thus the following
+command:
+
+-----------------------------------------------------------------------
+ $ git-rev-list foo bar ^baz
+-----------------------------------------------------------------------
+
means "list all the commits which are included in 'foo' and 'bar', but
not in 'baz'".
-A special notation <commit1>..<commit2> can be used as a
-short-hand for {caret}<commit1> <commit2>.
+A special notation "'<commit1>'..'<commit2>'" can be used as a
+short-hand for "{caret}'<commit1>' '<commit2>'". For example, either of
+the following may be used interchangeably:
-Another special notation is <commit1>...<commit2> which is useful for
-merges. The resulting set of commits is the symmetric difference
+-----------------------------------------------------------------------
+ $ git-rev-list origin..HEAD
+ $ git-rev-list HEAD ^origin
+-----------------------------------------------------------------------
+
+Another special notation is "'<commit1>'...'<commit2>'" which is useful
+for merges. The resulting set of commits is the symmetric difference
between the two operands. The following two commands are equivalent:
-------------
-$ git-rev-list A B --not $(git-merge-base --all A B)
-$ git-rev-list A...B
-------------
+-----------------------------------------------------------------------
+ $ git-rev-list A B --not $(git-merge-base --all A B)
+ $ git-rev-list A...B
+-----------------------------------------------------------------------
+
+gitlink:git-rev-list[1] is a very essential git program, since it
+provides the ability to build and traverse commit ancestry graphs. For
+this reason, it has a lot of different options that enables it to be
+used by commands as different as gitlink:git-bisect[1] and
+gitlink:git-repack[1].
OPTIONS
-------
---pretty::
- Print the contents of the commit changesets in human-readable form.
+
+Commit Formatting
+~~~~~~~~~~~~~~~~~
+
+Using these options, gitlink:git-rev-list[1] will act similar to the
+more specialized family of commit log tools: gitlink:git-log[1],
+gitlink:git-show[1], and gitlink:git-whatchanged[1]
+
+--pretty[='<format>']::
+
+ Pretty print the contents of the commit logs in a given format,
+ where '<format>' can be one of 'raw', 'medium', 'short', 'full',
+ and 'oneline'. When left out the format default to 'medium'.
+
+--relative-date::
+
+ Show dates relative to the current time, e.g. "2 hours ago".
+ Only takes effect for dates shown in human-readable format, such
+ as when using "--pretty".
--header::
- Print the contents of the commit in raw-format; each
- record is separated with a NUL character.
+
+ Print the contents of the commit in raw-format; each record is
+ separated with a NUL character.
--parents::
+
Print the parents of the commit.
---objects::
- Print the object IDs of any object referenced by the listed commits.
- 'git-rev-list --objects foo ^bar' thus means "send me all object IDs
- which I need to download if I have the commit object 'bar', but
- not 'foo'".
+Diff Formatting
+~~~~~~~~~~~~~~~
---objects-edge::
- Similar to `--objects`, but also print the IDs of
- excluded commits prefixed with a `-` character. This is
- used by `git-pack-objects` to build 'thin' pack, which
- records objects in deltified form based on objects
- contained in these excluded commits to reduce network
- traffic.
+Below are listed options that control the formatting of diff output.
+Some of them are specific to gitlink:git-rev-list[1], however other diff
+options may be given. See gitlink:git-diff-files[1] for more options.
---unpacked::
- Only useful with `--objects`; print the object IDs that
- are not in packs.
+-c::
+
+ This flag changes the way a merge commit is displayed. It shows
+ the differences from each of the parents to the merge result
+ simultaneously instead of showing pairwise diff between a parent
+ and the result one at a time. Furthermore, it lists only files
+ which were modified from all parents.
+
+--cc::
+
+ This flag implies the '-c' options and further compresses the
+ patch output by omitting hunks that show differences from only
+ one parent, or show the same change from all but one parent for
+ an Octopus merge.
+
+-r::
+
+ Show recursive diffs.
+
+-t::
+
+ Show the tree objects in the diff output. This implies '-r'.
+
+Commit Limiting
+~~~~~~~~~~~~~~~
+
+Besides specifying a range of commits that should be listed using the
+special notations explained in the description, additional commit
+limiting may be applied.
+
+--
+
+-n 'number', --max-count='number'::
---bisect::
- Limit output to the one commit object which is roughly halfway
- between the included and excluded commits. Thus, if 'git-rev-list
- --bisect foo {caret}bar {caret}baz' outputs 'midpoint', the output
- of 'git-rev-list foo {caret}midpoint' and 'git-rev-list midpoint
- {caret}bar {caret}baz' would be of roughly the same length.
- Finding the change
- which introduces a regression is thus reduced to a binary search:
- repeatedly generate and test new 'midpoint's until the commit chain
- is of length one.
-
---max-count::
Limit the number of commits output.
---max-age=timestamp, --min-age=timestamp::
- Limit the commits output to specified time range.
+--since='date', --after='date'::
+
+ Show commits more recent than a specific date.
+
+--until='date', --before='date'::
---sparse::
- When optional paths are given, the command outputs only
- the commits that changes at least one of them, and also
- ignores merges that do not touch the given paths. This
- flag makes the command output all eligible commits
- (still subject to count and age limitation), but apply
- merge simplification nevertheless.
+ Show commits older than a specific date.
+
+--max-age='timestamp', --min-age='timestamp'::
+
+ Limit the commits output to specified time range.
--remove-empty::
+
Stop when a given path disappears from the tree.
--no-merges::
+
Do not print commits with more than one parent.
--not::
- Reverses the meaning of the '{caret}' prefix (or lack
- thereof) for all following revision specifiers, up to
- the next `--not`.
+
+ Reverses the meaning of the '{caret}' prefix (or lack thereof)
+ for all following revision specifiers, up to the next '--not'.
--all::
- Pretend as if all the refs in `$GIT_DIR/refs/` are
- listed on the command line as <commit>.
---topo-order::
- By default, the commits are shown in reverse
- chronological order. This option makes them appear in
- topological order (i.e. descendant commits are shown
- before their parents).
+ Pretend as if all the refs in `$GIT_DIR/refs/` are listed on the
+ command line as '<commit>'.
--merge::
+
After a failed merge, show refs that touch files having a
conflict and don't exist on all heads to merge.
---relative-date::
- Show dates relative to the current time, e.g. "2 hours ago".
- Only takes effect for dates shown in human-readable format,
- such as when using "--pretty".
+--boundary::
+
+ Output uninteresting commits at the boundary, which are usually
+ not shown.
+
+--dense, --sparse::
+
+When optional paths are given, the default behaviour ('--dense') is to
+only output commits that changes at least one of them, and also ignore
+merges that do not touch the given paths.
+
+Use the '--sparse' flag to makes the command output all eligible commits
+(still subject to count and age limitation), but apply merge
+simplification nevertheless.
+
+--bisect::
+
+Limit output to the one commit object which is roughly halfway between
+the included and excluded commits. Thus, if
+
+-----------------------------------------------------------------------
+ $ git-rev-list --bisect foo ^bar ^baz
+-----------------------------------------------------------------------
+
+outputs 'midpoint', the output of the two commands
+
+-----------------------------------------------------------------------
+ $ git-rev-list foo ^midpoint
+ $ git-rev-list midpoint ^bar ^baz
+-----------------------------------------------------------------------
+
+would be of roughly the same length. Finding the change which
+introduces a regression is thus reduced to a binary search: repeatedly
+generate and test new 'midpoint's until the commit chain is of length
+one.
+
+--
+
+Commit Ordering
+~~~~~~~~~~~~~~~
+
+By default, the commits are shown in reverse chronological order.
+
+--topo-order::
+
+ This option makes them appear in topological order (i.e.
+ descendant commits are shown before their parents).
+
+--date-order::
+
+ This option is similar to '--topo-order' in the sense that no
+ parent comes before all of its children, but otherwise things
+ are still ordered in the commit timestamp order.
+
+Object Traversal
+~~~~~~~~~~~~~~~~
+
+These options are mostly targeted for packing of git repositories.
+
+--objects::
+
+ Print the object IDs of any object referenced by the listed
+ commits. 'git-rev-list --objects foo ^bar' thus means "send me
+ all object IDs which I need to download if I have the commit
+ object 'bar', but not 'foo'".
+
+--objects-edge::
+
+ Similar to '--objects', but also print the IDs of excluded
+ commits prefixed with a "-" character. This is used by
+ gitlink:git-pack-objects[1] to build "thin" pack, which records
+ objects in deltified form based on objects contained in these
+ excluded commits to reduce network traffic.
+
+--unpacked::
+
+ Only useful with '--objects'; print the object IDs that are not
+ in packs.
Author
------
@@ -139,9 +261,9 @@ Written by Linus Torvalds <torvalds@osdl
Documentation
--------------
-Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+Documentation by David Greaves, Junio C Hamano and the git-list
+<git@vger.kernel.org>.
GIT
---
Part of the gitlink:git[7] suite
-
--
1.4.2.g2ba6b-dirty
--
Jonas Fonseca
^ permalink raw reply related
* [PATCH] Use xmalloc instead of malloc
From: Jonas Fonseca @ 2006-08-31 22:32 UTC (permalink / raw)
To: git
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
builtin-fmt-merge-msg.c | 6 +++---
builtin-repo-config.c | 4 ++--
config.c | 4 ++--
git.c | 2 +-
help.c | 2 +-
merge-recursive.c | 6 +++---
mktag.c | 2 +-
send-pack.c | 4 ++--
sha1_file.c | 2 +-
9 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/builtin-fmt-merge-msg.c b/builtin-fmt-merge-msg.c
index 76d22b4..ed59e77 100644
--- a/builtin-fmt-merge-msg.c
+++ b/builtin-fmt-merge-msg.c
@@ -140,14 +140,14 @@ static int handle_line(char *line)
if (!strcmp(".", src) || !strcmp(src, origin)) {
int len = strlen(origin);
if (origin[0] == '\'' && origin[len - 1] == '\'') {
- char *new_origin = malloc(len - 1);
+ char *new_origin = xmalloc(len - 1);
memcpy(new_origin, origin + 1, len - 2);
new_origin[len - 1] = 0;
origin = new_origin;
} else
origin = strdup(origin);
} else {
- char *new_origin = malloc(strlen(origin) + strlen(src) + 5);
+ char *new_origin = xmalloc(strlen(origin) + strlen(src) + 5);
sprintf(new_origin, "%s of %s", origin, src);
origin = new_origin;
}
@@ -214,7 +214,7 @@ static void shortlog(const char *name, u
if (eol) {
int len = eol - bol;
- oneline = malloc(len + 1);
+ oneline = xmalloc(len + 1);
memcpy(oneline, bol, len);
oneline[len] = 0;
} else
diff --git a/builtin-repo-config.c b/builtin-repo-config.c
index 888466c..d19f7dc 100644
--- a/builtin-repo-config.c
+++ b/builtin-repo-config.c
@@ -84,7 +84,7 @@ static int get_value(const char* key_, c
*tl = tolower(*tl);
if (use_key_regexp) {
- key_regexp = (regex_t*)malloc(sizeof(regex_t));
+ key_regexp = (regex_t*)xmalloc(sizeof(regex_t));
if (regcomp(key_regexp, key, REG_EXTENDED)) {
fprintf(stderr, "Invalid key pattern: %s\n", key_);
goto free_strings;
@@ -97,7 +97,7 @@ static int get_value(const char* key_, c
regex_++;
}
- regexp = (regex_t*)malloc(sizeof(regex_t));
+ regexp = (regex_t*)xmalloc(sizeof(regex_t));
if (regcomp(regexp, regex_, REG_EXTENDED)) {
fprintf(stderr, "Invalid pattern: %s\n", regex_);
goto free_strings;
diff --git a/config.c b/config.c
index d9f2b78..782cc31 100644
--- a/config.c
+++ b/config.c
@@ -565,7 +565,7 @@ int git_config_set_multivar(const char*
/*
* Validate the key and while at it, lower case it for matching.
*/
- store.key = (char*)malloc(strlen(key)+1);
+ store.key = xmalloc(strlen(key) + 1);
dot = 0;
for (i = 0; key[i]; i++) {
unsigned char c = key[i];
@@ -633,7 +633,7 @@ int git_config_set_multivar(const char*
} else
store.do_not_match = 0;
- store.value_regex = (regex_t*)malloc(sizeof(regex_t));
+ store.value_regex = (regex_t*)xmalloc(sizeof(regex_t));
if (regcomp(store.value_regex, value_regex,
REG_EXTENDED)) {
fprintf(stderr, "Invalid pattern: %s\n",
diff --git a/git.c b/git.c
index bd07289..05871ad 100644
--- a/git.c
+++ b/git.c
@@ -29,7 +29,7 @@ static void prepend_to_path(const char *
path_len = len + strlen(old_path) + 1;
- path = malloc(path_len + 1);
+ path = xmalloc(path_len + 1);
memcpy(path, dir, len);
path[len] = ':';
diff --git a/help.c b/help.c
index 9ecdefd..0824c25 100644
--- a/help.c
+++ b/help.c
@@ -184,7 +184,7 @@ static void show_man_page(const char *gi
page = git_cmd;
else {
int page_len = strlen(git_cmd) + 4;
- char *p = malloc(page_len + 1);
+ char *p = xmalloc(page_len + 1);
strcpy(p, "git-");
strcpy(p + 4, git_cmd);
p[page_len] = 0;
diff --git a/merge-recursive.c b/merge-recursive.c
index 39a1eae..48b2763 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -283,7 +283,7 @@ static int save_files_dirs(const unsigne
unsigned int mode, int stage)
{
int len = strlen(path);
- char *newpath = malloc(baselen + len + 1);
+ char *newpath = xmalloc(baselen + len + 1);
memcpy(newpath, base, baselen);
memcpy(newpath + baselen, path, len);
newpath[baselen + len] = '\0';
@@ -455,7 +455,7 @@ static int remove_path(const char *name)
if (ret)
return ret;
len = strlen(name);
- dirs = malloc(len+1);
+ dirs = xmalloc(len+1);
memcpy(dirs, name, len);
dirs[len] = '\0';
while ((slash = strrchr(name, '/'))) {
@@ -572,7 +572,7 @@ void update_file_flags(const unsigned ch
flush_buffer(fd, buf, size);
close(fd);
} else if (S_ISLNK(mode)) {
- char *lnk = malloc(size + 1);
+ char *lnk = xmalloc(size + 1);
memcpy(lnk, buf, size);
lnk[size] = '\0';
mkdir_p(path, 0777);
diff --git a/mktag.c b/mktag.c
index be23e58..3448a5d 100644
--- a/mktag.c
+++ b/mktag.c
@@ -119,7 +119,7 @@ #undef PD_FMT
int main(int argc, char **argv)
{
unsigned long size = 4096;
- char *buffer = malloc(size);
+ char *buffer = xmalloc(size);
unsigned char result_sha1[20];
if (argc != 1)
diff --git a/send-pack.c b/send-pack.c
index fd79a61..ac4501d 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -53,7 +53,7 @@ static void exec_rev_list(struct ref *re
if (900 < i)
die("git-rev-list environment overflow");
if (!is_zero_sha1(ref->new_sha1)) {
- char *buf = malloc(100);
+ char *buf = xmalloc(100);
args[i++] = buf;
snprintf(buf, 50, "%s", sha1_to_hex(ref->new_sha1));
buf += 50;
@@ -75,7 +75,7 @@ static void exec_rev_list(struct ref *re
if (is_zero_sha1(ref->new_sha1) &&
!is_zero_sha1(ref->old_sha1) &&
has_sha1_file(ref->old_sha1)) {
- char *buf = malloc(42);
+ char *buf = xmalloc(42);
args[i++] = buf;
snprintf(buf, 42, "^%s", sha1_to_hex(ref->old_sha1));
}
diff --git a/sha1_file.c b/sha1_file.c
index 01aa745..912e1cc 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1774,7 +1774,7 @@ int read_pipe(int fd, char** return_buf,
int index_pipe(unsigned char *sha1, int fd, const char *type, int write_object)
{
unsigned long size = 4096;
- char *buf = malloc(size);
+ char *buf = xmalloc(size);
int ret;
unsigned char hdr[50];
int hdrlen;
--
1.4.2.g2ba6b-dirty
--
Jonas Fonseca
^ permalink raw reply related
* [PATCH] Include config.mak.autogen in the doc Makefile
From: Jonas Fonseca @ 2006-08-31 22:31 UTC (permalink / raw)
To: git
... to install documentation relative to the path set with configure's
--prefix option.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
Documentation/Makefile | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 0d9ffb4..ed8b886 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -33,6 +33,8 @@ # DESTDIR=
INSTALL?=install
+-include ../config.mak.autogen
+
#
# Please note that there is a minor bug in asciidoc.
# The version after 6.0.3 _will_ include the patch found here:
--
1.4.2.g2ba6b-dirty
--
Jonas Fonseca
^ permalink raw reply related
* Re: Compiling git-snapshot-20069831
From: Johannes Schindelin @ 2006-08-31 22:07 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jorma Karvonen, git
In-Reply-To: <Pine.LNX.4.64.0608311435150.27779@g5.osdl.org>
Hi,
On Thu, 31 Aug 2006, Linus Torvalds wrote:
> On Thu, 31 Aug 2006, Johannes Schindelin wrote:
> >
> > BTW I cannot read Finnish
>
> Tssk, tssk. Bad Dscho.
>
> "Tiedostoa tai hakemistoa ei ole" just means "No such file or directory".
>
> EVERYBODY knows that.
Ouch.
Well, I lied. I could _read_ it. But I did not _understand_ it.
If I had read something along the lines of "Des is owwer ned douh!", I'd
stand a chance to understand it.
Honestly, give me something like German, French, Italian, even Swedish or
Franconian, I'll happily read and understand it. And you only understand
it because you happened to live there, and besides drinks and sauna, there
is nothing more interesting than this language consisting of
multi-syllable words ;-)
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Trace into open fd and refactor tracing code.
From: Linus Torvalds @ 2006-08-31 21:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsljc8udx.fsf@assigned-by-dhcp.cox.net>
On Thu, 31 Aug 2006, Junio C Hamano wrote:
>
> Actually it was me who suggested the use of fd directly, along
> with trying to do one message in a single write (i.e. not doing
> stdio as much as possible).
I definitely agree with the "one message in a single write" thing.
That's in fact required to make sure that O_APPEND works properly (ie that
you don't have potentially different processes mixing output)
> I somehow felt there would be less interference between writes
> issued by process A and process B, but probably I am mistaken.
The atomicity guarantees are the same regardless of whether you do a
separate open(), the only thing that matters is that you do want to try to
do messages with a single "write()" call, and that you use O_APPEND. That
should guarantee that you get good behaviour.
Without O_APPEND, you would obviously have to share one single file
descriptor, because otherwise people will just be writing all over each
other.
Linus
^ permalink raw reply
* Re: Compiling git-snapshot-20069831
From: Linus Torvalds @ 2006-08-31 21:37 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jorma Karvonen, git
In-Reply-To: <Pine.LNX.4.63.0608311408350.28360@wbgn013.biozentrum.uni-wuerzburg.de>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 441 bytes --]
On Thu, 31 Aug 2006, Johannes Schindelin wrote:
>
> BTW I cannot read Finnish
Tssk, tssk. Bad Dscho.
"Tiedostoa tai hakemistoa ei ole" just means "No such file or directory".
EVERYBODY knows that.
It's not like there's even a single ä or ö in the whole sentence, so you
can't even blame the strange letters (and that's unusual, since in
Finnish, usually every other letter is 'ä' if only just to confuse the
uninitiated).
Linus
^ permalink raw reply
* Re: Problematic git pack
From: Linus Torvalds @ 2006-08-31 21:33 UTC (permalink / raw)
To: Sergio Callegari; +Cc: git
In-Reply-To: <44F6A198.4040902@arces.unibo.it>
On Thu, 31 Aug 2006, Sergio Callegari wrote:
>
> Junio, can you please send me privately details about [*1*] so I can retrieve
> the pack also?
He already did, search for "members.cox.net" in your email archive (it's
Message-ID: <7v7j0qihwl.fsf@assigned-by-dhcp.cox.net> to be precise).
> I also have another question... (maybe it was answered in some previous thread
> on this list, in this case a pointer would be enough).
> Now I am going to have the fixed archive and also a new archive, which I
> restarted from the latest working copy I had of my project.
> Is there any way to automatically do real "surgery" to attach one to the other
> and get a single archive with all the history?
Yes. This is just what a "grafts" file is for.
Put the old pack/idx files into the .git/objects/packs directory, and then
you can create "fake parenthood" information in a ".git/info/grafts" file
by just adding text-lines of the format "<sha1> <fakeparentsha1>" (with
each SHA being the regular 40-byte hex representation).
> Obviously, if I try to change a commit object to modify its parents, its
> signature changes, so I need to modify its childs and so on, is this correct?
> Alternatively I belive that grafts should be a way to go... I had never used
> them before, do all git tools support them? Particularly do they get pushed
> and pulled correctly?
Nope, they won't get pushed and pulled correctly, you need to put the
grafts files in all repositories. Alternatively, you can re-create the
whole history, I think cogito had some history re-writing tool.
> > So the _real_ difference is literally just the one byte at offset 0151000
> > (decimal 53760) which in the fixed pack is 0x96, and in the corrupt pack it
> > is 0x94. That's a single-bit difference (bit #1 has been cleared).
>
> So, possibly, the alpha particle theory could be the plausible one in the
> end...
Yes. It's just that Junio's original theory required it to not just hit a
memory cell, it also had to hit it at _just_ the right time in between
being written and the SHA1 of the buffer being computed. So the original
theory was very unlikely indeed.
My theory of the corruption just causing a re-computed SHA1 when repacking
(and silently copying the corruption without realizing it) meant that
there was no such small and unlikely window, but that any regular memory
(or disk) corruption could easily have caused it at any time, and then a
subsequent re-pack "fixed" the SHA1 to match the corruption..
> The bad thing is that I don't know which of my two machines (the laptop or the
> desktop) caused the issue!
I'd suggest running memtest86 for a few days on both (not necessarily at
the same time - keep one working machine to do you job on ;)
> > Finally, this also points out that the corrupted packs _can_ be fixed, but I
> > think Sergio was a bit lucky (to offset all the bad luck). Sergio still had
> > access to the original file that had had its object corrupted.
>
> Actually, this could possibly be a not so rare case... In my tree I had the
> development of some LaTeX documents and packages (code like, the really
> "precious" files) and a few binary objects (images and openoffice files
> mainly, by far less precious).
Sure. In your case you had checked in generated files too, and yes, they
were the larger ones. That's not true in general - in many other projects,
the _directory_ structure (ie the git "tree" objects) will be a large
portion of the project, and probably more likely to be corrupt. Now, to
some degree the tree objects are likely the ones easiest to "repair"
(because you can try to look at the history and figure things out by
hand), but at the same time, people also tend to have deeper delta-chains
and it would just be _very_ painful.
So I do think you were somewhat lucky.
> Finally, having a command to create an object out of a single file (contrary
> of git cat-file) could help re-creating the missing objects...
Hmm. Like "git-hash-object"?
Linus
^ permalink raw reply
* Re: [PATCH] Trace into open fd and refactor tracing code.
From: Junio C Hamano @ 2006-08-31 21:31 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0608311409470.27779@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> That way, if you want to do the fd thing, you can always just do
>
> GIT_TRACE=/proc/self/fd/9 make test 9>/var/tmp/trace.log
>
> although I really don't know how well that works across a fork/exec that
> may or may not be closing the file descriptor (I think it's much simpler
> and more obvious to just give the filename directly).
Actually it was me who suggested the use of fd directly, along
with trying to do one message in a single write (i.e. not doing
stdio as much as possible).
Process A has fd=9 opened to /var/tmp/trace.log and forks
process B.
(1) process B execs something else, and just writes into fd=9
or
(2) process B execs something else, perhaps after closing fd=9,
and the exec'ed image opens /var/tmp/trace.log with
"O_APPEND|O_CREAT" and gets a fd; it writes into this fd.
I somehow felt there would be less interference between writes
issued by process A and process B, but probably I am mistaken.
^ permalink raw reply
* Re: [PATCH] Trace into open fd and refactor tracing code.
From: Linus Torvalds @ 2006-08-31 21:14 UTC (permalink / raw)
To: Christian Couder; +Cc: Junio Hamano, Git Mailing List
In-Reply-To: <20060831084211.28d38764.chriscool@tuxfamily.org>
On Thu, 31 Aug 2006, Christian Couder wrote:
>
> It's now possible to run the tests like this:
>
> GIT_TRACE=9 make test 9>/var/tmp/trace.log
Wouldn't it me _much_ more natural to instead do
GIT_TRACE=/var/tmp/trace.log make test
and just have git open that file with "O_APPEND | O_CREAT"?
Maybe make the rule be that this only happens if the GIT_TRACE variable
starts with a '/' character (ie you have to make it an absolute path).
That way, if you want to do the fd thing, you can always just do
GIT_TRACE=/proc/self/fd/9 make test 9>/var/tmp/trace.log
although I really don't know how well that works across a fork/exec that
may or may not be closing the file descriptor (I think it's much simpler
and more obvious to just give the filename directly).
Hmm?
Linus
^ permalink raw reply
* [PATCH] gitweb: Remove forgotten call to git_to_hash
From: Dennis Stosberg @ 2006-08-31 19:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git
In-Reply-To: <7vac5px1ic.fsf@assigned-by-dhcp.cox.net>
On Aug 27th, Jakub Narebski sent a patch which removed the git_to_hash()
function and this call to it. The patch did not apply cleanly and had to
be applied manually. Removing the last chunk has obviously been forgotten.
See: commit 0aea33762b1262d11fb43eda9f3fc152b5622cca and
message <200608272345.26722.jnareb@gmail.com>
Signed-off-by: Dennis Stosberg <dennis@stosberg.net>
---
gitweb/gitweb.perl | 4 ----
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 9324d71..68f40bd 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2778,10 +2778,6 @@ sub git_blobdiff {
@difftree
or die_error('404 Not Found', "Blob diff not found");
- } elsif (defined $hash) { # try to find filename from $hash
- if ($hash !~ /[0-9a-fA-F]{40}/) {
- $hash = git_to_hash($hash);
- }
} elsif (defined $hash &&
$hash =~ /[0-9a-fA-F]{40}/) {
# try to find filename from $hash
--
1.4.2
^ permalink raw reply related
* Re: Compiling git-snapshot-20069831
From: Jakub Narebski @ 2006-08-31 19:30 UTC (permalink / raw)
To: git
In-Reply-To: <44F71B79.5070901@users.sourceforge.net>
Jorma Karvonen wrote:
> Johannes Schindelin wrote:
>
>> On Thu, 31 Aug 2006, Jorma Karvonen wrote:
>>
>>> I tried
>>>
>>> make configure
>>>
>>> and got an error message:
>>>
>>> /bin/sh: curl-config: command not found
>>> make: **** No rule to make target `configure'. Stop.
The offending line seems to be
curl_check := $(shell (echo 070908; curl-config --vernum) | sort -r | sed -ne 2p)
and it is turned off if you always run make with NO_CURL=1.
Or write NO_CURL=1 (or NO_CURL=YesPlease) in the config.mak file
>> Okay. I deem this a bug in our Makefile.
>>
>> Could you please try "autoconf" and _then_ "./configure"?
>>
> I tried autoconf and result was:
>
> autoconf: no input file
"autoconf -o configure configure.ac" then
By the way, from what directory you try to run make from?
autoconf default input file is configure.ac, and AFAIK it is
present in 'master' from quite some time, and perhaps in 'maint'
as well.
What is in GIT-VERSION-FILE aftre running GIT-VERSION-GEN?
Below my results of running make configure in git/ working directory:
1047:jnareb@roke:~/git> make configure
GIT_VERSION = 1.4.2.gf713
rm -f configure configure.ac+
sed -e 's/@@GIT_VERSION@@/1.4.2.gf713/g' \
configure.ac > configure.ac+
autoconf -o configure configure.ac+
rm -f configure.ac+
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 0/3] git-daemon: plug new upload-tar command
From: Rene Scharfe @ 2006-08-31 17:45 UTC (permalink / raw)
To: Franck Bui-Huu; +Cc: junkio, git
In-Reply-To: <11570277231100-git-send-email-vagabon.xyz@gmail.com>
Hi,
Franck Bui-Huu schrieb:
> Here's a simple patchset that basically teach git-daemon about the
> upload-tar command added by Junio's commit:
Junio has similar code in the 'next' branch. And he correctly pointed
out that with the arrival of git-zip-tree the time has come to think
about a format independent tree-to-archive converter command to avoid
re-implementing essentially the same thing under the names of
git-upload-zip, git-upload-rar etc.
I'm trying for a few days now to find time for implementing a
git-archive command, but I'm failing. And I won't be able to do so
before the weekend (at least).
I propose to make the command line syntax more similar to the one of
git-ls-tree (e.g. --prefix instead of optional second non-option
parameter for base dir, support for path specs). In a previous mail I
also proposed to merge the upload command into git-archive, but now that
I thought a bit about it it doesn't make sense to me anymore.
So if you beat me to it, that would be great. Or if you have a better
idea, that would be also great. :-)
I have to go now..
René
^ permalink raw reply
* Re: Compiling git-snapshot-20069831
From: Jorma Karvonen @ 2006-08-31 17:25 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0608311904520.28360@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Thu, 31 Aug 2006, Jorma Karvonen wrote:
>
>
>> I tried
>>
>> make configure
>>
>> and got an error message:
>>
>> /bin/sh: curl-config: command not found
>> make: **** No rule to make target `configure'. Stop.
>>
>
> Okay. I deem this a bug in our Makefile.
>
> Could you please try "autoconf" and _then_ "./configure"?
>
> Hth,
> Dscho
>
>
Hi,
I tried autoconf and result was:
autoconf: no input file
Best regards,
Jorma Karvonen
karvjorm (at) users (dot) sourceforge (dot) net
^ 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