* Re: New web frontend: gitarella
From: Marco Costalba @ 2006-06-25 10:49 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, flameeyes
In-Reply-To: <Pine.LNX.4.63.0606251211490.29667@wbgn013.biozentrum.uni-wuerzburg.de>
On 6/25/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> just to inform you I saw gitarella announced on freshmeat. It is inspired
> by gitweb, but written in Ruby.
>
It's amazing to see in how many different ways a lot of people try to
find an (almost the same) solution for (almost) the same problem. IMHO
this is one of the main differences between developing for fun and as
a day job.
Welcome abroad gitarella.
Marco
P.S: BTW gitarella, pronounced with the 'gi' like in 'giant' it means
"little trip" in Italian.
^ permalink raw reply
* [PATCH] Add msg_sep to diff_options
From: Timo Hirvonen @ 2006-06-25 10:54 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: junkio, git
In-Reply-To: <20060624202153.1001a66c.tihirvon@gmail.com>
Add msg_sep variable to struct diff_options. msg_sep is printed after
commit message. Default is "\n", format-patch sets it to "---\n".
This also removes the second argument from show_log() because all
callers derived it from the first argument:
show_log(rev, rev->loginfo, ...
Signed-off-by: Timo Hirvonen <tihirvon@gmail.com>
---
I'm not 100% sure if format-patch is the only one wanting "---\n".
But I think "\n" should be used for every command that doesn't create
patches.
builtin-log.c | 1 +
combine-diff.c | 7 ++++---
diff.c | 1 +
diff.h | 1 +
log-tree.c | 15 ++++++---------
log-tree.h | 2 +-
6 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/builtin-log.c b/builtin-log.c
index f173070..5b3fadc 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -175,6 +175,7 @@ int cmd_format_patch(int argc, const cha
rev.diff = 1;
rev.combine_merges = 0;
rev.ignore_merges = 1;
+ rev.diffopt.msg_sep = "---\n";
git_config(git_format_config);
rev.extra_headers = extra_headers;
diff --git a/combine-diff.c b/combine-diff.c
index 3daa8cb..39fb10c 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -701,7 +701,7 @@ static int show_patch_diff(struct combin
const char *abb;
if (rev->loginfo)
- show_log(rev, rev->loginfo, "\n");
+ show_log(rev, opt->msg_sep);
dump_quoted_path(dense ? "diff --cc " : "diff --combined ", elem->path);
printf("index ");
for (i = 0; i < num_parent; i++) {
@@ -769,7 +769,7 @@ static void show_raw_diff(struct combine
inter_name_termination = 0;
if (rev->loginfo)
- show_log(rev, rev->loginfo, "\n");
+ show_log(rev, opt->msg_sep);
if (opt->output_format & DIFF_FORMAT_RAW) {
offset = strlen(COLONS) - num_parent;
@@ -855,7 +855,8 @@ void diff_tree_combined(const unsigned c
paths = intersect_paths(paths, i, num_parent);
if (opt->output_format & DIFF_FORMAT_DIFFSTAT && rev->loginfo)
- show_log(rev, rev->loginfo, "---\n");
+ show_log(rev, opt->msg_sep);
+
diff_flush(&diffopts);
if (opt->output_format & DIFF_FORMAT_DIFFSTAT)
putchar('\n');
diff --git a/diff.c b/diff.c
index 4b1b4eb..cc2af30 100644
--- a/diff.c
+++ b/diff.c
@@ -1359,6 +1359,7 @@ void diff_setup(struct diff_options *opt
options->break_opt = -1;
options->rename_limit = -1;
options->context = 3;
+ options->msg_sep = "\n";
options->change = diff_change;
options->add_remove = diff_addremove;
diff --git a/diff.h b/diff.h
index 2b6dc0c..729cd02 100644
--- a/diff.h
+++ b/diff.h
@@ -57,6 +57,7 @@ struct diff_options {
int rename_limit;
int setup;
int abbrev;
+ const char *msg_sep;
const char *stat_sep;
long xdl_opts;
diff --git a/log-tree.c b/log-tree.c
index 7d4c51f..ab6b682 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -43,9 +43,10 @@ static int append_signoff(char *buf, int
return at;
}
-void show_log(struct rev_info *opt, struct log_info *log, const char *sep)
+void show_log(struct rev_info *opt, const char *sep)
{
static char this_header[16384];
+ struct log_info *log = opt->loginfo;
struct commit *commit = log->commit, *parent = log->parent;
int abbrev = opt->diffopt.abbrev;
int abbrev_commit = opt->abbrev_commit ? opt->abbrev : 40;
@@ -163,13 +164,9 @@ int log_tree_diff_flush(struct rev_info
return 0;
}
- if (opt->loginfo && !opt->no_commit_id) {
- if (opt->diffopt.output_format & DIFF_FORMAT_DIFFSTAT) {
- show_log(opt, opt->loginfo, "---\n");
- } else {
- show_log(opt, opt->loginfo, "\n");
- }
- }
+ if (opt->loginfo && !opt->no_commit_id)
+ show_log(opt, opt->diffopt.msg_sep);
+
diff_flush(&opt->diffopt);
return 1;
}
@@ -266,7 +263,7 @@ int log_tree_commit(struct rev_info *opt
shown = log_tree_diff(opt, commit, &log);
if (!shown && opt->loginfo && opt->always_show_header) {
log.parent = NULL;
- show_log(opt, opt->loginfo, "");
+ show_log(opt, "");
shown = 1;
}
opt->loginfo = NULL;
diff --git a/log-tree.h b/log-tree.h
index a26e484..e82b56a 100644
--- a/log-tree.h
+++ b/log-tree.h
@@ -11,6 +11,6 @@ void init_log_tree_opt(struct rev_info *
int log_tree_diff_flush(struct rev_info *);
int log_tree_commit(struct rev_info *, struct commit *);
int log_tree_opt_parse(struct rev_info *, const char **, int);
-void show_log(struct rev_info *opt, struct log_info *log, const char *sep);
+void show_log(struct rev_info *opt, const char *sep);
#endif
--
1.4.1.rc1.g35ee-dirty
^ permalink raw reply related
* [RFC] git --trace: trace command execution
From: Matthias Lederhofer @ 2006-06-25 10:57 UTC (permalink / raw)
To: git
Show parameters to execve/builtin-cmds before executing them. This
version does not yet have a parameter --trace to git to enable this I
just want to get feedback first :)
I think this is quite useful to debug what is going on since a command
may be another program (shell/python/perl/.. script etc) or just an
alias for a internal command. Before that many commands became
built-ins this was quite easy to do with strace.
Example:
% git repo-config alias.showtag
trace: exec: /home/matled/local/stow/git/bin/git-repo-config
alias.showtag
% git showtag v1.4.1-rc1 > /dev/null
trace: exec: /home/matled/local/stow/git/bin/git-showtag v1.4.1-rc1
trace: exec failed: No such file or directory
trace: built-in command: git cat-file tag v1.4.1-rc1
% git showtag 'a b "c" `d` $e \f'
trace: exec: /home/matled/local/stow/git/bin/git-showtag "a b \"c\" \`d\` \$e \\f"
trace: exec failed: No such file or directory
trace: built-in command: git cat-file tag "a b \"c\" \`d\` \$e \\f"
fatal: Not a valid object name a b "c" `d` $e \f
% git cat-file tag "a b \"c\" \`d\` \$e \\f"
trace: built-in command: git cat-file tag "a b \"c\" \`d\` \$e \\f"
fatal: Not a valid object name a b "c" `d` $e \f
print_shell_escape will escape the arguments to be used as strings in
the shell to prevent ambiguity with spaces and other special
characters and make them copy-and-pastable.
---
exec_cmd.c | 42 ++++++++++++++++++++++++++++++++++++++++++
exec_cmd.h | 1 +
git.c | 10 ++++++++++
3 files changed, 53 insertions(+), 0 deletions(-)
diff --git a/exec_cmd.c b/exec_cmd.c
index c1539d1..85afbf3 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -87,6 +87,16 @@ int execv_git_cmd(const char **argv)
break;
}
+ fprintf(stderr, "trace: exec: ");
+ print_shell_escape(stderr, git_command);
+ const char **p = argv;
+ while (*(++p)) {
+ putc(' ', stderr);
+ print_shell_escape(stderr, *p);
+ }
+ putc('\n', stderr);
+ fflush(stderr);
+
/* argv[0] must be the git command, but the argv array
* belongs to the caller, and my be reused in
* subsequent loop iterations. Save argv[0] and
@@ -98,6 +108,8 @@ int execv_git_cmd(const char **argv)
/* execve() can only ever return if it fails */
execve(git_command, (char **)argv, environ);
+ fprintf(stderr, "trace: exec failed: %s\n", strerror(errno));
+ fflush(stderr);
argv[0] = tmp;
}
@@ -128,3 +140,33 @@ int execl_git_cmd(const char *cmd,...)
argv[argc] = NULL;
return execv_git_cmd(argv);
}
+
+void print_shell_escape(FILE *stream, const char *s)
+{
+ const char *c = s;
+ short int quote = 0;
+ while (*c) {
+ if (*c == '"' || *c == '`' || *c == '$' || *c == '\\' ||
+ isspace(*c))
+ {
+ quote = 1;
+ break;
+ }
+ ++c;
+ }
+
+ if (!quote) {
+ fputs(s, stream);
+ return;
+ }
+
+ putc('"', stream);
+ c = s;
+ while (*c) {
+ if (*c == '"' || *c == '`' || *c == '$' || *c == '\\')
+ putc('\\', stream);
+ putc(*c, stream);
+ ++c;
+ }
+ putc('"', stream);
+}
diff --git a/exec_cmd.h b/exec_cmd.h
index 989621f..8b237fa 100644
--- a/exec_cmd.h
+++ b/exec_cmd.h
@@ -5,6 +5,7 @@ extern void git_set_exec_path(const char
extern const char* git_exec_path(void);
extern int execv_git_cmd(const char **argv); /* NULL terminated */
extern int execl_git_cmd(const char *cmd, ...);
+extern void print_shell_escape(FILE *stream, const char *s);
#endif /* __GIT_EXEC_CMD_H_ */
diff --git a/git.c b/git.c
index 94e9a4a..361fb25 100644
--- a/git.c
+++ b/git.c
@@ -198,6 +198,16 @@ static void handle_internal_command(int
struct cmd_struct *p = commands+i;
if (strcmp(p->cmd, cmd))
continue;
+
+ fprintf(stderr, "trace: built-in command: git");
+ int i;
+ for (i = 0; i < argc; ++i) {
+ putc(' ', stderr);
+ print_shell_escape(stderr, argv[i]);
+ }
+ putc('\n', stderr);
+ fflush(stderr);
+
exit(p->fn(argc, argv, envp));
}
}
--
1.4.GIT
^ permalink raw reply related
* Re: [RFC] GIT user survey
From: Junio C Hamano @ 2006-06-25 11:06 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: git
In-Reply-To: <4d8e3fd30606250347o47c4b200t6feb0406bfa535fa@mail.gmail.com>
"Paolo Ciarrocchi" <paolo.ciarrocchi@gmail.com> writes:
> About you
>
> 1. What country are you in?
> 2. What is your preferred language?
> 3. What's your gender?
Demography is interesting and quite relevant to understand the
bias in the answers to the rest of the questions, although I do
not see much point about #3. Question #2 is relevant in i18n,
of course.
I would also ask if the respondent has her own patch in the
git.git repository. If most of them are git developers, the
answer to the question "was git easy to learn" becomes
suspicious, for example.
> Getting started with GIT
>
> 1. How did you hear about GIT?
> 2. Did you find GIT easy to learn?
> 3. What helped you most in learning to use it?
Also "When did you start using git?" -- old timers who learned
git when it was still young and small would have had an easier
time to learn it.
> How you use GIT
>
> 1. Do you use GIT for work, unpaid projects, or both?
> 2. How do you obtain GIT? Source tarball, binary package, or
> pull the main repository?
> 3. What platforms (hardware, OS, version) do you use GIT on?
> 4. How many people do you collaborate with using GIT?
> 5. How big are the repositories that you work on? (e.g. how many
> files, how much disk space)
> 6. How many different projects do you manage using GIT?
> 7. Which porcelains do you use?
After seeing the Mercurial survey result, I think question #3
should be stated a bit more concretely. The results having
mixture of i386 and Linux are not very interesting. I would
also add "how deep the history" to #5.
> Getting help, staying in touch
>
> 1. Have you tried to get GIT help from other people?
> * If yes, did you get these problems resolved quickly and to
> your liking?
> 2. Do you subscribe to the mailing list?
> * If yes, do you find it useful, and traffic levels OK?
> 3. Do you use the IRC channel (#git on irc.freenode.net)?
> * If no, did you know that all of the core developers use
> IRC, and that there's almost 24-hour help available?
About #3, I do not see some people I consider "core" often on
the IRC. Maybe "most of the core".
^ permalink raw reply
* [PATCH] whatchanged: Default to DIFF_FORMAT_RAW
From: Timo Hirvonen @ 2006-06-25 11:11 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: junkio, git
In-Reply-To: <20060624202153.1001a66c.tihirvon@gmail.com>
Signed-off-by: Timo Hirvonen <tihirvon@gmail.com>
---
builtin-log.c | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/builtin-log.c b/builtin-log.c
index 5b3fadc..8a39770 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -28,6 +28,15 @@ static int cmd_log_wc(int argc, const ch
rev->always_show_header = 0;
}
+ if (!rev->diffopt.output_format && !rev->simplify_history) {
+ /* Ugly hack!
+ *
+ * rev->simplify_history == 0 -> whatchanged
+ * Can't do this before setup_revisions()
+ */
+ rev->diffopt.output_format = DIFF_FORMAT_RAW;
+ }
+
if (argc > 1)
die("unrecognized argument: %s", argv[1]);
--
1.4.1.rc1.g6e272-dirty
^ permalink raw reply related
* Re: [PATCH 0/7] Rework diff options
From: Timo Hirvonen @ 2006-06-25 11:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes.Schindelin
In-Reply-To: <7vslltopzg.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Here are a few problems I have seen:
>
> - "git show --stat HEAD" gives '---' marker as Johannes and you
> have already discussed (I do not mind this that much though);
The patch I sent as a reply to 2/7 should fix this.
> - "--cc" seems to be quite broken. "git show v1.0.0" nor "git
> diff-tree --pretty --cc v1.0.0" does not give the log
> message, and gives something quite confused instead. I think
> it is showing "-m -p" followed by "--cc".
Sorry about that. I don't understand the --cc stuff very well but I try
to fix the bug.
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* [PATCH] Don't xcalloc() struct diffstat_t
From: Timo Hirvonen @ 2006-06-25 11:28 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: junkio, git
In-Reply-To: <20060624202153.1001a66c.tihirvon@gmail.com>
Signed-off-by: Timo Hirvonen <tihirvon@gmail.com>
---
diff.c | 11 +++++------
1 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/diff.c b/diff.c
index cc2af30..8880150 100644
--- a/diff.c
+++ b/diff.c
@@ -2062,17 +2062,16 @@ void diff_flush(struct diff_options *opt
}
if (output_format & DIFF_FORMAT_DIFFSTAT) {
- struct diffstat_t *diffstat;
+ struct diffstat_t diffstat;
- diffstat = xcalloc(sizeof (struct diffstat_t), 1);
- diffstat->xm.consume = diffstat_consume;
+ memset(&diffstat, 0, sizeof(struct diffstat_t));
+ diffstat.xm.consume = diffstat_consume;
for (i = 0; i < q->nr; i++) {
struct diff_filepair *p = q->queue[i];
if (check_pair_status(p))
- diff_flush_stat(p, options, diffstat);
+ diff_flush_stat(p, options, &diffstat);
}
- show_stats(diffstat);
- free(diffstat);
+ show_stats(&diffstat);
}
if (output_format & DIFF_FORMAT_SUMMARY) {
--
1.4.1.rc1.g5472-dirty
^ permalink raw reply related
* git-repack -a -d produces unusable packs with 1.4.0
From: Thomas Glanzmann @ 2006-06-25 11:35 UTC (permalink / raw)
To: GIT
Hello everyone,
what on earth is going wrong here (this is with 1.4.0):
(node01) [~] git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Checking files out...)
100% (19830/19830) done
(node01) [~] cd linux-2.6/
(node01) [~/linux-2.6] git repack -a -d
Generating pack...
Done counting 263175 objects.
Deltifying 263175 objects.
100% (263175/263175) done
Writing 263175 objects.
100% (263175/263175) done
Total 263175, written 263175 (delta 206825), reused 262943 (delta 206593)
Pack pack-ce49d2efd5af06ed6093049050b5ba41da8b683f created.
mv: overwrite `.git/objects/pack/pack-ce49d2efd5af06ed6093049050b5ba41da8b683f.pack', overriding mode 0444? y
mv: overwrite `.git/objects/pack/pack-ce49d2efd5af06ed6093049050b5ba41da8b683f.idx', overriding mode 0444? y
fatal: packfile .git/objects/pack/pack-ce49d2efd5af06ed6093049050b5ba41da8b683f.pack does not match index.
(node01) [~/linux-2.6] git repack -a -d
Generating pack...
fatal: expected sha1, got garbage:
fatal: packfile .git/objects/pack/pack-ce49d2efd5af06ed6093049050b5ba41da8b683f.pack does not match index.
Oh and are there localized git mirrors like for example
git.de.kernel.org or is the git protocoll only available from the
primary site?
Thomas
^ permalink raw reply
* Re: [PATCH] Add msg_sep to diff_options
From: Junio C Hamano @ 2006-06-25 11:40 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: git
In-Reply-To: <20060625135414.425580d1.tihirvon@gmail.com>
Timo Hirvonen <tihirvon@gmail.com> writes:
> Add msg_sep variable to struct diff_options. msg_sep is printed after
> commit message. Default is "\n", format-patch sets it to "---\n".
>
> This also removes the second argument from show_log() because all
> callers derived it from the first argument:
>
> show_log(rev, rev->loginfo, ...
Good catch. Thanks.
> Signed-off-by: Timo Hirvonen <tihirvon@gmail.com>
> ---
I often wonder if the separator should be "\n---\n" instead when
I see something like the above, but do not change it yet please.
> I'm not 100% sure if format-patch is the only one wanting "---\n".
git log --patch-with-stat should also show "---\n".
> But I think "\n" should be used for every command that doesn't create
> patches.
This sounds good.
We probably would want to have an output format testsuite to
catch regression.
^ permalink raw reply
* Re: [RFC] git --trace: trace command execution
From: Junio C Hamano @ 2006-06-25 11:50 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: git
In-Reply-To: <E1FuSIf-0004jK-Tp@moooo.ath.cx>
Matthias Lederhofer <matled@gmx.net> writes:
> Show parameters to execve/builtin-cmds before executing them. This
> version does not yet have a parameter --trace to git to enable this I
> just want to get feedback first :)
>
> I think this is quite useful to debug what is going on since a command
> may be another program (shell/python/perl/.. script etc) or just an
> alias for a internal command. Before that many commands became
> built-ins this was quite easy to do with strace.
Interesting. Debugging one's alias entries would be helped with
this I would imagine, and for that you would want something like
this:
> Example:
> % git showtag v1.4.1-rc1 > /dev/null
> trace: exec: /home/matled/local/stow/git/bin/git-showtag v1.4.1-rc1
> trace: exec failed: No such file or directory
* trace: expanded alias "showtag" => "cat-file tag"
> trace: built-in command: git cat-file tag v1.4.1-rc1
By the way "git cat-file -p" or "git verify-tag -v" might be
more pleasant to view a tag since they make the tagger timestamp
human readable.
> print_shell_escape will escape the arguments to be used as strings in
> the shell to prevent ambiguity with spaces and other special
> characters and make them copy-and-pastable.
Might be worth reusing quote.c::sq_quote(), perhaps?
^ permalink raw reply
* Re: [PATCH] whatchanged: Default to DIFF_FORMAT_RAW
From: Junio C Hamano @ 2006-06-25 11:55 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: git
In-Reply-To: <20060625141102.b68a7cae.tihirvon@gmail.com>
Timo Hirvonen <tihirvon@gmail.com> writes:
> Signed-off-by: Timo Hirvonen <tihirvon@gmail.com>
> ---
> builtin-log.c | 9 +++++++++
> 1 files changed, 9 insertions(+), 0 deletions(-)
>
> diff --git a/builtin-log.c b/builtin-log.c
> index 5b3fadc..8a39770 100644
> --- a/builtin-log.c
> +++ b/builtin-log.c
> @@ -28,6 +28,15 @@ static int cmd_log_wc(int argc, const ch
> rev->always_show_header = 0;
> }
>
> + if (!rev->diffopt.output_format && !rev->simplify_history) {
> + /* Ugly hack!
> + *
> + * rev->simplify_history == 0 -> whatchanged
> + * Can't do this before setup_revisions()
> + */
Indeed it is ugly. Might it be a cleaner option to signal _wc
function what command its caller is, by adding an extra
parameter (or check argv -- ugh)?
^ permalink raw reply
* Re: git-repack -a -d produces unusable packs with 1.4.0
From: Junio C Hamano @ 2006-06-25 12:23 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: git
In-Reply-To: <20060625113522.GC19210@cip.informatik.uni-erlangen.de>
Thomas Glanzmann <sithglan@stud.uni-erlangen.de> writes:
> Pack pack-ce49d2efd5af06ed6093049050b5ba41da8b683f created.
> mv: overwrite `.git/objects/pack/pack-ce49d2efd5af06ed6093049050b5ba41da8b683f.pack', overriding mode 0444? y
> mv: overwrite `.git/objects/pack/pack-ce49d2efd5af06ed6093049050b5ba41da8b683f.idx', overriding mode 0444? y
> fatal: packfile .git/objects/pack/pack-ce49d2efd5af06ed6093049050b5ba41da8b683f.pack does not match index.
I would understand if you answer 'y' to one but 'n' to the other
it would result in a situation with unmatching .pack and .idx
and you would see something like the above (by the way, the
"fatal" is coming from update-server-info that tries to read
from freshly moved packfiles); but the above is different, so it
does not explain the symptom. I am worried and curious as to
what happened, since you are answering 'y' to both of them.
This would trigger immediately after a clone which creates pack
and idx unwritable; repack leaves the results writable unless
your umask is 0222, so "mv" would not even ask the silly
questions.
Did you happen to have .tmp-pack-ce49d2ef... at the project root
level after this failure? If so which one (either .pack or .idx)?
If you had .tmp-pack-*.pack then .git/objects/pack/pack-ce49...pack
is from the old round and .git/objects/pack/pack-ce49...idx is
from the new one. Moving .tmp-pack-* to .git/objects/pack/pack-*
would hopefully solve this problem.
Nevertheless, this _is_ a dangerous and grave bug, and thanks
for reporting it.
Maybe we would want to do something like this:
-- >8 --
git-repack: Be careful when updating the same pack as existing one.
After clone, packfiles are read-only by default and "mv" went
interactive asking if the user wants to replace it with a
repacked copy. If one is successfully moved and the other is
not, the pack and its idx would become out-of-sync and corrupts
the repository.
Recovering is straightforward -- it is just the matter of
finding the remaining .tmp-pack-* and make sure they are both
moved -- but we should be extra careful not to do something so
alarming to the users.
---
diff --git a/git-repack.sh b/git-repack.sh
index eb75c8c..b58cf91 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -54,9 +54,21 @@ else
fi
mkdir -p "$PACKDIR" || exit
- mv .tmp-pack-$name.pack "$PACKDIR/pack-$name.pack" &&
- mv .tmp-pack-$name.idx "$PACKDIR/pack-$name.idx" ||
- exit
+ for sfx in pack idx
+ do
+ if test -f "$PACKDIR/pack-$name.$sfx"
+ then
+ mv -f "$PACKDIR/pack-$name.$sfx" "$PACKDIR/old-pack-$name.$sfx"
+ fi
+ done
+ mv -f .tmp-pack-$name.pack "$PACKDIR/pack-$name.pack" &&
+ mv -f .tmp-pack-$name.idx "$PACKDIR/pack-$name.idx" || {
+ echo >&2 "Couldn't replace the existing pack with updated one."
+ echo >&2 "The original set of packs have been saved as"
+ echo >&2 "old-pack-$name.{pack,idx} in $PACKDIR."
+ exit 1
+ }
+ rm -f "$PACKDIR/old-pack-$name.pack" "$PACKDIR/old-pack-$name.idx"
fi
if test "$remove_redundant" = t
^ permalink raw reply related
* [PATCH] whatchanged: Default to DIFF_FORMAT_RAW
From: Timo Hirvonen @ 2006-06-25 12:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy7vltppj.fsf@assigned-by-dhcp.cox.net>
Split cmd_log_wc() to cmd_log_init() and cmd_log_walk() and set default
diff output format for whatchanged to DIFF_FORMAT_RAW.
Signed-off-by: Timo Hirvonen <tihirvon@gmail.com>
---
Forget the previous patch, this is cleaner.
builtin-log.c | 27 ++++++++++++++++-----------
1 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/builtin-log.c b/builtin-log.c
index 5b3fadc..28cd8bf 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -14,22 +14,22 @@ #include "builtin.h"
/* this is in builtin-diff.c */
void add_head(struct rev_info *revs);
-static int cmd_log_wc(int argc, const char **argv, char **envp,
+static void cmd_log_init(int argc, const char **argv, char **envp,
struct rev_info *rev)
{
- struct commit *commit;
-
rev->abbrev = DEFAULT_ABBREV;
rev->commit_format = CMIT_FMT_DEFAULT;
rev->verbose_header = 1;
argc = setup_revisions(argc, argv, rev, "HEAD");
- if (rev->always_show_header) {
- if (rev->diffopt.pickaxe || rev->diffopt.filter)
- rev->always_show_header = 0;
- }
-
+ if (rev->diffopt.pickaxe || rev->diffopt.filter)
+ rev->always_show_header = 0;
if (argc > 1)
die("unrecognized argument: %s", argv[1]);
+}
+
+static int cmd_log_walk(struct rev_info *rev)
+{
+ struct commit *commit;
prepare_revision_walk(rev);
setup_pager();
@@ -51,7 +51,10 @@ int cmd_whatchanged(int argc, const char
rev.diff = 1;
rev.diffopt.recursive = 1;
rev.simplify_history = 0;
- return cmd_log_wc(argc, argv, envp, &rev);
+ cmd_log_init(argc, argv, envp, &rev);
+ if (!rev.diffopt.output_format)
+ rev.diffopt.output_format = DIFF_FORMAT_RAW;
+ return cmd_log_walk(&rev);
}
int cmd_show(int argc, const char **argv, char **envp)
@@ -66,7 +69,8 @@ int cmd_show(int argc, const char **argv
rev.always_show_header = 1;
rev.ignore_merges = 0;
rev.no_walk = 1;
- return cmd_log_wc(argc, argv, envp, &rev);
+ cmd_log_init(argc, argv, envp, &rev);
+ return cmd_log_walk(&rev);
}
int cmd_log(int argc, const char **argv, char **envp)
@@ -76,7 +80,8 @@ int cmd_log(int argc, const char **argv,
init_revisions(&rev);
rev.always_show_header = 1;
rev.diffopt.recursive = 1;
- return cmd_log_wc(argc, argv, envp, &rev);
+ cmd_log_init(argc, argv, envp, &rev);
+ return cmd_log_walk(&rev);
}
static int istitlechar(char c)
--
1.4.1.rc1.g39849-dirty
^ permalink raw reply related
* Re: [RFC] git --trace: trace command execution
From: Matthias Lederhofer @ 2006-06-25 12:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3bdtv4h3.fsf@assigned-by-dhcp.cox.net>
> Interesting. Debugging one's alias entries would be helped with
> this I would imagine, and for that you would want something like
> this:
>
> > Example:
> > % git showtag v1.4.1-rc1 > /dev/null
> > trace: exec: /home/matled/local/stow/git/bin/git-showtag v1.4.1-rc1
> > trace: exec failed: No such file or directory
> * trace: expanded alias "showtag" => "cat-file tag"
That's a good idea, I'll integrate that.
> By the way "git cat-file -p" or "git verify-tag -v" might be
> more pleasant to view a tag since they make the tagger timestamp
> human readable.
Ok, yesterday I was searching for something to see the annotation of a
tag. verify-tag -v looks quite much like that, is there any other way
to read this? Or in general: how do I work with tags? I want to build
a version tagged as v1.2 so currently I'll do
> git checkout -b 1.2 v1.2
and built it. But then I've to type the version number twice (typing
it once is annoying enough :)) and I've to type it once more to get
the tag annotation.
> Might be worth reusing quote.c::sq_quote(), perhaps?
Oh, sure, did not know about this. This would result in a loop of
malloc'ing memory for the buffer. Is this ok? Or should I add a
function like sq_quote which takes a stream and writes to it?
So for the --trace part I think an environment variable GIT_TRACE is
more suitable for this because children inherit this. So running git
status will show what internal commands the shell script uses.
Otherwise I see no way to pass the --trace option down because an
extern program like git-status, git-annotate etc will not accept
parameters which can be passed to `git'.
^ permalink raw reply
* Re: On boolean configuration variables...
From: Anand Kumria @ 2006-06-25 13:33 UTC (permalink / raw)
To: git
In-Reply-To: <7vy7vmviul.fsf@assigned-by-dhcp.cox.net>
On Sat, 24 Jun 2006 05:28:02 -0700, Junio C Hamano wrote:
> Boolean configuration variables in $GIT_DIR/config are a bit
> strange.
>
> [bool]
> var1
> var2 =
> var3 = true
> var4 = yes
> var5 = 1
> var6 = 2
> var7 = false
> var8 = no
> var9 = 0
>
> var1, var3, var5, and var6 are "true"; var2, var7 and var9 are
> "false". var4 and var8 are syntax errors.
>
> Currently "git repo-config --bool --get bool.var1" returns
> "false", which is fixed by the attached patch, but I am
> wondering if it is a good idea to allow "yes" and "no" as well.
>
Allowing 'yes' and 'no' to equal 'true' and 'false' respectively sounds
pretty sane and user-friendly.
Why wouldn't you want to do that?
Anand
^ permalink raw reply
* Re: PPC SHA-1 Updates in "pu"
From: Johannes Schindelin @ 2006-06-25 13:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git, Linus Torvalds, Randal L. Schwartz
In-Reply-To: <7vzmg1v7ci.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sun, 25 Jun 2006, Junio C Hamano wrote:
> I vaguely recall that last time we discussed the minimum Perl
> version requirement somebody perhaps Merlyn said 5.6 is old
> enough but in some corporate settings people may still be stuck
> with 5.004.
>
> Tentatively let's say our cut-off point is somewhere around 5.6.
> If we can get away without relying on extra from CPAN that would
> be great. Otherwise as long as the modules from CPAN we end up
> depending on are all compatible with the cut-off version of Perl
> that would be acceptable. We might even try to be nicer and
> carry a straight copy of what we require from CPAN in compat/
> just like we have subprocess.py there (modulo licensing worries
> if any, of course).
I can live with it. Although I still think that it would be a good idea to
convert (at least the most commonly used) scripts to C.
Perl, Python and sometimes even bash are good for fast prototyping. But
for serious work, such as profiling, they are not that good.
And you can see different behaviour on different platforms (plus things
like the SunCC requirement for XS on Solaris), which make the scripts less
robust.
Ciao,
Dscho
^ permalink raw reply
* Re: New web frontend: gitarella
From: Johannes Schindelin @ 2006-06-25 13:47 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <e5bfff550606250349m1d243cbfsbecea557f3225d9b@mail.gmail.com>
Hi,
On Sun, 25 Jun 2006, Marco Costalba wrote:
> It's amazing to see in how many different ways a lot of people try to
> find an (almost the same) solution for (almost) the same problem. IMHO
> this is one of the main differences between developing for fun and as a
> day job.
Disagree. I was refactoring a C++ project recently, and we found no less
than 34 separate implementations of sorted arrays, _plus_ usage of the
STL to do the same job.
It does not depend on commercial or not, but it depends on a dedicated
benevolent dictator to keep things clean.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] GIT_TRACE: show which built-in/external commands are executed
From: Matthias Lederhofer @ 2006-06-25 13:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3bdtv4h3.fsf@assigned-by-dhcp.cox.net>
With the environment variable GIT_TRACE set git will show
- alias expansion
- built-in command execution
- external command execution
on stderr.
Signed-off-by: Matthias Lederhofer <matled@gmx.net>
---
Examples:
% GIT_TRACE=1 git status > /dev/null
trace: exec: '/home/matled/local/stow/git/bin/git-status'
trace: built-in: git 'rev-parse' '--git-dir'
trace: built-in: git 'rev-parse' '--show-cdup'
trace: built-in: git 'update-index' '-q' '--unmerged' '--refresh'
trace: built-in: git 'diff-index' '-M' '--cached' '--name-status' \
'--diff-filter=MDTCRA' 'HEAD'
trace: built-in: git 'diff-files' '--name-status'
trace: built-in: git 'ls-files' '-z' '--others' '--directory' \
'--no-empty-directory' '--exclude-from=.git/info/exclude' \
'--exclude-per-directory=.gitignore'
This seems to be quite useful to find out how tools do things and for
debugging.
% GIT_TRACE=1 git showtag v1.4.0 > /dev/null
trace: exec: '/home/matled/local/stow/git/bin/git-showtag' 'v1.4.0'
trace: exec failed: No such file or directory
trace: alias expansion: showtag => 'cat-file' 'tag'
trace: built-in: git 'cat-file' 'tag' 'v1.4.0'
% GIT_TRACE=1 git l > /dev/null
trace: exec: '/home/matled/local/stow/git/bin/git-l'
trace: exec failed: No such file or directory
trace: alias expansion: l => 'log' '-p'
trace: built-in: git 'log' '-p'
Documentation/git.txt | 7 +++++++
exec_cmd.c | 19 +++++++++++++++++++
git.c | 25 +++++++++++++++++++++++++
quote.c | 17 +++++++++++++++++
quote.h | 1 +
5 files changed, 69 insertions(+), 0 deletions(-)
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 51f20c6..603c474 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -615,6 +615,13 @@ git Diffs
gitlink:git-diff-files[1];
gitlink:git-diff-tree[1]
+other
+~~~~~
+'GIT_TRACE'::
+ If this variable is set git will print `trace:` messages on
+ stderr telling about alias expansion, built-in command
+ execution and external command execution.
+
Discussion[[Discussion]]
------------------------
include::README[]
diff --git a/exec_cmd.c b/exec_cmd.c
index c1539d1..f2133ec 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -1,5 +1,6 @@
#include "cache.h"
#include "exec_cmd.h"
+#include "quote.h"
#define MAX_ARGS 32
extern char **environ;
@@ -96,9 +97,27 @@ int execv_git_cmd(const char **argv)
tmp = argv[0];
argv[0] = git_command;
+ if (getenv("GIT_TRACE")) {
+ fputs("trace: exec:", stderr);
+ const char **p = argv;
+ while (*p) {
+ fputc(' ', stderr);
+ sq_quote_print(stderr, *p);
+ ++p;
+ }
+ putc('\n', stderr);
+ fflush(stderr);
+ }
+
/* execve() can only ever return if it fails */
execve(git_command, (char **)argv, environ);
+ if (getenv("GIT_TRACE")) {
+ fprintf(stderr, "trace: exec failed: %s\n",
+ strerror(errno));
+ fflush(stderr);
+ }
+
argv[0] = tmp;
}
return -1;
diff --git a/git.c b/git.c
index 94e9a4a..8b060e8 100644
--- a/git.c
+++ b/git.c
@@ -11,6 +11,7 @@ #include <stdarg.h>
#include "git-compat-util.h"
#include "exec_cmd.h"
#include "cache.h"
+#include "quote.h"
#include "builtin.h"
@@ -119,6 +120,18 @@ static int handle_alias(int *argcp, cons
if (!strcmp(alias_command, new_argv[0]))
die("recursive alias: %s", alias_command);
+ if (getenv("GIT_TRACE")) {
+ int i;
+ fprintf(stderr, "trace: alias expansion: %s =>",
+ alias_command);
+ for (i = 0; i < count; ++i) {
+ fputc(' ', stderr);
+ sq_quote_print(stderr, new_argv[i]);
+ }
+ fputc('\n', stderr);
+ fflush(stderr);
+ }
+
/* insert after command name */
if (*argcp > 1) {
new_argv = realloc(new_argv, sizeof(char*) *
@@ -198,6 +211,18 @@ static void handle_internal_command(int
struct cmd_struct *p = commands+i;
if (strcmp(p->cmd, cmd))
continue;
+
+ if (getenv("GIT_TRACE")) {
+ int i;
+ fprintf(stderr, "trace: built-in: git");
+ for (i = 0; i < argc; ++i) {
+ fputc(' ', stderr);
+ sq_quote_print(stderr, argv[i]);
+ }
+ putc('\n', stderr);
+ fflush(stderr);
+ }
+
exit(p->fn(argc, argv, envp));
}
}
diff --git a/quote.c b/quote.c
index dcc2326..2ca18e8 100644
--- a/quote.c
+++ b/quote.c
@@ -45,6 +45,23 @@ size_t sq_quote_buf(char *dst, size_t n,
return len;
}
+void sq_quote_print(FILE *stream, const char *src)
+{
+ char c;
+
+ fputc('\'', stream);
+ while ((c = *src++)) {
+ if (need_bs_quote(c)) {
+ fputs("'\\", stream);
+ fputc(c, stream);
+ fputc('\'', stream);
+ } else {
+ fputc(c, stream);
+ }
+ }
+ fputc('\'', stream);
+}
+
char *sq_quote(const char *src)
{
char *buf;
diff --git a/quote.h b/quote.h
index c1ab378..fc5481e 100644
--- a/quote.h
+++ b/quote.h
@@ -29,6 +29,7 @@ #include <stdio.h>
*/
extern char *sq_quote(const char *src);
+extern void sq_quote_print(FILE *stream, const char *src);
extern size_t sq_quote_buf(char *dst, size_t n, const char *src);
/* This unwraps what sq_quote() produces in place, but returns
--
1.4.1.rc1.gfa6c9-dirty
^ permalink raw reply related
* Re: On boolean configuration variables...
From: Johannes Schindelin @ 2006-06-25 14:00 UTC (permalink / raw)
To: Anand Kumria; +Cc: git
In-Reply-To: <e7m3b6$eoa$1@sea.gmane.org>
Hi,
On Sun, 25 Jun 2006, Anand Kumria wrote:
> Allowing 'yes' and 'no' to equal 'true' and 'false' respectively sounds
> pretty sane and user-friendly.
>
> Why wouldn't you want to do that?
'Cause you'd have to add "maybe", too ;-)
Seriously, there is a subtle side to booleans, which is the reason that
they typically take on only "false" and "true": Consider the question "Is
the box not red?". If the answer is "yes", I do not know if "yes, the box
is red" or "yes, the box is not red".
"true" and "false" are less ambiguous.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] GIT user survey
From: Paolo Ciarrocchi @ 2006-06-25 14:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfyhtv6iw.fsf@assigned-by-dhcp.cox.net>
On 6/25/06, Junio C Hamano <junkio@cox.net> wrote:
> "Paolo Ciarrocchi" <paolo.ciarrocchi@gmail.com> writes:
>
> > About you
> >
> > 1. What country are you in?
> > 2. What is your preferred language?
> > 3. What's your gender?
>
> Demography is interesting and quite relevant to understand the
> bias in the answers to the rest of the questions, although I do
> not see much point about #3. Question #2 is relevant in i18n,
> of course.
Yeah, removed item #3.
> I would also ask if the respondent has her own patch in the
> git.git repository. If most of them are git developers, the
> answer to the question "was git easy to learn" becomes
> suspicious, for example.
OK.
> > Getting started with GIT
> >
> > 1. How did you hear about GIT?
> > 2. Did you find GIT easy to learn?
> > 3. What helped you most in learning to use it?
>
> Also "When did you start using git?" -- old timers who learned
> git when it was still young and small would have had an easier
> time to learn it.
OK.
> > How you use GIT
> >
> > 1. Do you use GIT for work, unpaid projects, or both?
> > 2. How do you obtain GIT? Source tarball, binary package, or
> > pull the main repository?
> > 3. What platforms (hardware, OS, version) do you use GIT on?
> > 4. How many people do you collaborate with using GIT?
> > 5. How big are the repositories that you work on? (e.g. how many
> > files, how much disk space)
> > 6. How many different projects do you manage using GIT?
> > 7. Which porcelains do you use?
>
> After seeing the Mercurial survey result, I think question #3
> should be stated a bit more concretely. The results having
> mixture of i386 and Linux are not very interesting. I would
> also add "how deep the history" to #5.
OK
> > Getting help, staying in touch
> >
> > 1. Have you tried to get GIT help from other people?
> > * If yes, did you get these problems resolved quickly and to
> > your liking?
> > 2. Do you subscribe to the mailing list?
> > * If yes, do you find it useful, and traffic levels OK?
> > 3. Do you use the IRC channel (#git on irc.freenode.net)?
> > * If no, did you know that all of the core developers use
> > IRC, and that there's almost 24-hour help available?
>
> About #3, I do not see some people I consider "core" often on
> the IRC. Maybe "most of the core".
I think I can remove that part of the sentece, Pasky already had the
same comment when I was discussing the sruvey on #GIT. My mistake.
New version attached.
About you
1. What country are you in?
2. What is your preferred language?
Getting started with GIT
1. How did you hear about GIT?
2. Did you find GIT easy to learn?
3. What helped you most in learning to use it?
4. When did you start using git?
How you use GIT
1. Do you use GIT for work, unpaid projects, or both?
2. How do you obtain GIT? Source tarball, binary package, or
pull the main repository?
3. What hardware platforms do you use GIT on?
4. What OS (please include the version) do you use GIT on?
5. How many people do you collaborate with using GIT?
6. How big are the repositories that you work on? (e.g. how many
files, how much disk space, how deep is the histoty)
7. How many different projects do you manage using GIT?
8. Which porcellains do you use?
9. Is the git.git repository including codes produced by you?
What you think of GIT
1. Overall, how happy are you with GIT?
2. How does GIT compare to other SCM tools you have used?
3. What do you like about using GIT?
4. What would you most like to see improved about GIT?
(features, bugs, plugins, documentation, ...)
5. If you want to see GIT more widely used, what do you
think we could do to make this happen?
Documentation
1. Do you use the GIT wiki? If yes, do you find it useful?
2. Do you find GIT's online help useful?
3. What is your favourite user documentation for any software
projects or products you have used?
4. What could be improved on the GIT homepage?
Getting help, staying in touch
1. Have you tried to get GIT help from other people?
* If yes, did you get these problems resolved quickly and to
your liking?
2. Do you subscribe to the mailing list?
* If yes, do you find it useful, and traffic levels OK?
3. Do you use the IRC channel (#git on irc.freenode.net)?
Open forum
1. What other comments or suggestions do you have that are not
covered by the questions above?
--
Paolo
http://paolociarrocchi.googlepages.com
http://picasaweb.google.com/paolo.ciarrocchi
^ permalink raw reply
* Re: [PATCH] GIT_TRACE: show which built-in/external commands are executed
From: Johannes Schindelin @ 2006-06-25 14:11 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: Junio C Hamano, git
In-Reply-To: <E1FuV62-0004Jd-Ve@moooo.ath.cx>
Hi,
On Sun, 25 Jun 2006, Matthias Lederhofer wrote:
> With the environment variable GIT_TRACE set git will show
> - alias expansion
> - built-in command execution
> - external command execution
> on stderr.
Nice.
Ciao,
Dscho
P.S.: Now we only have to convert all "git-" invocations in the scripts to
"git " invocations so we can benefit from it. But that would mean two
forks instead of one for the non-builtins. Hmm.
^ permalink raw reply
* Re: [PATCH] GIT_TRACE: show which built-in/external commands are executed
From: Petr Baudis @ 2006-06-25 14:22 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Matthias Lederhofer, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0606251607090.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Hi,
Dear diary, on Sun, Jun 25, 2006 at 04:11:48PM CEST, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> P.S.: Now we only have to convert all "git-" invocations in the scripts to
> "git " invocations so we can benefit from it. But that would mean two
> forks instead of one for the non-builtins. Hmm.
actually this is a myth - not two fork()s since 'git' has no reason to
fork; only two execve()s in line after a single fork().
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* Re: [Patch] trap: exit: invalid signal specification
From: S.Çağlar Onur @ 2006-06-25 14:33 UTC (permalink / raw)
To: Yakov Lerner; +Cc: git
In-Reply-To: <f36b08ee0606241311h399c42b0h11638f14d6f54bd5@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 659 bytes --]
Cumartesi 24 Haziran 2006 23:11 tarihinde şunları yazmıştınız:
> But in the commandline you are patching, 'exit' keyword
> is not bash signal name,
Pff, you are completely right. I'm currently using git-1.2.6 which has "exit"
signal (git-clone.sh: trap 'err=$?; cd ..; rm -r "$D"; exit $err' exit )
causing that trouble but in git-1.4.0 its converted to 0 (git-clone.sh:
trap 'err=$?; cd ..; rm -r "$D"; exit $err' 0) and i didn't realize until
look again. Sorry for noise :(
--
S.Çağlar Onur <caglar@pardus.org.tr>
http://cekirdek.pardus.org.tr/~caglar/
Linux is like living in a teepee. No Windows, no Gates and an Apache in house!
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Git.pm build: Fix quoting and missing GIT-CFLAGS dependency
From: Petr Baudis @ 2006-06-25 15:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Chris Wright, Linus Torvalds, git
In-Reply-To: <7vac82q6mb.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sun, Jun 25, 2006 at 05:03:24AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> During our a handful piecemeal patch exchange back-and-forth on
> the list, most of the patches did not apply mechanically, so I
> rolled them up and have pushed out the result in "pu" and it
> will mirror out shortly. I am reasonably sure it is in much
> better shape than 24 hours ago; could you double check the
> result for me please?
It looks good; I don't like the makefile changes a lot but more on that
below.
Could you please also throw in these two?
[PATCH 3/7] Git.pm: Swap hash_object() parameters
[PATCH 4/7] Git.pm: Fix Git->repository("/somewhere/totally/elsewhere")
..snip..
> - RPM target -- we probably acquired a new build-dependency in
> which case the .spec file needs to be updated;
..snip..
> I think we have cleared SITELIBARCH, and Git.xs building is in
> testable state for wider audience. The remaining hurdles are to
> make sure the RPM target is still sensible, and fix the test
> scheme.
>
> Now, I am clueless about RPM, so help is very much appreciated.
Chris, could you help, please? Do we need to insert anything special
to builddeps if we build own Perl module?
> About the testsuite, I think with the way git-fmt-merge-msg (and
> other Perl scripts that will use Git.pm) is munged on the
> initial line "#!/usr/bin/perl -I$(installedpath)", the test
> scheme is seriously broken. To see how yourself, have a good
> working version of Git.pm and friends in the path your
> git-fmt-merge-msg's first line points at, apply the following
> patch to perl/Git.pm in your source tree and run "make test".
> It will pass t5700-clone-reference.sh test, which does "git
> pull" (and uses git-fmt-merge-msg) without problems X-<.
Yes, -I is very broken. I have abandoned it in:
Subject: Re: [PATCH 01/12] Introduce Git.pm (v4)
Date: Sat, 24 Jun 2006 13:52:27 +0200
The advantage to your approach is that it works properly without
requiring to make install even outside of the testsuite.
> The additional dependency to perl/Makefile is needed regardless
> of this tentative fix -- you cannot run make -C perl before
> building perl/Makefile.
Yes, that bit shall be Acked-by: Petr Baudis <pasky@suse.cz>
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* Re: [PATCH] Git.pm: Support for perl/ being built by a different compiler
From: Petr Baudis @ 2006-06-25 15:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk676orjy.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sun, Jun 25, 2006 at 05:14:09AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Petr Baudis <pasky@suse.cz> writes:
> > This is not really meant for an application yet since it's not clear
> > if it will alone help anything.
It appears that it did have helped and all went well, according to dst_.
> I would question why the rest of git is not built with Sun CC as
> well if that is the case.
< dst_> Three points: (1) Gcc comes along with solaris, sun cc not.
< dst_> (2) Git used a lot of GCC'isms whan I last checked a few weeks ago
< dst_> (3) a lot of other software will not ompile out of the box with suncc, so gcc is usually the safer choice
Of course (1) is troublesome since this means you can't build Git on
Solaris without installing Sun CC - I have no other answer to this than
that Solaris is horribly broken. :-( Perhaps ExtUtils::MakeMaker could
be convinced to build with gcc, I'm not sure.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ 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