* Re: [PATCH v2] Teach git diff about Objective-C syntax
From: Jonathan del Strother @ 2008-10-02 10:40 UTC (permalink / raw)
To: git
Cc: Miklos Vajna, Johannes Schindelin, Junio C Hamano,
Andreas Ericsson, Jonathan del Strother
In-Reply-To: <1222818394-11547-1-git-send-email-jon.delStrother@bestbefore.tv>
On Wed, Oct 1, 2008 at 12:46 AM, Jonathan del Strother
<jon.delStrother@bestbefore.tv> wrote:
> Add support for recognition of Objective-C class & instance methods, C functions, and class implementation/interfaces.
>
> Signed-off-by: Jonathan del Strother <jon.delStrother@bestbefore.tv>
> ---
> This version is much the same, but rebuilt on top of 1883a0d3b to use the extended regexp stuff, and it doesn't attempt to tidy up other patterns.
>
> Documentation/gitattributes.txt | 2 ++
> diff.c | 10 ++++++++++
> 2 files changed, 12 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
> index 2ae771f..2694559 100644
> --- a/Documentation/gitattributes.txt
> +++ b/Documentation/gitattributes.txt
> @@ -315,6 +315,8 @@ patterns are available:
>
> - `java` suitable for source code in the Java language.
>
> +- `objc` suitable for source code in the Objective-C language.
> +
> - `pascal` suitable for source code in the Pascal/Delphi language.
>
> - `php` suitable for source code in the PHP language.
> diff --git a/diff.c b/diff.c
> index b001d7b..3694602 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -1429,6 +1429,16 @@ static const struct funcname_pattern_entry builtin_funcname_pattern[] = {
> "!^[ \t]*(catch|do|for|if|instanceof|new|return|switch|throw|while)\n"
> "^[ \t]*(([ \t]*[A-Za-z_][A-Za-z_0-9]*){2,}[ \t]*\\([^;]*)$",
> REG_EXTENDED },
> + { "objc",
> + /* Negate C statements that can look like functions */
> + "!^[ \t]*(do|for|if|else|return|switch|while)\n"
> + /* Objective-C methods */
> + "^[ \t]*([-+][ \t]*\\([ \t]*[A-Za-z_][A-Za-z_0-9* \t]*\\)[ \t]*[A-Za-z_].*)$\n"
> + /* C functions */
> + "^[ \t]*(([ \t]*[A-Za-z_][A-Za-z_0-9]*){2,}[ \t]*\\([^;]*)$\n"
> + /* Objective-C class/protocol definitions */
> + "^(@(implementation|interface|protocol)[ \t].*)$",
> + REG_EXTENDED },
> { "pascal",
> "^((procedure|function|constructor|destructor|interface|"
> "implementation|initialization|finalization)[ \t]*.*)$"
> --
Given Brandon's "strip newline (and cr) from line before pattern
matching" patch, the objective C line could be changed to
"^[ \t]*([-+][ \t]*\\([ \t]*[A-Za-z_][A-Za-z_0-9* \t]*\\)[
\t]*[A-Za-z_][A-Za-z_0-9:{()*& \t]*)$\n"
to be more specific about what's allowed to occur on a method line.
Depends how often we really care about getting the funcname right -
for instance, do we want to deal with cases like :
-(void)doStuff:(NSString*)foo { // TODO : This is a %@^$#@ method
name, change it.
? I suspect the additional complexity that would be added to the
regex isn't worth the small gain - any thoughts?
^ permalink raw reply
* Re: [PATCH] xdiff-interface.c: strip newline (and cr) from line before pattern matching
From: Jonathan del Strother @ 2008-10-02 10:29 UTC (permalink / raw)
To: Brandon Casey
Cc: Git Mailing List, Miklos Vajna, Johannes Schindelin,
Junio C Hamano, Andreas Ericsson
In-Reply-To: <o5dqpNECJusQHKCTvRWiIqN2ZJ7w-fyC-0vM99FajJIgLsOwP3RNug@cipher.nrlssc.navy.mil>
On Wed, Oct 1, 2008 at 8:28 PM, Brandon Casey <casey@nrlssc.navy.mil> wrote:
> POSIX doth sayeth:
>
> "In the regular expression processing described in IEEE Std 1003.1-2001,
> the <newline> is regarded as an ordinary character and both a period and
> a non-matching list can match one. ... Those utilities (like grep) that
> do not allow <newline>s to match are responsible for eliminating any
> <newline> from strings before matching against the RE."
>
> Thus far git has not been removing the trailing newline from strings matched
> against regular expression patterns. This has the effect that (quoting
> Jonathan del Strother) "... a line containing just 'FUNCNAME' (terminated by
> a newline) will be matched by the pattern '^(FUNCNAME.$)' but not
> '^(FUNCNAME$)'", and more simply not '^FUNCNAME$'.
>
> Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
> ---
>
>
> This could be a little simpler if I knew what was guaranteed from xdiff.
> Such as whether the len elements of line were guaranteed to be newline
> terminated, or be greater than zero. But, the code in def_ff() in xemit.c
> is wrapped in 'if (len > 0)', so..
>
> -brandon
>
>
> xdiff-interface.c | 12 +++++++++++-
> 1 files changed, 11 insertions(+), 1 deletions(-)
>
> diff --git a/xdiff-interface.c b/xdiff-interface.c
> index 8bab82e..61f5dab 100644
> --- a/xdiff-interface.c
> +++ b/xdiff-interface.c
> @@ -191,12 +191,22 @@ struct ff_regs {
> static long ff_regexp(const char *line, long len,
> char *buffer, long buffer_size, void *priv)
> {
> - char *line_buffer = xstrndup(line, len); /* make NUL terminated */
> + char *line_buffer;
> struct ff_regs *regs = priv;
> regmatch_t pmatch[2];
> int i;
> int result = -1;
>
> + /* Exclude terminating newline (and cr) from matching */
> + if (len > 0 && line[len-1] == '\n') {
> + if (len > 1 && line[len-2] == '\r')
> + len -= 2;
> + else
> + len--;
> + }
> +
> + line_buffer = xstrndup(line, len); /* make NUL terminated */
> +
> for (i = 0; i < regs->nr; i++) {
> struct ff_reg *reg = regs->array + i;
> if (!regexec(®->re, line_buffer, 2, pmatch, 0)) {
> --
> 1.6.0.2.323.g7c850
>
>
Looks good to me, or at least, works as advertised with a bunch of my
funcname patterns.
^ permalink raw reply
* Re: [PATCHv4] gitweb: PATH_INFO support improvements
From: Jakub Narebski @ 2008-10-02 10:16 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Junio C Hamano, Shawn O. Pearce
In-Reply-To: <cb7bb73a0810020149l4722be08p52be3b4703be0e41@mail.gmail.com>
Giuseppe Bilotta wrote:
> On Thu, Oct 2, 2008 at 10:19 AM, Jakub Narebski wrote:
> >
> > A nit: when sending longer patch series you should use numbered
> > format in the form of [PATCH m/n] or [PATCH m/n vX] prefix.
>
> W00t, I still manage to get this wrong. Kudos to me 8-/
>
> I wonder why these options are not the default when there is more than
> one patch, btw?
>
> (And yes, I tried looking into the builtin-log.c code but making it
> automatic is somewhat less trivial than I can dedicate time to.)
Hmmm... I thought that format.numbered config variable is 'auto' by
default; I guess it isn't (just so you know where to look to change
it ;-)).
I have the following in the .git/config / ~/.gitconfig:
[format]
numbered = auto
suffix = .txt
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] archive.c: make archiver static
From: Nanako Shiraishi @ 2008-10-02 10:14 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
This variable is not used anywhere outside.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
---
archive.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/archive.c b/archive.c
index e2280df..44ab008 100644
--- a/archive.c
+++ b/archive.c
@@ -15,7 +15,7 @@ static char const * const archive_usage[] = {
#define USES_ZLIB_COMPRESSION 1
-const struct archiver {
+static const struct archiver {
const char *name;
write_archive_fn_t write_archive;
unsigned int flags;
--
1.6.0.2
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply related
* [PATCH] commit.c: make read_graft_file() static
From: Nanako Shiraishi @ 2008-10-02 10:14 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
This function is not called by any other file.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
---
commit.c | 2 +-
commit.h | 1 -
2 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/commit.c b/commit.c
index dc0c5bf..c99db16 100644
--- a/commit.c
+++ b/commit.c
@@ -160,7 +160,7 @@ struct commit_graft *read_graft_line(char *buf, int len)
return graft;
}
-int read_graft_file(const char *graft_file)
+static int read_graft_file(const char *graft_file)
{
FILE *fp = fopen(graft_file, "r");
char buf[1024];
diff --git a/commit.h b/commit.h
index de15f4d..4c05864 100644
--- a/commit.h
+++ b/commit.h
@@ -118,7 +118,6 @@ struct commit_graft {
struct commit_graft *read_graft_line(char *buf, int len);
int register_commit_graft(struct commit_graft *, int);
-int read_graft_file(const char *graft_file);
struct commit_graft *lookup_commit_graft(const unsigned char *sha1);
extern struct commit_list *get_merge_bases(struct commit *rev1, struct commit *rev2, int cleanup);
--
1.6.0.2
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply related
* [PATCH] config.c: make git_parse_long() static
From: Nanako Shiraishi @ 2008-10-02 10:14 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
This function is not used in any other file.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
---
cache.h | 1 -
config.c | 4 ++--
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/cache.h b/cache.h
index de8c2b6..5a61f5e 100644
--- a/cache.h
+++ b/cache.h
@@ -742,7 +742,6 @@ typedef int (*config_fn_t)(const char *, const char *, void *);
extern int git_default_config(const char *, const char *, void *);
extern int git_config_from_file(config_fn_t fn, const char *, void *);
extern int git_config(config_fn_t fn, void *);
-extern int git_parse_long(const char *, long *);
extern int git_parse_ulong(const char *, unsigned long *);
extern int git_config_int(const char *, const char *);
extern unsigned long git_config_ulong(const char *, const char *);
diff --git a/config.c b/config.c
index 53f04a0..7d5843f 100644
--- a/config.c
+++ b/config.c
@@ -255,7 +255,7 @@ static int parse_unit_factor(const char *end, unsigned long *val)
return 0;
}
-int git_parse_long(const char *value, long *ret)
+static int git_parse_long(const char *value, long *ret)
{
if (value && *value) {
char *end;
@@ -291,7 +291,7 @@ static void die_bad_config(const char *name)
int git_config_int(const char *name, const char *value)
{
- long ret;
+ long ret = 0;
if (!git_parse_long(value, &ret))
die_bad_config(name);
return ret;
--
1.6.0.2
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply related
* [PATCH] run-command.c: remove run_command_v_opt_cd()
From: Nanako Shiraishi @ 2008-10-02 10:14 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
This function is not used anywhere.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
---
run-command.c | 8 --------
run-command.h | 1 -
2 files changed, 0 insertions(+), 9 deletions(-)
diff --git a/run-command.c b/run-command.c
index caab374..c90cdc5 100644
--- a/run-command.c
+++ b/run-command.c
@@ -273,14 +273,6 @@ int run_command_v_opt(const char **argv, int opt)
return run_command(&cmd);
}
-int run_command_v_opt_cd(const char **argv, int opt, const char *dir)
-{
- struct child_process cmd;
- prepare_run_command_v_opt(&cmd, argv, opt);
- cmd.dir = dir;
- return run_command(&cmd);
-}
-
int run_command_v_opt_cd_env(const char **argv, int opt, const char *dir, const char *const *env)
{
struct child_process cmd;
diff --git a/run-command.h b/run-command.h
index 4f2b7d7..a8b0c20 100644
--- a/run-command.h
+++ b/run-command.h
@@ -53,7 +53,6 @@ int run_command(struct child_process *);
#define RUN_GIT_CMD 2 /*If this is to be git sub-command */
#define RUN_COMMAND_STDOUT_TO_STDERR 4
int run_command_v_opt(const char **argv, int opt);
-int run_command_v_opt_cd(const char **argv, int opt, const char *dir);
/*
* env (the environment) is to be formatted like environ: "VAR=VALUE".
--
1.6.0.2
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply related
* [PATCH] dir.c: make dir_add_name() and dir_add_ignored() static
From: Nanako Shiraishi @ 2008-10-02 10:14 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
These functions are not used by any other file.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
---
dir.c | 4 ++--
dir.h | 1 -
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/dir.c b/dir.c
index acf1001..f79ec61 100644
--- a/dir.c
+++ b/dir.c
@@ -382,7 +382,7 @@ static struct dir_entry *dir_entry_new(const char *pathname, int len)
return ent;
}
-struct dir_entry *dir_add_name(struct dir_struct *dir, const char *pathname, int len)
+static struct dir_entry *dir_add_name(struct dir_struct *dir, const char *pathname, int len)
{
if (cache_name_exists(pathname, len, ignore_case))
return NULL;
@@ -391,7 +391,7 @@ struct dir_entry *dir_add_name(struct dir_struct *dir, const char *pathname, int
return dir->entries[dir->nr++] = dir_entry_new(pathname, len);
}
-struct dir_entry *dir_add_ignored(struct dir_struct *dir, const char *pathname, int len)
+static struct dir_entry *dir_add_ignored(struct dir_struct *dir, const char *pathname, int len)
{
if (cache_name_pos(pathname, len) >= 0)
return NULL;
diff --git a/dir.h b/dir.h
index 2df15de..c98ad98 100644
--- a/dir.h
+++ b/dir.h
@@ -73,7 +73,6 @@ extern void add_excludes_from_file(struct dir_struct *, const char *fname);
extern void add_exclude(const char *string, const char *base,
int baselen, struct exclude_list *which);
extern int file_exists(const char *);
-extern struct dir_entry *dir_add_name(struct dir_struct *dir, const char *pathname, int len);
extern char *get_relative_cwd(char *buffer, int size, const char *dir);
extern int is_inside_dir(const char *dir);
--
1.6.0.2
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply related
* Re: [PATCH] Solaris: Use OLD_ICONV to avoid compile warnings
From: David Soria Parra @ 2008-10-02 10:09 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20081002010816.GA27415@coredump.intra.peff.net>
Jeff King schrieb:
> Do you also unset NEEDS_LIBICONV (and which version of Solaris are you
> running)? Our Makefile sets it to "yes" for Solaris 8, but my build box
> requires that it be unset. I'm not sure if my setup is somehow
> deficient, or if it is only other versions that need it.
I'm using OpenSolaris which is identified as SunOS 5.11. Therefore the
Makefile doesn't set NEEDS_LIBICONV. I'm not sure if it's needed on
Solaris 8 or not, but it's not needed on OpenSolaris.
David
^ permalink raw reply
* Re: Git commit hash clash prevention
From: Johannes Schindelin @ 2008-10-02 10:07 UTC (permalink / raw)
To: martin f krafft; +Cc: git discussion list
In-Reply-To: <20081002085358.GA5342@lapse.rw.madduck.net>
Hi,
On Thu, 2 Oct 2008, martin f krafft wrote:
> the other day during a workshop on Git, one of the attendants asked
> about the scenario when two developers, Jane and David, both working on
> the same project, both create a commit and the two just so happen to
> have the same SHA-1. I realise that the likelihood of this happening is
> about as high as the chance of <insert witty joke here>, but it *is*
> possible, isn't it? Even though this is thus somewhat academic, I am
> still very curious about it.
It _is_ academic. Did you already discuss the chance that your wife gives
birth to a mouse? I haven't done the maths yet, but I am pretty certain
that this would be more likely than an unintended SHA-1 collision.
> What happens when David now pulls from Jane? How does Git deal with
> this?
Basically, the commit that David has will not be overwritten. So every
commit referring to Jane's commit would point to David's in his
repository.
But the more likely case (well, as likely goes) would be that either
Jane's or David's object is actually a blob. And Git would complain about
a type mismatch then.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCHv4] gitweb: parse project/action/hash_base:filename PATH_INFO
From: Giuseppe Bilotta @ 2008-10-02 9:43 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Petr Baudis, Junio C Hamano, Shawn O. Pearce
In-Reply-To: <200810021059.19708.jnareb@gmail.com>
On Thu, Oct 2, 2008 at 10:59 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> Giuseppe Bilotta wrote:
>>
>> +# dispatch
>> +my %actions = (
>> + "blame" => \&git_blame,
> [...]
>> +);
>
> I'm not sure if the '# dispatch' comment is correct here now that
> %actions hash is moved away from actual dispatch (selecting action
> to run)
Bingo.
>> @@ -519,9 +550,19 @@ sub evaluate_path_info {
>> # do not change any parameters if an action is given using the query string
>> return if $action;
>> $path_info =~ s,^\Q$project\E/*,,;
>> +
>> + # next comes the action
>> + $action = $path_info;
>> + $action =~ s,/.*$,,;
>
> I would use here pattern matching, but your code is also good and
> doesn't need changing; just for completeness below there is alternate
> solution:
>
> + $path_info =~ m,^(.*?)/,;
> + $action = $1;
Yeah, I just followed the existing code style.
>> @@ -534,8 +575,9 @@ sub evaluate_path_info {
>> $file_name ||= validate_pathname($pathname);
>> } elsif (defined $refname) {
>> # we got "project.git/branch"
>
> You meant here
>
> # we got "project.git/branch" or "project.git/action/branch"
Yes I do.
>> - $action ||= "shortlog";
>> - $hash ||= validate_refname($refname);
>> + $action ||= "shortlog";
>> + $hash ||= validate_refname($refname);
>> + $hash_base ||= validate_refname($refname);
>> }
>> }
>
> This hunk is IMHO incorrect. First, $refname is _either_ $hash, or
> $hash_base; it cannot be both. Second, in most cases (like the case
> of 'shortlog' action, either explicit or implicit) it is simply $hash;
> I think it can be $hash_base when $file_name is not set only in
> singular exception case of 'tree' view for the top tree (lack of
> filename is not an error, but is equivalent to $file_name='/').
OTOH, while setting both $hash and $hash_base has worked fine for me
so far (because the right one is automatically used and apparently
setting the other doesn't hurt), choosing which one to set is a much
hairier case. Do you have suggestions for a better way to always make
it work?
>> @@ -544,37 +586,6 @@ evaluate_path_info();
>> our $git_dir;
>> $git_dir = "$projectroot/$project" if $project;
>>
>> -# dispatch
>> -my %actions = (
> [...]
>> -);
>> -
>> if (!defined $action) {
>> if (defined $hash) {
>> $action = git_get_type($hash);
>
> I _think_ the '# dispatch' comment should be left here, and not moved
> with the %actions hash.
I agree.
>> @@ -631,8 +642,15 @@ sub href (%) {
>> if ($params{-replay}) {
>> while (my ($name, $symbol) = each %mapping) {
>> if (!exists $params{$name}) {
>> - # to allow for multivalued params we use arrayref form
>> - $params{$name} = [ $cgi->param($symbol) ];
>> + # the parameter we want to recycle may be either part of the
>> + # list of CGI parameter, or recovered from PATH_INFO
>> + if ($cgi->param($symbol)) {
>> + # to allow for multivalued params we use arrayref form
>> + $params{$name} = [ $cgi->param($symbol) ];
>> + } else {
>> + no strict 'refs';
>> + $params{$name} = $$name if $$name;
>
> I would _perhaps_ add here comment that multivalued parameters can come
> only from CGI query string, so there is no need for something like:
>
> + $params{$name} = (ref($$name) ? @$name : $$name) if $$name;
>
>> + }
>> }
>> }
>> }
>
> This fragment is a bit of ugly code, hopefully corrected in later patch.
> I think it would be better to have 'refactor parsing/validation of input
> parameters' to be very fist patch in series; I am not sure but I suspect
> that is a kind of bugfix for current "$project/$hash" ('shortlog' view)
> and "$project/$hash_base:$file_name" ('blob_plain' and 'tree' view)
> path_info.
But implementing the path_info parsing first makes the input param
refactoring SO much nicer that I would rather put a comment here
saying "this code sucks: we should rather collect all input
parameters" and then clean it up on the subsequent patch.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: Git commit hash clash prevention
From: Thomas Rast @ 2008-10-02 9:18 UTC (permalink / raw)
To: martin f krafft; +Cc: git discussion list
In-Reply-To: <20081002085358.GA5342@lapse.rw.madduck.net>
[-- Attachment #1: Type: text/plain, Size: 1760 bytes --]
martin f krafft wrote:
> the other day during a workshop on Git, one of the attendants asked
> about the scenario when two developers, Jane and David, both working
> on the same project, both create a commit and the two just so happen
> to have the same SHA-1. I realise that the likelihood of this
> happening is about as high as the chance of <insert witty joke
> here>, but it *is* possible, isn't it? Even though this is thus
> somewhat academic, I am still very curious about it.
>
> What happens when David now pulls from Jane? How does Git deal with
> this?
There are two cases:
* The commits are exactly identical. This won't happen in your
scenario, but is still theoretically possible if you commit the same
tree with the same author info, timestamps, etc. on two different
machines. Then there is no problem, because they really are the
same.
* They're not identical, but there is a hash collision. Git will
become very confused because it only ever saves one of them. (I
suppose it'd "only" corrupt the DAG if the two are commits, but in
the general case a commit could collide with a tree etc.)
However, the expected number of objects needed to get a collision is
on the order of 2**80 (http://en.wikipedia.org/wiki/Birthday_attack),
and since there are (very roughly) 2**25 seconds in a year and 2**34
years in the age of the universe, that still leaves you with 2**21
ages of the universe to go.
(I hope I did the counting right...)
> I imagine it'll be able to distinguish the two commits based on
> metadata, but won't the DAG get corrupted?
No, it does not distinguish between objects in any way but the SHA1.
- Thomas
--
Thomas Rast
trast@student.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH v3] tests: add a testcase for "git submodule sync"
From: David Aguilar @ 2008-10-02 9:11 UTC (permalink / raw)
To: spearce; +Cc: git, mlevedahl, gitster, David Aguilar
This testcase ensures that upstream changes to submodule properties
can be updated using the sync subcommand. This particular test
changes the submodule URL upstream and uses the sync command to update
an existing checkout.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
sorry for the noise, :-/ please disregard the last two emails
t/t7403-submodule-sync.sh | 64 +++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 64 insertions(+), 0 deletions(-)
diff --git a/t/t7403-submodule-sync.sh b/t/t7403-submodule-sync.sh
new file mode 100755
index 0000000..d9e04d4
--- /dev/null
+++ b/t/t7403-submodule-sync.sh
@@ -0,0 +1,64 @@
+#!/bin/sh
+#
+# Copyright (c) 2008 David Aguilar
+#
+
+test_description='git submodule sync
+
+These tests exercise the "git submodule sync" subcommand.
+'
+
+. ./test-lib.sh
+
+test_expect_success setup '
+ echo file > file &&
+ git add file &&
+ test_tick &&
+ git commit -m upstream
+ git clone . super &&
+ git clone super submodule &&
+ (cd super &&
+ git submodule add ../submodule submodule &&
+ test_tick &&
+ git commit -m "submodule"
+ ) &&
+ git clone super super-clone &&
+ (cd super-clone && git submodule update --init)
+'
+
+test_expect_success 'change submodule' '
+ (cd submodule &&
+ echo second line >> file &&
+ test_tick &&
+ git commit -a -m "change submodule"
+ )
+'
+
+test_expect_success 'change submodule url' '
+ (cd super &&
+ cd submodule &&
+ git checkout master &&
+ git pull
+ ) &&
+ mv submodule moved-submodule &&
+ (cd super &&
+ git config -f .gitmodules submodule.submodule.url ../moved-submodule
+ test_tick &&
+ git commit -a -m moved-submodule
+ )
+'
+
+test_expect_success '"git submodule sync" should update submodule URLs' '
+ (cd super-clone &&
+ git pull &&
+ git submodule sync
+ ) &&
+ test -d "$(git config -f super-clone/submodule/.git/config \
+ remote.origin.url)" &&
+ (cd super-clone/submodule &&
+ git checkout master &&
+ git pull
+ )
+'
+
+test_done
--
1.6.0.2.428.g5e22e
^ permalink raw reply related
* [PATCH v2] tests: add a testcase for "git submodule sync"
From: David Aguilar @ 2008-10-02 8:55 UTC (permalink / raw)
To: spearce; +Cc: git, mlevedahl, gitster, David Aguilar
This testcase ensures that upstream changes to submodule properties
can be updated using the sync subcommand. This particular test
changes the submodule URL upstream and uses the sync command to update
an existing checkout.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
t/t7403-submodule-sync.sh | 71 +++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 71 insertions(+), 0 deletions(-)
diff --git a/t/t7403-submodule-sync.sh b/t/t7403-submodule-sync.sh
new file mode 100755
index 0000000..c034c9e
--- /dev/null
+++ b/t/t7403-submodule-sync.sh
@@ -0,0 +1,71 @@
+#!/bin/sh
+#
+# Copyright (c) 2008 David Aguilar
+#
+
+test_description='git submodule sync
+
+These tests exercise the "git submodule sync" subcommand.
+'
+
+. ./test-lib.sh
+
+test_expect_success setup '
+ mkdir upstream &&
+ (cd upstream &&
+ git init &&
+ echo file > file &&
+ git add file &&
+ test_tick &&
+ git commit -m upstream
+ ) &&
+ git clone upstream super &&
+ git clone super submodule &&
+ (cd super &&
+ git submodule add ../submodule submodule &&
+ git commit -m "submodule"
+ ) &&
+ git clone super super-clone &&
+ (cd super-clone && git submodule update --init)
+'
+
+test_expect_success 'change submodule' '
+ (cd submodule &&
+ echo second line >> file &&
+ test_tick &&
+ git commit -a -m "change submodule"
+ )
+'
+
+test_expect_success 'change submodule url' '
+ (cd super &&
+ cd submodule &&
+ git checkout master &&
+ test_tick &&
+ git pull
+ ) &&
+ mv submodule moved-submodule &&
+ (cd super &&
+ git config -f .gitmodules submodule.submodule.url ../moved-submodule
+ test_tick &&
+ git commit -a -m moved-submodule
+ )
+'
+
+test_expect_success '"git submodule sync" should update submodule URLs' '
+ (cd super-clone &&
+ git pull &&
+ test_tick &&
+ git submodule sync
+ ) &&
+ test_tick &&
+ test -d "$(git config -f super-clone/submodule/.git/config \
+ remote.origin.url)" &&
+ (cd super-clone/submodule &&
+ git checkout master &&
+ test_tick &&
+ git pull
+ )
+'
+
+test_done
--
1.6.0.2.428.g5e22e
^ permalink raw reply related
* Re: [PATCHv4] gitweb: parse project/action/hash_base:filename PATH_INFO
From: Jakub Narebski @ 2008-10-02 8:59 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Junio C Hamano, Shawn O. Pearce
In-Reply-To: <1222906234-8182-2-git-send-email-giuseppe.bilotta@gmail.com>
Giuseppe Bilotta wrote:
> This patch enables gitweb to parse URLs with more information embedded
> in PATH_INFO, reducing the need for CGI parameters. The typical gitweb
> path is now $project/$action/$hash_base:$file_name or
> $project/$action/$hash
>
> This is mostly backwards compatible with the old-style gitweb paths,
> except when $project/$branch was used to access a branch whose name
> matches a gitweb action.
Nice summary.
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
> ---
> gitweb/gitweb.perl | 90 +++++++++++++++++++++++++++++++---------------------
> 1 files changed, 54 insertions(+), 36 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index e7e4d6b..f088681 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -495,6 +495,37 @@ if (defined $searchtext) {
> $search_regexp = $search_use_regexp ? $searchtext : quotemeta $searchtext;
> }
>
> +# dispatch
> +my %actions = (
> + "blame" => \&git_blame,
[...]
> +);
I'm not sure if the '# dispatch' comment is correct here now that
%actions hash is moved away from actual dispatch (selecting action
to run)
> @@ -519,9 +550,19 @@ sub evaluate_path_info {
> # do not change any parameters if an action is given using the query string
> return if $action;
> $path_info =~ s,^\Q$project\E/*,,;
> +
> + # next comes the action
> + $action = $path_info;
> + $action =~ s,/.*$,,;
I would use here pattern matching, but your code is also good and
doesn't need changing; just for completeness below there is alternate
solution:
+ $path_info =~ m,^(.*?)/,;
+ $action = $1;
> + if (exists $actions{$action}) {
> + $path_info =~ s,^$action/*,,;
> + } else {
> + $action = undef;
> + }
> +
[...]
> @@ -534,8 +575,9 @@ sub evaluate_path_info {
> $file_name ||= validate_pathname($pathname);
> } elsif (defined $refname) {
> # we got "project.git/branch"
You meant here
# we got "project.git/branch" or "project.git/action/branch"
> - $action ||= "shortlog";
> - $hash ||= validate_refname($refname);
> + $action ||= "shortlog";
> + $hash ||= validate_refname($refname);
> + $hash_base ||= validate_refname($refname);
> }
> }
This hunk is IMHO incorrect. First, $refname is _either_ $hash, or
$hash_base; it cannot be both. Second, in most cases (like the case
of 'shortlog' action, either explicit or implicit) it is simply $hash;
I think it can be $hash_base when $file_name is not set only in
singular exception case of 'tree' view for the top tree (lack of
filename is not an error, but is equivalent to $file_name='/').
> @@ -544,37 +586,6 @@ evaluate_path_info();
> our $git_dir;
> $git_dir = "$projectroot/$project" if $project;
>
> -# dispatch
> -my %actions = (
[...]
> -);
> -
> if (!defined $action) {
> if (defined $hash) {
> $action = git_get_type($hash);
I _think_ the '# dispatch' comment should be left here, and not moved
with the %actions hash.
> @@ -631,8 +642,15 @@ sub href (%) {
> if ($params{-replay}) {
> while (my ($name, $symbol) = each %mapping) {
> if (!exists $params{$name}) {
> - # to allow for multivalued params we use arrayref form
> - $params{$name} = [ $cgi->param($symbol) ];
> + # the parameter we want to recycle may be either part of the
> + # list of CGI parameter, or recovered from PATH_INFO
> + if ($cgi->param($symbol)) {
> + # to allow for multivalued params we use arrayref form
> + $params{$name} = [ $cgi->param($symbol) ];
> + } else {
> + no strict 'refs';
> + $params{$name} = $$name if $$name;
I would _perhaps_ add here comment that multivalued parameters can come
only from CGI query string, so there is no need for something like:
+ $params{$name} = (ref($$name) ? @$name : $$name) if $$name;
> + }
> }
> }
> }
This fragment is a bit of ugly code, hopefully corrected in later patch.
I think it would be better to have 'refactor parsing/validation of input
parameters' to be very fist patch in series; I am not sure but I suspect
that is a kind of bugfix for current "$project/$hash" ('shortlog' view)
and "$project/$hash_base:$file_name" ('blob_plain' and 'tree' view)
path_info.
P.S. It is a bit of pity that Mechanize test from Lea Wiemann caching
gitweb code is not in the 'master' or at least 'pu'. Using big, single,
monolithic patch instead of patch series of small, easy reviewable
commits strikes again... ;-(
--
Jakub Narebski
Poland
^ permalink raw reply
* Git commit hash clash prevention
From: martin f krafft @ 2008-10-02 8:53 UTC (permalink / raw)
To: git discussion list
[-- Attachment #1: Type: text/plain, Size: 985 bytes --]
Hi folks,
the other day during a workshop on Git, one of the attendants asked
about the scenario when two developers, Jane and David, both working
on the same project, both create a commit and the two just so happen
to have the same SHA-1. I realise that the likelihood of this
happening is about as high as the chance of <insert witty joke
here>, but it *is* possible, isn't it? Even though this is thus
somewhat academic, I am still very curious about it.
What happens when David now pulls from Jane? How does Git deal with
this?
I imagine it'll be able to distinguish the two commits based on
metadata, but won't the DAG get corrupted?
Cheers,
--
martin | http://madduck.net/ | http://two.sentenc.es/
"and no one sings me lullabies,
and no one makes me close my eyes,
and so i throw the windows wide,
and call to you across the sky"
-- pink floyd, 1971
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* git svn bug?
From: Ark Xu @ 2008-10-02 8:50 UTC (permalink / raw)
To: git
Hi guys,
I like git very much so I also use git svn for subversion repo.
Now I got a tough problem which stopping me for any svn related
operations. There is a file log4j.xml that is somehow strange because
when I fetch it, i got the following message:
tms-service/src/test/resources/log4j.xml has mode 120000 but is not a
link at /opt/local/bin/git-svn line 3230.
M tms-service/src/test/resources/log4j.xml
And then, all the operation will lead to :
Checksum mismatch: branches/5.3/tms-service/src/test/resources/
log4j.xml 51031cbb0e1a2e878e4a3836cf0baa9b80a037a5
expected: fab6daef9fc355b9342e26047f5d0141
got: 0e7e9081d608c80d2de0340ba5cd1600
Could anybody help?
regards,
Ark
^ permalink raw reply
* Re: [PATCHv4] gitweb: PATH_INFO support improvements
From: Giuseppe Bilotta @ 2008-10-02 8:49 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Petr Baudis, Junio C Hamano, Shawn O. Pearce
In-Reply-To: <200810021019.27383.jnareb@gmail.com>
On Thu, Oct 2, 2008 at 10:19 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> Giuseppe Bilotta wrote:
>
>> Fourth version of my gitweb PATH_INFO patchset, whose purpose is to
>> reduce the use of CGI parameters by embedding as many parameters as
>> possible in the URL path itself, provided the pathinfo feature is
>> enabled.
>
> A nit: when sending longer patch series you should use numbered
> format in the form of [PATCH m/n] or [PATCH m/n vX] prefix.
W00t, I still manage to get this wrong. Kudos to me 8-/
I wonder why these options are not the default when there is more than
one patch, btw?
(And yes, I tried looking into the builtin-log.c code but making it
automatic is somewhat less trivial than I can dedicate time to.)
>> The new typical gitweb URL is therefore in the form
>>
>> $project/$action/$parent:$file..$hash:$file
>>
>> (with useless parts stripped). Backwards compatibility for old-style
>> $project/$hash URLs is kept, as long as $hash is not a refname whose
>> name happens to match a git action.
>
> Minor nit: there was also old-style $project/$hash_base:$file_name
> path_info format.
Right, forgot about that.
>> The main implementation is provided by paired patches (#1#3, #5#6)
>> that implement parsing and generation of the new style URLs.
>>
>> Patch #2 deals with a refactoring of the input parameters parsing and
>> validation, so that the rest of gitweb can be agnostic wrt to the
>> parameters' origin (CGI vs PATH_INFO vs possible other future inputs
>> such as CLI).
>>
>> Patch #4 is a minor improvement to the URL syntax that allows web
>> documents to be properly browsable in raw mode.
>
> Very nice summary of patchset and patch coverage in this cover letter.
Thanks. At least I'm learning from my past errors. I'll manage to send
the perfect patchset sooner or later ;)
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [PATCH] git commit: Repaint the output format bikeshed (again)
From: Wincent Colaiuta @ 2008-10-02 8:36 UTC (permalink / raw)
To: Jeff King; +Cc: Andreas Ericsson, Shawn Pearce, Git Mailing List
In-Reply-To: <20081001220604.GB18058@coredump.intra.peff.net>
El 2/10/2008, a las 0:06, Jeff King escribió:
> better. But in the interests of just agreeing on something, I am
> willing
> to accept this. FWIW, the git-reset command doesn't use any delimiter
> for the message:
>
> <branch> is now at <hash> <subject>
>
> So perhaps they should be the same. I don't think it overly matters.
If you're wanting to trim horizontal fat then the "is" isn't really
required.
<branch> now at <hash> <subject>
Reads just as well.
Cheers,
Wincent
^ permalink raw reply
* [PATCH] tests: add a testcase for "git submodule sync"
From: David Aguilar @ 2008-10-02 8:29 UTC (permalink / raw)
To: spearce; +Cc: git, mlevedahl, gitster, David Aguilar
This testcase ensures that upstream changes to submodule properties
can be updated using the sync subcommand. This particular test
changes the submodule URL upstream and uses the sync command to update
an existing checkout.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
t/t7403-submodule-sync.sh | 71 +++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 71 insertions(+), 0 deletions(-)
diff --git a/t/t7403-submodule-sync.sh b/t/t7403-submodule-sync.sh
new file mode 100755
index 0000000..c034c9e
--- /dev/null
+++ b/t/t7403-submodule-sync.sh
@@ -0,0 +1,71 @@
+#!/bin/sh
+#
+# Copyright (c) 2008 David Aguilar
+#
+
+test_description='git submodule sync
+
+These tests exercise the "git submodule sync" subcommand.
+'
+
+. ./test-lib.sh
+
+test_expect_success setup '
+ mkdir upstream &&
+ (cd upstream &&
+ git init &&
+ echo file > file &&
+ git add file &&
+ test_tick &&
+ git commit -m upstream
+ ) &&
+ git clone upstream super &&
+ git clone super submodule &&
+ (cd super &&
+ git submodule add ../submodule submodule &&
+ git commit -m "submodule"
+ ) &&
+ git clone super super-clone &&
+ (cd super-clone && git submodule update --init)
+'
+
+test_expect_success 'change submodule' '
+ (cd submodule &&
+ echo second line >> file &&
+ test_tick &&
+ git commit -a -m "change submodule"
+ )
+'
+
+test_expect_success 'change submodule url' '
+ (cd super &&
+ cd submodule &&
+ git checkout master &&
+ test_tick &&
+ git pull
+ ) &&
+ mv submodule moved-submodule &&
+ (cd super &&
+ git config -f .gitmodules submodule.submodule.url ../moved-submodule
+ test_tick &&
+ git commit -a -m moved-submodule
+ )
+'
+
+test_expect_success '"git submodule sync" should update submodule URLs' '
+ (cd super-clone &&
+ git pull &&
+ test_tick &&
+ git submodule sync
+ ) &&
+ test_tick &&
+ test -d "$(git config -f super-clone/submodule/.git/config \
+ remote.origin.url)" &&
+ (cd super-clone/submodule &&
+ git checkout master &&
+ test_tick &&
+ git pull
+ )
+'
+
+test_done
--
1.6.0.2.428.g5e22e
^ permalink raw reply related
* Re: [PATCHv4] gitweb: PATH_INFO support improvements
From: Jakub Narebski @ 2008-10-02 8:19 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Junio C Hamano, Shawn O. Pearce
In-Reply-To: <1222906234-8182-1-git-send-email-giuseppe.bilotta@gmail.com>
Giuseppe Bilotta wrote:
> Fourth version of my gitweb PATH_INFO patchset, whose purpose is to
> reduce the use of CGI parameters by embedding as many parameters as
> possible in the URL path itself, provided the pathinfo feature is
> enabled.
A nit: when sending longer patch series you should use numbered
format in the form of [PATCH m/n] or [PATCH m/n vX] prefix.
>
> The new typical gitweb URL is therefore in the form
>
> $project/$action/$parent:$file..$hash:$file
>
> (with useless parts stripped). Backwards compatibility for old-style
> $project/$hash URLs is kept, as long as $hash is not a refname whose
> name happens to match a git action.
Minor nit: there was also old-style $project/$hash_base:$file_name
path_info format.
>
> The main implementation is provided by paired patches (#1#3, #5#6)
> that implement parsing and generation of the new style URLs.
>
> Patch #2 deals with a refactoring of the input parameters parsing and
> validation, so that the rest of gitweb can be agnostic wrt to the
> parameters' origin (CGI vs PATH_INFO vs possible other future inputs
> such as CLI).
>
> Patch #4 is a minor improvement to the URL syntax that allows web
> documents to be properly browsable in raw mode.
Very nice summary of patchset and patch coverage in this cover letter.
>
> Giuseppe Bilotta (6):
> gitweb: parse project/action/hash_base:filename PATH_INFO
> gitweb: refactor input parameters parse/validation
> gitweb: generate project/action/hash URLs
> gitweb: use_pathinfo filenames start with /
> gitweb: parse parent..current syntax from pathinfo
> gitweb: generate parent..current URLs
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] git commit: Repaint the output format bikeshed (again)
From: Andreas Ericsson @ 2008-10-02 5:40 UTC (permalink / raw)
To: Jeff King; +Cc: Shawn Pearce, Git Mailing List
In-Reply-To: <20081001223125.GA25267@coredump.intra.peff.net>
Jeff King wrote:
> On Wed, Oct 01, 2008 at 06:06:04PM -0400, Jeff King wrote:
>
>> I think I still like your other proposal:
>>
>> [branch] created b930c4a: "i386: Snib the sprock"
>
> And here is the patch, since it was sitting uncommitted in my working
> tree. Feel free to ignore.
>
> BTW, we should apply _something_ since what is currently in next has a
> bug: it lacks a space between "DETACHED commit" and the hash:
>
> Created DETACHED commit4fde0d0 (subject line)
>
> -- >8 --
> reformat informational commit message
>
> When committing, we print a message like:
>
> Created [DETACHED commit] <hash> (<subject>) on <branch>
>
> The most useful bit of information there (besides the
> detached status, if it is present) is which branch you made
> the commit on. However, it is sometimes hard to see because
> the subject dominates the line.
>
> Instead, let's put the most useful information (detached
> status and commit branch) on the far left, with the subject
> (which is least likely to be interesting) on the far right.
>
> We'll use brackets to offset the branch name so the line is
> not mistaken for an error line of the form "program: some
> sort of error". E.g.,:
>
> [jk/bikeshed] created bd8098f: "reformat informational commit message"
> ---
No sign-off.
> builtin-commit.c | 37 ++++++++++---------------------------
> 1 files changed, 10 insertions(+), 27 deletions(-)
>
> diff --git a/builtin-commit.c b/builtin-commit.c
> index e4e1448..7a66e5a 100644
> --- a/builtin-commit.c
> +++ b/builtin-commit.c
> @@ -878,35 +878,13 @@ int cmd_status(int argc, const char **argv, const char *prefix)
> return commitable ? 0 : 1;
> }
>
> -static char *get_commit_format_string(void)
> -{
> - unsigned char sha[20];
> - const char *head = resolve_ref("HEAD", sha, 0, NULL);
> - struct strbuf buf = STRBUF_INIT;
> -
> - /* use shouty-caps if we're on detached HEAD */
> - strbuf_addf(&buf, "format:%s", strcmp("HEAD", head) ? "" : "DETACHED commit");
> - strbuf_addstr(&buf, "%h (%s)");
> -
> - if (!prefixcmp(head, "refs/heads/")) {
> - const char *cp;
> - strbuf_addstr(&buf, " on ");
> - for (cp = head + 11; *cp; cp++) {
> - if (*cp == '%')
> - strbuf_addstr(&buf, "%x25");
> - else
> - strbuf_addch(&buf, *cp);
> - }
> - }
> -
> - return strbuf_detach(&buf, NULL);
> -}
> -
> static void print_summary(const char *prefix, const unsigned char *sha1)
> {
> struct rev_info rev;
> struct commit *commit;
> - char *format = get_commit_format_string();
> + static const char *format = "format:%h: \"%s\"";
> + unsigned char junk_sha1[20];
> + const char *head = resolve_ref("HEAD", junk_sha1, 0, NULL);
>
> commit = lookup_commit(sha1);
> if (!commit)
> @@ -931,7 +909,13 @@ static void print_summary(const char *prefix, const unsigned char *sha1)
> rev.diffopt.break_opt = 0;
> diff_setup_done(&rev.diffopt);
>
> - printf("Created %s", initial_commit ? "root-commit " : "");
> + printf("[%s%s]: created ",
> + !prefixcmp(head, "refs/heads/") ?
> + head + 11 :
> + !strcmp(head, "HEAD") ?
> + "detached HEAD" :
> + head,
> + initial_commit ? " (root-commit)" : "");
>
Personally, I'm not overly fond of things like
something ? yay : nay_but_try ? worked_now : still_no_go
since I find them hard to read without thinking a lot.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Help with a tcl/tk gui thing..
From: Mikael Magnusson @ 2008-10-02 5:18 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0810011605001.3341@nehalem.linux-foundation.org>
2008/10/2 Linus Torvalds <torvalds@linux-foundation.org>:
>
>
> On Wed, 1 Oct 2008, Mikael Magnusson wrote:
>>
>> git clone git://mika.l3ib.org/tracker.git
>>
>> I wrote it in pygtk since I know zero to no tcl/tk, hope that's okay.
>> It has a label with the time remaining (simply read from the daemon file),
>> and shows the text in red if less than 10% is remaining. You'll need to
>> change the ./ in cb_function to /var/log/tracker since I forgot to change
>> that and I'm lazy :).
>
> Well, it doesn't do anything at all for me except change the cursor to a
> cross, and if I'm a n00b with tcl/tk, I'm even more of one with pygtk.
>
> I merged the two other suggestions, though. And am open to seeing that
> pygtk thing too as an alternative, but only if it actually works for me ;)
Heh, sorry, I'm an idiot. I forgot to put '#!/usr/bin/python' on the first
line. I was running 'python tracker-ui.py' then did chmod +x just before
committing :). So the cross is coming from running 'import time'.
--
Mikael Magnusson
^ permalink raw reply
* Re: [PATCH] Solaris: Use OLD_ICONV to avoid compile warnings
From: Jeff King @ 2008-10-02 1:08 UTC (permalink / raw)
To: David Soria Parra; +Cc: git, David Soria Parra
In-Reply-To: <1222906127-16900-1-git-send-email-sn_@gmx.net>
On Thu, Oct 02, 2008 at 02:08:47AM +0200, David Soria Parra wrote:
> Solaris systems use the old styled iconv(3) call and therefore
> the OLD_ICONV variable should be set. Otherwise we get annoying compile
> warnings.
Acked-by: Jeff King <peff@peff.net>
I set OLD_ICONV on my Solaris build.
Do you also unset NEEDS_LIBICONV (and which version of Solaris are you
running)? Our Makefile sets it to "yes" for Solaris 8, but my build box
requires that it be unset. I'm not sure if my setup is somehow
deficient, or if it is only other versions that need it.
-Peff
^ permalink raw reply
* [PATCHv4] gitweb: generate parent..current URLs
From: Giuseppe Bilotta @ 2008-10-02 0:10 UTC (permalink / raw)
To: git
Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Shawn O. Pearce,
Giuseppe Bilotta
In-Reply-To: <1222906234-8182-6-git-send-email-giuseppe.bilotta@gmail.com>
If use_pathinfo is enabled, href now creates links that contain paths in
the form $project/$action/oldhash:/oldname..newhash:/newname for actions
that use hash_parent etc.
If any of the filename contains two consecutive dots, it's kept as a CGI
parameter since the resulting path would otherwise be ambiguous.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 30 +++++++++++++++++++++++++-----
1 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 89e360f..d863ef7 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -712,7 +712,8 @@ sub href (%) {
# try to put as many parameters as possible in PATH_INFO:
# - project name
# - action
- # - hash or hash_base:/filename
+ # - hash_parent or hash_parent_base:/file_parent
+ # - hash or hash_base:/file_name
# Strip any trailing / from $href, or we might get double
# slashes when the script is the DirectoryIndex
@@ -730,17 +731,36 @@ sub href (%) {
delete $params{'action'};
}
- # Finally, we put either hash_base:/file_name or hash
+ # Next, we put hash_parent_base:/file_parent..hash_base:/file_name,
+ # stripping nonexistent or useless pieces
+ $href .= "/" if ($params{'hash_base'} || $params{'hash_parent_base'}
+ || $params{'hash_parent'} || $params{'hash'});
if (defined $params{'hash_base'}) {
- $href .= "/".esc_url($params{'hash_base'});
- if (defined $params{'file_name'}) {
+ if (defined $params{'hash_parent_base'}) {
+ $href .= esc_url($params{'hash_parent_base'});
+ # skip the file_parent if it's the same as the file_name
+ delete $params{'file_parent'} if $params{'file_parent'} eq $params{'file_name'};
+ if (defined $params{'file_parent'} && $params{'file_parent'} !~ /\.\./) {
+ $href .= ":/".esc_url($params{'file_parent'});
+ delete $params{'file_parent'};
+ }
+ $href .= "..";
+ delete $params{'hash_parent'};
+ delete $params{'hash_parent_base'};
+ } elsif (defined $params{'hash_parent'}) {
+ $href .= esc_url($params{'hash_parent'}). "..";
+ delete $params{'hash_parent'};
+ }
+
+ $href .= esc_url($params{'hash_base'});
+ if (defined $params{'file_name'} && $params{'file_name'} !~ /\.\./) {
$href .= ":/".esc_url($params{'file_name'});
delete $params{'file_name'};
}
delete $params{'hash'};
delete $params{'hash_base'};
} elsif (defined $params{'hash'}) {
- $href .= "/".esc_url($params{'hash'});
+ $href .= esc_url($params{'hash'});
delete $params{'hash'};
}
}
--
1.5.6.5
^ permalink raw reply related
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