* Re: [PATCH] Move gitweb style to gitweb.css
From: Jakub Narebski @ 2006-06-18 4:32 UTC (permalink / raw)
To: git
In-Reply-To: <7vhd2j5hi2.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> Move gitweb style from embedded <style> element in gitweb/gitweb.cgi
>> to external CSS file gitweb/gitweb.css.
>>
>> ---
>> External CSS file can be downloaded only once and cached.
>
> That's good, but I'm wondering if you dropped this deliberately
> or it was just an accident.
>
>> -body {
>> - font-family: sans-serif; font-size: 12px; border:solid #d9d8d1; border-width:1px;
>> - margin:10px; background-color:#ffffff; color:#000000;
>> -}
Ooops. Amended commit follows.
Note: this patch is of temporary use, as I plan to merge xmms2 additions
to gitweb, which include separate CSS file too.
-- >8 --
From nobody Mon Sep 17 00:00:00 2001
From: Jakub Narebski <jnareb@gmail.com>
Date: Sat Jun 17 11:15:18 2006 +0200
Subject: [PATCH] Move gitweb style to gitweb.css
Move gitweb style from embedded <style> element in gitweb/gitweb.cgi
to external CSS file gitweb/gitweb.css. Introduced new configuration
variable $stylesheet.
---
gitweb/gitweb.cgi | 64 +++--------------------------------------------------
gitweb/gitweb.css | 58 ++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 62 insertions(+), 60 deletions(-)
create mode 100644 gitweb/gitweb.css
42b89d8cbc6bdfed33df7bdadf45a3254cf8f1ae
diff --git a/gitweb/gitweb.cgi b/gitweb/gitweb.cgi
index ea21fbe..9d902b7 100755
--- a/gitweb/gitweb.cgi
+++ b/gitweb/gitweb.cgi
@@ -38,6 +38,9 @@ my $home_link = $my_uri;
# html text to include at home page
my $home_text = "indextext.html";
+# URI of default stylesheet
+my $stylesheet = "gitweb.css";
+
# source of projects list
#my $projects_list = $projectroot;
my $projects_list = "index/index.aux";
@@ -257,68 +260,9 @@ sub git_header_html {
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8"/>
<meta name="robots" content="index, nofollow"/>
+<link rel="stylesheet" href="$stylesheet"/>
<title>$title</title>
$rss_link
-<style type="text/css">
-body {
- font-family: sans-serif; font-size: 12px; border:solid #d9d8d1; border-width:1px;
- margin:10px; background-color:#ffffff; color:#000000;
-}
-a { color:#0000cc; }
-a:hover, a:visited, a:active { color:#880000; }
-div.page_header { height:25px; padding:8px; font-size:18px; font-weight:bold; background-color:#d9d8d1; }
-div.page_header a:visited, a.header { color:#0000cc; }
-div.page_header a:hover { color:#880000; }
-div.page_nav { padding:8px; }
-div.page_nav a:visited { color:#0000cc; }
-div.page_path { padding:8px; border:solid #d9d8d1; border-width:0px 0px 1px}
-div.page_footer { height:17px; padding:4px 8px; background-color: #d9d8d1; }
-div.page_footer_text { float:left; color:#555555; font-style:italic; }
-div.page_body { padding:8px; }
-div.title, a.title {
- display:block; padding:6px 8px;
- font-weight:bold; background-color:#edece6; text-decoration:none; color:#000000;
-}
-a.title:hover { background-color: #d9d8d1; }
-div.title_text { padding:6px 0px; border: solid #d9d8d1; border-width:0px 0px 1px; }
-div.log_body { padding:8px 8px 8px 150px; }
-span.age { position:relative; float:left; width:142px; font-style:italic; }
-div.log_link {
- padding:0px 8px;
- font-size:10px; font-family:sans-serif; font-style:normal;
- position:relative; float:left; width:136px;
-}
-div.list_head { padding:6px 8px 4px; border:solid #d9d8d1; border-width:1px 0px 0px; font-style:italic; }
-a.list { text-decoration:none; color:#000000; }
-a.list:hover { text-decoration:underline; color:#880000; }
-a.text { text-decoration:none; color:#0000cc; }
-a.text:visited { text-decoration:none; color:#880000; }
-a.text:hover { text-decoration:underline; color:#880000; }
-table { padding:8px 4px; }
-th { padding:2px 5px; font-size:12px; text-align:left; }
-tr.light:hover { background-color:#edece6; }
-tr.dark { background-color:#f6f6f0; }
-tr.dark:hover { background-color:#edece6; }
-td { padding:2px 5px; font-size:12px; vertical-align:top; }
-td.link { padding:2px 5px; font-family:sans-serif; font-size:10px; }
-div.pre { font-family:monospace; font-size:12px; white-space:pre; }
-div.diff_info { font-family:monospace; color:#000099; background-color:#edece6; font-style:italic; }
-div.index_include { border:solid #d9d8d1; border-width:0px 0px 1px; padding:12px 8px; }
-div.search { margin:4px 8px; position:absolute; top:56px; right:12px }
-a.linenr { color:#999999; text-decoration:none }
-a.rss_logo {
- float:right; padding:3px 0px; width:35px; line-height:10px;
- border:1px solid; border-color:#fcc7a5 #7d3302 #3e1a01 #ff954e;
- color:#ffffff; background-color:#ff6600;
- font-weight:bold; font-family:sans-serif; font-size:10px;
- text-align:center; text-decoration:none;
-}
-a.rss_logo:hover { background-color:#ee5500; }
-span.tag {
- padding:0px 4px; font-size:10px; font-weight:normal;
- background-color:#ffffaa; border:1px solid; border-color:#ffffcc #ffee00 #ffee00 #ffffcc;
-}
-</style>
</head>
<body>
EOF
diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
new file mode 100644
index 0000000..5900916
--- /dev/null
+++ b/gitweb/gitweb.css
@@ -0,0 +1,58 @@
+body {
+ font-family: sans-serif; font-size: 12px; border:solid #d9d8d1; border-width:1px;
+ margin:10px; background-color:#ffffff; color:#000000;
+}
+a { color:#0000cc; }
+a:hover, a:visited, a:active { color:#880000; }
+div.page_header { height:25px; padding:8px; font-size:18px; font-weight:bold; background-color:#d9d8d1; }
+div.page_header a:visited, a.header { color:#0000cc; }
+div.page_header a:hover { color:#880000; }
+div.page_nav { padding:8px; }
+div.page_nav a:visited { color:#0000cc; }
+div.page_path { padding:8px; border:solid #d9d8d1; border-width:0px 0px 1px}
+div.page_footer { height:17px; padding:4px 8px; background-color: #d9d8d1; }
+div.page_footer_text { float:left; color:#555555; font-style:italic; }
+div.page_body { padding:8px; }
+div.title, a.title {
+ display:block; padding:6px 8px;
+ font-weight:bold; background-color:#edece6; text-decoration:none; color:#000000;
+}
+a.title:hover { background-color: #d9d8d1; }
+div.title_text { padding:6px 0px; border: solid #d9d8d1; border-width:0px 0px 1px; }
+div.log_body { padding:8px 8px 8px 150px; }
+span.age { position:relative; float:left; width:142px; font-style:italic; }
+div.log_link {
+ padding:0px 8px;
+ font-size:10px; font-family:sans-serif; font-style:normal;
+ position:relative; float:left; width:136px;
+}
+div.list_head { padding:6px 8px 4px; border:solid #d9d8d1; border-width:1px 0px 0px; font-style:italic; }
+a.list { text-decoration:none; color:#000000; }
+a.list:hover { text-decoration:underline; color:#880000; }
+a.text { text-decoration:none; color:#0000cc; }
+a.text:visited { text-decoration:none; color:#880000; }
+a.text:hover { text-decoration:underline; color:#880000; }
+table { padding:8px 4px; }
+th { padding:2px 5px; font-size:12px; text-align:left; }
+tr.light:hover { background-color:#edece6; }
+tr.dark { background-color:#f6f6f0; }
+tr.dark:hover { background-color:#edece6; }
+td { padding:2px 5px; font-size:12px; vertical-align:top; }
+td.link { padding:2px 5px; font-family:sans-serif; font-size:10px; }
+div.pre { font-family:monospace; font-size:12px; white-space:pre; }
+div.diff_info { font-family:monospace; color:#000099; background-color:#edece6; font-style:italic; }
+div.index_include { border:solid #d9d8d1; border-width:0px 0px 1px; padding:12px 8px; }
+div.search { margin:4px 8px; position:absolute; top:56px; right:12px }
+a.linenr { color:#999999; text-decoration:none }
+a.rss_logo {
+ float:right; padding:3px 0px; width:35px; line-height:10px;
+ border:1px solid; border-color:#fcc7a5 #7d3302 #3e1a01 #ff954e;
+ color:#ffffff; background-color:#ff6600;
+ font-weight:bold; font-family:sans-serif; font-size:10px;
+ text-align:center; text-decoration:none;
+}
+a.rss_logo:hover { background-color:#ee5500; }
+span.tag {
+ padding:0px 4px; font-size:10px; font-weight:normal;
+ background-color:#ffffaa; border:1px solid; border-color:#ffffcc #ffee00 #ffee00 #ffffcc;
+}
--
1.3.0
^ permalink raw reply related
* Re: [RFD] gitweb configuration
From: Jakub Narebski @ 2006-06-18 4:00 UTC (permalink / raw)
To: git
In-Reply-To: <20060617232358.GK2609@pasky.or.cz>
Petr Baudis wrote:
>> - gitweb installation options (gitweb version need not to correspond to
>> git version, and we could theoretically have more than one gitweb
>> installation while one git-core installation). It was proposed to put
>> such options on gitweb.conf file in the same directory as gitweb.cgi.
>> Unfortunately if one would want to use git-repo-config for managing
>> gitweb.conf one is out of luck: git-repo-config uses $GIT_DIR/config.
>
> In the longer term, perhaps this kind of configuration might land in the
> global git configuration file.
We could use user's "global" configuration file, ~/.gitconfig, in patch
from Johannes Schindelin (and now in 'pu').
So GIT_CONFIG would be ~/.gitconfig, and GIT_CONFIG_LOCAL would be
$GIT_DIR/config or what?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] rebase: Allow merge strategies to be used when rebasing
From: Eric Wong @ 2006-06-18 3:02 UTC (permalink / raw)
To: git, Junio C Hamano; +Cc: Eric Wong
This solves the problem of rebasing local commits against an
upstream that has renamed files.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
Documentation/git-rebase.txt | 20 +++++
git-rebase.sh | 176 ++++++++++++++++++++++++++++++++++++++++--
2 files changed, 186 insertions(+), 10 deletions(-)
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 08ee4aa..c339c45 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -7,7 +7,7 @@ git-rebase - Rebase local commits to a n
SYNOPSIS
--------
-'git-rebase' [--onto <newbase>] <upstream> [<branch>]
+'git-rebase' [--merge] [--onto <newbase>] <upstream> [<branch>]
'git-rebase' --continue | --skip | --abort
@@ -106,6 +106,24 @@ OPTIONS
--abort::
Restore the original branch and abort the rebase operation.
+--skip::
+ Restart the rebasing process by skipping the current patch.
+ This does not work with the --merge option.
+
+--merge::
+ Use merging strategies to rebase. When the recursive (default) merge
+ strategy is used, this allows rebase to be aware of renames on the
+ upstream side.
+
+-s <strategy>, \--strategy=<strategy>::
+ Use the given merge strategy; can be supplied more than
+ once to specify them in the order they should be tried.
+ If there is no `-s` option, a built-in list of strategies
+ is used instead (`git-merge-recursive` when merging a single
+ head, `git-merge-octopus` otherwise). This implies --merge.
+
+include::merge-strategies.txt[]
+
NOTES
-----
When you rebase a branch, you are changing its history in a way that
diff --git a/git-rebase.sh b/git-rebase.sh
index e6b57b8..68bddfb 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -34,7 +34,81 @@ When you have resolved this problem run
If you would prefer to skip this patch, instead run \"git rebase --skip\".
To restore the original branch and stop rebasing run \"git rebase --abort\".
"
+
+MRESOLVEMSG="
+When you have resolved this problem run \"git rebase --continue\".
+To restore the original branch and stop rebasing run \"git rebase --abort\".
+"
unset newbase
+strategy_args=
+do_merge=
+dotest=$GIT_DIR/.dotest-merge
+prec=4
+
+continue_merge () {
+ test -n "$prev_head" || die "prev_head must be defined"
+ test -d "$dotest" || die "$dotest directory does not exist"
+
+ unmerged=$(git-ls-files -u)
+ if test -n "$unmerged"
+ then
+ echo "You still have unmerged paths in your index"
+ echo "did you forget update-index?"
+ die "$MRESOLVEMSG"
+ fi
+
+ mh="$GIT_DIR/MERGE_HEAD"
+ mm="$GIT_DIR/MERGE_MSG"
+ if test -f "$mh" && test -f "$mm"
+ then
+ git-commit -F "$mm" || die "commit failed: $MRESOLVEMSG"
+ else
+ echo "Previous merge succeeded automatically"
+ fi
+
+ prev_head=`git-rev-parse HEAD^0`
+
+ # save the resulting commit so we can read-tree on it later
+ echo "$prev_head" > "$dotest/`printf %0${prec}d $msgnum`.result"
+ echo "$prev_head" > "$dotest/prev_head"
+
+ # onto the next patch:
+ msgnum=$(($msgnum + 1))
+ printf "%0${prec}d" "$msgnum" > "$dotest/msgnum"
+}
+
+call_merge () {
+ cmt="$(cat $dotest/`printf %0${prec}d $1`)"
+ echo "$cmt" > "$dotest/current"
+ git-merge $strategy_args "rebase-merge: $cmt" HEAD "$cmt" \
+ || die "$MRESOLVEMSG"
+}
+
+finish_rb_merge () {
+ set -e
+
+ msgnum=1
+ echo "Finalizing rebased commits..."
+ git-reset --hard "`cat $dotest/upstream`"
+ end="`cat $dotest/end`"
+ while test "$msgnum" -le "$end"
+ do
+ msgnum=`printf "%0${prec}d" "$msgnum"`
+ printf "%0${prec}d" "$msgnum" > "$dotest/msgnum"
+
+ git-read-tree `cat "$dotest/$msgnum.result"`
+ git-checkout-index -q -f -u -a
+ git-commit -C "`cat $dotest/$msgnum`"
+
+ echo "Committed $msgnum"
+ echo ' '`git-rev-list --pretty=oneline -1 HEAD | \
+ sed 's/^[a-f0-9]\+ //'`
+ msgnum=$(($msgnum + 1))
+ done
+ rm -r "$dotest"
+ echo "All done."
+}
+
while case "$#" in 0) break ;; esac
do
case "$1" in
@@ -46,17 +120,42 @@ do
exit 1
;;
esac
+ if test -d "$dotest"
+ then
+ prev_head="`cat $dotest/prev_head`"
+ end="`cat $dotest/end`"
+ msgnum="`cat $dotest/msgnum`"
+ continue_merge
+ while test "$msgnum" -le "$end"
+ do
+ call_merge "$msgnum"
+ continue_merge
+ done
+ finish_rb_merge
+ exit
+ fi
git am --resolved --3way --resolvemsg="$RESOLVEMSG"
exit
;;
--skip)
+ if test -d "$dotest"
+ then
+ die "--skip is not supported when using --merge"
+ fi
git am -3 --skip --resolvemsg="$RESOLVEMSG"
exit
;;
--abort)
- [ -d .dotest ] || die "No rebase in progress?"
+ if test -d "$dotest"
+ then
+ rm -r "$dotest"
+ elif test -d .dotest
+ then
+ rm -r .dotest
+ else
+ die "No rebase in progress?"
+ fi
git reset --hard ORIG_HEAD
- rm -r .dotest
exit
;;
--onto)
@@ -64,6 +163,24 @@ do
newbase="$2"
shift
;;
+ -M|-m|--m|--me|--mer|--merg|--merge)
+ do_merge=t
+ ;;
+ -s=*|--s=*|--st=*|--str=*|--stra=*|--strat=*|--strate=*|\
+ --strateg=*|--strategy=*|\
+ -s|--s|--st|--str|--stra|--strat|--strate|--strateg|--strategy)
+ case "$#,$1" in
+ *,*=*)
+ strategy=`expr "$1" : '-[^=]*=\(.*\)'` ;;
+ 1,*)
+ usage ;;
+ *)
+ strategy="$2"
+ shift ;;
+ esac
+ do_merge=t
+ strategy_args="${strategy_args}-s $strategy "
+ ;;
-*)
usage
;;
@@ -75,16 +192,25 @@ do
done
# Make sure we do not have .dotest
-if mkdir .dotest
+if test -z "$do_merge"
then
- rmdir .dotest
-else
- echo >&2 '
+ if mkdir .dotest
+ then
+ rmdir .dotest
+ else
+ echo >&2 '
It seems that I cannot create a .dotest directory, and I wonder if you
are in the middle of patch application or another rebase. If that is not
the case, please rm -fr .dotest and run me again. I am stopping in case
you still have something valuable there.'
- exit 1
+ exit 1
+ fi
+else
+ if test -d "$dotest"
+ then
+ die "previous dotest directory $dotest still exists." \
+ 'try git-rebase < --continue | --abort >'
+ fi
fi
# The tree must be really really clean.
@@ -152,6 +278,38 @@ then
exit 0
fi
-git-format-patch -k --stdout --full-index "$upstream"..ORIG_HEAD |
-git am --binary -3 -k --resolvemsg="$RESOLVEMSG"
+if test -z "$do_merge"
+then
+ git-format-patch -k --stdout --full-index "$upstream"..ORIG_HEAD |
+ git am --binary -3 -k --resolvemsg="$RESOLVEMSG"
+ exit 0
+fi
+
+# start doing a rebase with git-merge
+# this is rename-aware if the recursive (default) strategy is used
+
+mkdir -p "$dotest"
+echo "$upstream" > "$dotest/upstream"
+prev_head=`git-rev-parse HEAD^0`
+echo "$prev_head" > "$dotest/prev_head"
+
+msgnum=0
+for cmt in `git-rev-list "$upstream"..ORIG_HEAD | tac`
+do
+ msgnum=$(($msgnum + 1))
+ echo "$cmt" > "$dotest/`printf "%0${prec}d" $msgnum`"
+done
+
+printf "%0${prec}d" 1 > "$dotest/msgnum"
+printf "%0${prec}d" "$msgnum" > "$dotest/end"
+
+end=$msgnum
+msgnum=1
+
+while test "$msgnum" -le "$end"
+do
+ call_merge "$msgnum"
+ continue_merge
+done
+finish_rb_merge
--
1.4.0.ge24c
^ permalink raw reply related
* Re: [PATCH] Move gitweb style to gitweb.css
From: Junio C Hamano @ 2006-06-18 2:23 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200606171123.56643.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Move gitweb style from embedded <style> element in gitweb/gitweb.cgi
> to external CSS file gitweb/gitweb.css.
>
> ---
> External CSS file can be downloaded only once and cached.
That's good, but I'm wondering if you dropped this deliberately
or it was just an accident.
> -body {
> - font-family: sans-serif; font-size: 12px; border:solid #d9d8d1; border-width:1px;
> - margin:10px; background-color:#ffffff; color:#000000;
> -}
^ permalink raw reply
* Some more memory leak avoidance
From: Linus Torvalds @ 2006-06-18 1:47 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
This is really the dregs of my effort to not waste memory in git-rev-list,
and makes barely one percent of a difference in the memory footprint, but
hey, it's also a pretty small patch.
It discards the parent lists and the commit buffer after the commit has
been shown by git-rev-list (and "git log" - which already did the commit
buffer part), and frees the commit list entry that was used by the
revision walker.
The big win would be to get rid of the "refs" pointer in the object
structure (another 5%), because it's only used by fsck. That would require
some pretty major surgery to fsck, though, so I'm timid and did the less
interesting but much easier part instead.
This (percentually) makes a bigger difference to "git log" and friends,
since those are walking _just_ commits, and thus the list entries tend to
be a bigger percentage of the memory use. But the "list all objects" case
does improve too.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
This one should be independent of the other memory use optimizations.
builtin-log.c | 2 ++
builtin-rev-list.c | 8 ++++++++
revision.c | 6 ++++--
3 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/builtin-log.c b/builtin-log.c
index 29a8851..f6da1c3 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -40,6 +40,8 @@ static int cmd_log_wc(int argc, const ch
log_tree_commit(rev, commit);
free(commit->buffer);
commit->buffer = NULL;
+ free_commit_list(commit->parents);
+ commit->parents = NULL;
}
return 0;
}
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index 2b298c4..71353eb 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -89,6 +89,14 @@ static void show_commit(struct commit *c
printf("%s%c", pretty_header, hdr_termination);
}
fflush(stdout);
+ if (commit->parents) {
+ free_commit_list(commit->parents);
+ commit->parents = NULL;
+ }
+ if (commit->buffer) {
+ free(commit->buffer);
+ commit->buffer = NULL;
+ }
}
static struct object_list **process_blob(struct blob *blob,
diff --git a/revision.c b/revision.c
index f4b8826..475d604 100644
--- a/revision.c
+++ b/revision.c
@@ -944,9 +944,11 @@ struct commit *get_revision(struct rev_i
}
do {
- struct commit *commit = revs->commits->item;
+ struct commit_list *entry = revs->commits;
+ struct commit *commit = entry->item;
- revs->commits = revs->commits->next;
+ revs->commits = entry->next;
+ free(entry);
/*
* If we haven't done the list limiting, we need to look at
^ permalink raw reply related
* Move "void *util" from "struct object" into "struct commit"
From: Linus Torvalds @ 2006-06-18 1:26 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
Every single user actually wanted this only for commit objects, and we
have no reason to waste space on it for other object types. So just move
the structure member from the low-level "struct object" into the "struct
commit".
This leaves the commit object the same size, and removes one unnecessary
pointer from all other object allocations.
This shrinks memory usage (still at a fairly hefty half-gig, admittedly)
of "git-rev-list --all --objects" on the mozilla repo by another 5% in my
tests.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
This is on top of the previous memory usage shrinking patch, and won't
actually work without it (although if wanted, you can start off with this
one with some trivial modifications - they are _barely_ interdependent,
with very little overlap)
blame.c | 48 ++++++++++++++++++++++++------------------------
builtin-show-branch.c | 24 ++++++++++++------------
commit.c | 4 ++--
commit.h | 1 +
name-rev.c | 12 +++++++++---
object.h | 1 -
6 files changed, 48 insertions(+), 42 deletions(-)
diff --git a/blame.c b/blame.c
index 88bfec2..2dd70ee 100644
--- a/blame.c
+++ b/blame.c
@@ -108,8 +108,8 @@ static struct patch *get_patch(struct co
xdemitconf_t xecfg;
mmfile_t file_c, file_o;
xdemitcb_t ecb;
- struct util_info *info_c = (struct util_info *)commit->object.util;
- struct util_info *info_o = (struct util_info *)other->object.util;
+ struct util_info *info_c = (struct util_info *)commit->util;
+ struct util_info *info_o = (struct util_info *)other->util;
struct timeval tv_start, tv_end;
get_blob(commit);
@@ -195,7 +195,7 @@ static int get_blob_sha1_internal(const
static void get_blob(struct commit *commit)
{
- struct util_info *info = commit->object.util;
+ struct util_info *info = commit->util;
char type[20];
if (info->buf)
@@ -221,8 +221,8 @@ #if DEBUG
/* For debugging only */
static void print_map(struct commit *cmit, struct commit *other)
{
- struct util_info *util = cmit->object.util;
- struct util_info *util2 = other->object.util;
+ struct util_info *util = cmit->util;
+ struct util_info *util2 = other->util;
int i;
int max =
@@ -257,8 +257,8 @@ #endif
static void fill_line_map(struct commit *commit, struct commit *other,
struct patch *p)
{
- struct util_info *util = commit->object.util;
- struct util_info *util2 = other->object.util;
+ struct util_info *util = commit->util;
+ struct util_info *util2 = other->util;
int *map = util->line_map;
int *map2 = util2->line_map;
int cur_chunk = 0;
@@ -320,14 +320,14 @@ static void fill_line_map(struct commit
static int map_line(struct commit *commit, int line)
{
- struct util_info *info = commit->object.util;
+ struct util_info *info = commit->util;
assert(line >= 0 && line < info->num_lines);
return info->line_map[line];
}
static struct util_info* get_util(struct commit *commit)
{
- struct util_info *util = commit->object.util;
+ struct util_info *util = commit->util;
if (util)
return util;
@@ -338,13 +338,13 @@ static struct util_info* get_util(struct
util->line_map = NULL;
util->num_lines = -1;
util->pathname = NULL;
- commit->object.util = util;
+ commit->util = util;
return util;
}
static int fill_util_info(struct commit *commit)
{
- struct util_info *util = commit->object.util;
+ struct util_info *util = commit->util;
assert(util);
assert(util->pathname);
@@ -357,7 +357,7 @@ static int fill_util_info(struct commit
static void alloc_line_map(struct commit *commit)
{
- struct util_info *util = commit->object.util;
+ struct util_info *util = commit->util;
int i;
if (util->line_map)
@@ -381,7 +381,7 @@ static void alloc_line_map(struct commit
static void init_first_commit(struct commit* commit, const char* filename)
{
- struct util_info* util = commit->object.util;
+ struct util_info* util = commit->util;
int i;
util->pathname = filename;
@@ -390,7 +390,7 @@ static void init_first_commit(struct com
alloc_line_map(commit);
- util = commit->object.util;
+ util = commit->util;
for (i = 0; i < util->num_lines; i++)
util->line_map[i] = i;
@@ -411,7 +411,7 @@ static void process_commits(struct rev_i
assert(commit);
init_first_commit(commit, path);
- util = commit->object.util;
+ util = commit->util;
num_blame_lines = util->num_lines;
blame_lines = xmalloc(sizeof(struct commit *) * num_blame_lines);
blame_contents = util->buf;
@@ -450,7 +450,7 @@ static void process_commits(struct rev_i
continue;
alloc_line_map(commit);
- util = commit->object.util;
+ util = commit->util;
for (parents = commit->parents;
parents != NULL; parents = parents->next) {
@@ -510,7 +510,7 @@ static int compare_tree_path(struct rev_
{
int ret;
const char* paths[2];
- struct util_info* util = c2->object.util;
+ struct util_info* util = c2->util;
paths[0] = util->pathname;
paths[1] = NULL;
@@ -539,7 +539,7 @@ static int same_tree_as_empty_path(struc
static const char* find_rename(struct commit* commit, struct commit* parent)
{
- struct util_info* cutil = commit->object.util;
+ struct util_info* cutil = commit->util;
struct diff_options diff_opts;
const char *paths[1];
int i;
@@ -583,7 +583,7 @@ static void simplify_commit(struct rev_i
return;
if (!commit->parents) {
- struct util_info* util = commit->object.util;
+ struct util_info* util = commit->util;
if (!same_tree_as_empty_path(revs, commit->tree,
util->pathname))
commit->object.flags |= TREECHANGE;
@@ -610,7 +610,7 @@ static void simplify_commit(struct rev_i
case REV_TREE_NEW:
{
- struct util_info* util = commit->object.util;
+ struct util_info* util = commit->util;
if (revs->remove_empty_trees &&
same_tree_as_empty_path(revs, p->tree,
util->pathname)) {
@@ -701,13 +701,13 @@ static const char* format_time(unsigned
static void topo_setter(struct commit* c, void* data)
{
- struct util_info* util = c->object.util;
+ struct util_info* util = c->util;
util->topo_data = data;
}
static void* topo_getter(struct commit* c)
{
- struct util_info* util = c->object.util;
+ struct util_info* util = c->util;
return util->topo_data;
}
@@ -850,7 +850,7 @@ int main(int argc, const char **argv)
struct util_info* u;
if (!c)
c = initial;
- u = c->object.util;
+ u = c->util;
if (!found_rename && strcmp(filename, u->pathname))
found_rename = 1;
@@ -868,7 +868,7 @@ int main(int argc, const char **argv)
if (!c)
c = initial;
- u = c->object.util;
+ u = c->util;
get_commit_info(c, &ci);
fwrite(sha1_to_hex(c->object.sha1), sha1_len, 1, stdout);
if(compability) {
diff --git a/builtin-show-branch.c b/builtin-show-branch.c
index cf9c071..09d8227 100644
--- a/builtin-show-branch.c
+++ b/builtin-show-branch.c
@@ -51,9 +51,9 @@ struct commit_name {
static void name_commit(struct commit *commit, const char *head_name, int nth)
{
struct commit_name *name;
- if (!commit->object.util)
- commit->object.util = xmalloc(sizeof(struct commit_name));
- name = commit->object.util;
+ if (!commit->util)
+ commit->util = xmalloc(sizeof(struct commit_name));
+ name = commit->util;
name->head_name = head_name;
name->generation = nth;
}
@@ -65,8 +65,8 @@ static void name_commit(struct commit *c
*/
static void name_parent(struct commit *commit, struct commit *parent)
{
- struct commit_name *commit_name = commit->object.util;
- struct commit_name *parent_name = parent->object.util;
+ struct commit_name *commit_name = commit->util;
+ struct commit_name *parent_name = parent->util;
if (!commit_name)
return;
if (!parent_name ||
@@ -80,12 +80,12 @@ static int name_first_parent_chain(struc
int i = 0;
while (c) {
struct commit *p;
- if (!c->object.util)
+ if (!c->util)
break;
if (!c->parents)
break;
p = c->parents->item;
- if (!p->object.util) {
+ if (!p->util) {
name_parent(c, p);
i++;
}
@@ -106,7 +106,7 @@ static void name_commits(struct commit_l
/* First give names to the given heads */
for (cl = list; cl; cl = cl->next) {
c = cl->item;
- if (c->object.util)
+ if (c->util)
continue;
for (i = 0; i < num_rev; i++) {
if (rev[i] == c) {
@@ -132,9 +132,9 @@ static void name_commits(struct commit_l
struct commit_name *n;
int nth;
c = cl->item;
- if (!c->object.util)
+ if (!c->util)
continue;
- n = c->object.util;
+ n = c->util;
parents = c->parents;
nth = 0;
while (parents) {
@@ -142,7 +142,7 @@ static void name_commits(struct commit_l
char newname[1000], *en;
parents = parents->next;
nth++;
- if (p->object.util)
+ if (p->util)
continue;
en = newname;
switch (n->generation) {
@@ -257,7 +257,7 @@ static void join_revs(struct commit_list
static void show_one_commit(struct commit *commit, int no_name)
{
char pretty[256], *cp;
- struct commit_name *name = commit->object.util;
+ struct commit_name *name = commit->util;
if (commit->object.parsed)
pretty_print_commit(CMIT_FMT_ONELINE, commit, ~0,
pretty, sizeof(pretty), 0, NULL, NULL);
diff --git a/commit.c b/commit.c
index 11fca55..5914200 100644
--- a/commit.c
+++ b/commit.c
@@ -711,12 +711,12 @@ int count_parents(struct commit * commit
void topo_sort_default_setter(struct commit *c, void *data)
{
- c->object.util = data;
+ c->util = data;
}
void *topo_sort_default_getter(struct commit *c)
{
- return c->object.util;
+ return c->util;
}
/*
diff --git a/commit.h b/commit.h
index c9de167..7c9ca3f 100644
--- a/commit.h
+++ b/commit.h
@@ -11,6 +11,7 @@ struct commit_list {
struct commit {
struct object object;
+ void *util;
unsigned long date;
struct commit_list *parents;
struct tree *tree;
diff --git a/name-rev.c b/name-rev.c
index 1f0135f..c29b93e 100644
--- a/name-rev.c
+++ b/name-rev.c
@@ -19,7 +19,7 @@ static void name_rev(struct commit *comm
const char *tip_name, int merge_traversals, int generation,
int deref)
{
- struct rev_name *name = (struct rev_name *)commit->object.util;
+ struct rev_name *name = (struct rev_name *)commit->util;
struct commit_list *parents;
int parent_number = 1;
@@ -41,7 +41,7 @@ static void name_rev(struct commit *comm
if (name == NULL) {
name = xmalloc(sizeof(rev_name));
- commit->object.util = name;
+ commit->util = name;
goto copy_data;
} else if (name->merge_traversals > merge_traversals ||
(name->merge_traversals == merge_traversals &&
@@ -108,7 +108,13 @@ static int name_ref(const char *path, co
static const char* get_rev_name(struct object *o)
{
static char buffer[1024];
- struct rev_name *n = (struct rev_name *)o->util;
+ struct rev_name *n;
+ struct commit *c;
+
+ if (o->type != TYPE_COMMIT)
+ return "undefined";
+ c = (struct commit *) o;
+ n = c->util;
if (!n)
return "undefined";
diff --git a/object.h b/object.h
index a0762b6..f4ee2e5 100644
--- a/object.h
+++ b/object.h
@@ -29,7 +29,6 @@ struct object {
unsigned flags : FLAG_BITS;
unsigned char sha1[20];
struct object_refs *refs;
- void *util;
};
extern int track_object_refs;
^ permalink raw reply related
* What's in git.git
From: Junio C Hamano @ 2006-06-18 0:48 UTC (permalink / raw)
To: git; +Cc: vger
It's been a while since I've done v1.4.0, and I haven't fully
caught up with the list traffic yet, but here is the current
status.
I'm planning to manage the v1.4.X series a bit differently
during this round. So far, they were supposed to be fix-only on
top of v1.4.0, but people who follow the maintenance series
(including the binary packages) missed out on too many good
stuff that happen on the "master" branch. Also presses like
lwn.net tended to cover the maint series which gets stale pretty
quickly.
So I'll first merge only post-1.4.0 fixes and additions to the
"master" branch until we are comfortable with its shape, tag it
as 1.4.1, and continue. Essentially, "next" and "pu" will
become the playpens (the first being "not proven but fixable"
changes, the latter being "under consideration, but will not be
missed if dropped" changes) their names originally implied, and
"master" will be what "maint" was supposed to be -- fixes and
good changes. The old fixes-only maintenance on "maint" branch
will be halted for now -- except maybe when some urgent fixes
are needed, I might do 1.4.X.Y like the kernel folks do.
* The 'master' branch has these since v1.4.0
Dennis Stosberg:
Make t4101-apply-nonl bring along its patches
Eric W. Biederman:
Don't parse any headers in the real body of an email message.
Eric Wong:
git-svn: t0000: add -f flag to checkout
git-svn: fix handling of filenames with embedded '@'
git-svn: eol_cp corner-case fixes
git-svn: restore original LC_ALL setting (or unset) for commit
git-svn: don't allow commit if svn tree is not current
git-svn: support -C<num> passing to git-diff-tree
git-svn: --branch-all-refs / -B support
git-svn: optimize --branch and --branch-all-ref
git-svn: support manually placed initial trees from fetch
git-svn: Move all git-svn-related paths into $GIT_DIR/svn
git-svn: minor cleanups, extra error-checking
git-svn: add --repack and --repack-flags= options
git-svn: add --shared and --template= options to pass to init-db
git-svn: add some functionality to better support branches in svn
git-svn: add UTF-8 message test
git-svn: add 'log' command, a facsimile of basic `svn log'
git-svn: add support for Perl SVN::* libraries
git-svn: make the $GIT_DIR/svn/*/revs directory obsolete
git-svn: avoid creating some small files
git-svn: fix several small bugs, enable branch optimization
git-svn: Eliminate temp file usage in libsvn_get_file()
git-svn: bugfix and optimize the 'log' command
git-svn: tests no longer fail if LC_ALL is not a UTF-8 locale
git-svn: svn (command-line) 1.0.x compatibility
git-svn: rebuild convenience and bugfixes
Florian Forster:
gitweb: Adding a `blame' interface.
gitweb: Make the `blame' interface in gitweb optional.
Fredrik Kuivinen:
blame: Add --time to produce raw timestamps
Jakub Narebski:
Update gitweb README: gitweb is now included with git
Junio C Hamano:
gitk: rereadrefs needs listrefs
fix git alias
t5100: mailinfo and mailsplit tests.
mailinfo: ignore blanks after in-body headers.
Linus Torvalds:
gitweb.cgi history not shown
Martin Langhoff:
cvsimport: ignore CVSPS_NO_BRANCH and impossible branches
cvsimport: complete the cvsps run before starting the import
cvsimport: keep one index per branch during import
Peter Eriksen:
Implement safe_strncpy() as strlcpy() and use it more.
Sean Estabrooks:
Add a "--notags" option for git-p4import.
Sven Verdoolaege:
git-cvsexportcommit.perl: fix typo
* The 'next' branch, in addition, has these.
Johannes Schindelin:
diff options: add --color
I would say this would be fine as is -- diff being quite
important part of the system, I just wanted to cook it for a
while.
Junio C Hamano:
read-tree: --prefix=<path>/ option.
write-tree: --prefix=<path>
read-tree: reorganize bind_merge code.
I'll have them graduate to "master" soon, as they do not seem
to hurt anybody.
fetch-pack: give up after getting too many "ack continue"
Maybe merge to "master" and see what it breaks.
shared repository: optionally allow reading to "others".
This should be ready. I just want to do another round of
check.
Paul Eggert:
date.c: improve guess between timezone offset and year.
This is more for the entertainment value than for practical
value ;-).
* The 'pu' branch, in addition, has these.
Johannes Schindelin:
Read configuration also from ~/.gitconfig
repo-config: learn the flag "--no-local"
I see Pasky has proposed another config change (this time,
not "also from" but "alternatively from") -- I am not sure
which one is more appropriate. Waiting for Johannes's
response to Pasky's message and hoping the list can agree on
a single patch series to apply to "next".
Teach diff about -b and -w flags
Yakov Lerner:
auto-detect changed prefix and/or changed build flags
I think this is fine, except that test-prefix-change target
is probably unneeded as Martin noticed.
^ permalink raw reply
* [ANNOUNCE] Cogito-0.17.3
From: Petr Baudis @ 2006-06-18 0:19 UTC (permalink / raw)
To: git; +Cc: linux-kernel
Hello,
cogito-0.17.3 was just released - bugfixes release on the latest
stable line of the Cogito user-friendly Git user interface.
Plenty of new stuff, mostly bugfixes - especially cg-admin-rewritehist
was particularily bug-ridden and Git 1.4.0 broke some backwards
compatibility, Cogito 0.17.3 should work smoothly with it again.
So, what's new?
* Many cg-admin-rewritehist bugfixes; note that -r semantics was
changed to match documentation, -k steps in to mean what -r used
to in practice
* Some documentation fixes
* Adjust to some Git 1.4.0 usage changes and new-style git-http-push
* Several other random things
Who did what:
Bertrand Jacquin:
Push over HTTP now works with refs/heads/foo instead of foo
Dennis Stosberg:
cg-clean fails on files beginning with a dash
Johannes Sixt:
cg-admin-rewritehist: Seed the commit map with the parents specified with -r
Enhance the rewritemap seeding when given symbolic commit ids
cg-admin-rewritehist: fix reappearing files with --filter-tree
cg-admin-rewritehist: Add the documented but missing --msg-filter option.
cg-admin-rewritehist: Must use the parent of the start rev to seed the map.
cg-admin-rewritehist: Support multiple parents of the start revision (-r).
cg-admin-rewritehist: Support partial rewriting of complicated history.
Jonas Fonseca:
ciabot: fix post-update hook description
Portfile: bring it up to date; use description from cogito.spec.in
Minor doc fixes
Fix section slicing so help options are not misplaced in cg-commit(1)
Martin Langhoff:
cg-status -- disambiguate parameters to git-diff-files
Pavel Roskin:
Fix cg-status with recent git versions
[PATCH 1/2] Fix cg-patch hanging on terminals with TOSTOP flag
[PATCH 2/2] Improve the tutorial script
Petr Baudis:
mkdir -p .git/info since git-init-db won't always create it
Separate git-diff-* file arguments by --
Export the $PATH we've set
Use local Cogito version when running the tutorial script
Fix cg-rm -r in a subdirectory
Do not export relpath - fixes cg-add -r in a subdir
Fix output of cg-status path with path given w/o trailing slash
cg-status: do not strip subdirs given in path specifier
Make cg-rm -r subdir fix actually safe
Fix broken tree timewarp with late git versions
Use tail -n +2 inst. of tail +2
Make testcases take input from /dev/null
Fix cg-tag calls changed by the backported update
Fix cg-admin-rewritehist -r
Indentation fix
cg-admin-rewritehist: Die in case of invalid revisions
cogito-0.17.3
Yann Dirson:
[PATCH 2/2] Catch history inconsistency in cg-admin-rewritehist
Fix cg-object-id to lookup parents in the Right Way
[PATCH 1/3] cg-admin-rewritehist: catch git-rev-list returning no commit
P.S.: See us at #git @ FreeNode!
Happy hacking,
--
Petr "Pasky the lousy poet" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: [RFD] gitweb configuration
From: Petr Baudis @ 2006-06-17 23:23 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e720r0$qdv$1@sea.gmane.org>
Dear diary, on Sun, Jun 18, 2006 at 12:48:12AM CEST, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> Petr Baudis <pasky@suse.cz> writes:
> > - we might want to have a configuration mechanism in place
> > before enhancing gitweb. My gut feeling is that we can use
> > [gitweb] section in project.git/config (and probably
> > duplicate first and deprecate later existing "description" as
> > well).
(Note that this is what Junio said, not me.)
> - gitweb installation options (gitweb version need not to correspond to
> git version, and we could theoretically have more than one gitweb
> installation while one git-core installation). It was proposed to put
> such options on gitweb.conf file in the same directory as gitweb.cgi.
> Unfortunately if one would want to use git-repo-config for managing
> gitweb.conf one is out of luck: git-repo-config uses $GIT_DIR/config.
In the longer term, perhaps this kind of configuration might land in the
global git configuration file.
---
[PATCH] Support for extracting configuration from different files
Add $GIT_CONFIG environment variable whose content is used instead
of .git/config if set. Also add $GIT_CONFIG_LOCAL as a
forward-compatibility cue for whenever we will finally come to support]
global configuration files (properly).
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
Documentation/git-repo-config.txt | 12 ++++++++++++
config.c | 12 +++++++++++-
2 files changed, 23 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-repo-config.txt b/Documentation/git-repo-config.txt
index d5142e0..803c0d5 100644
--- a/Documentation/git-repo-config.txt
+++ b/Documentation/git-repo-config.txt
@@ -73,6 +73,18 @@ OPTIONS
List all variables set in .git/config.
+ENVIRONMENT
+-----------
+
+GIT_CONFIG::
+ Take the configuration from the given file instead of .git/config.
+
+GIT_CONFIG_LOCAL::
+ Currently the same as $GIT_CONFIG; when Git will support global
+ configuration files, this will cause it to take the configuration
+ from the global configuration file in addition to the given file.
+
+
EXAMPLE
-------
diff --git a/config.c b/config.c
index c474970..42e1493 100644
--- a/config.c
+++ b/config.c
@@ -317,7 +317,17 @@ int git_config_from_file(config_fn_t fn,
int git_config(config_fn_t fn)
{
- return git_config_from_file(fn, git_path("config"));
+ const char *filename = git_path("config");
+ /* Forward-compatibility cue: $GIT_CONFIG makes git read _only_
+ * the given config file, $GIT_CONFIG_LOCAL will make it process
+ * it in addition to the global config file, the same way it would
+ * the per-repository config file otherwise. */
+ if (getenv("GIT_CONFIG")) {
+ filename = getenv("GIT_CONFIG");
+ } else if (getenv("GIT_CONFIG_LOCAL")) {
+ filename = getenv("GIT_CONFIG_LOCAL");
+ }
+ return git_config_from_file(fn, filename);
}
/*
--
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 related
* Re: [PATCH 1/3] cg-admin-rewritehist: catch git-rev-list returning no commit
From: Petr Baudis @ 2006-06-17 23:21 UTC (permalink / raw)
To: Yann Dirson; +Cc: git
In-Reply-To: <20060611120455.12116.14042.stgit@gandelf.nowhere.earth>
Dear diary, on Sun, Jun 11, 2006 at 02:04:55PM CEST, I got a letter
where Yann Dirson <ydirson@altern.org> said that...
> Signed-off-by: Yann Dirson <ydirson@altern.org>
> ---
>
> cg-admin-rewritehist | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/cg-admin-rewritehist b/cg-admin-rewritehist
> index 861c7f6..fe3f210 100755
> --- a/cg-admin-rewritehist
> +++ b/cg-admin-rewritehist
> @@ -199,6 +199,10 @@ done
> git-rev-list --topo-order HEAD $startrev | tac >../revs
> commits=$(cat ../revs | wc -l)
>
> +if [ $commits -eq 0 ]; then
> + die "Found nothing to rewrite"
> +fi
> +
> i=0
> while read commit; do
> i=$((i+1))
Thanks, applied.
Dear diary, on Sun, Jun 11, 2006 at 02:04:57PM CEST, I got a letter
where Yann Dirson <ydirson@altern.org> said that...
> Signed-off-by: Yann Dirson <ydirson@altern.org>
> ---
>
> cg-admin-rewritehist | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/cg-admin-rewritehist b/cg-admin-rewritehist
> index fe3f210..7cbdb30 100755
> --- a/cg-admin-rewritehist
> +++ b/cg-admin-rewritehist
> @@ -154,6 +154,8 @@ while optparse; do
> if optparse -d=; then
> tempdir="$OPTARG"
> elif optparse -r=; then
> + git-rev-parse "$OPTARG" >/dev/null || die "Unknown revision '$OPTARG'"
> + git-rev-parse "$OPTARG^" >/dev/null || die "Revision '$OPTARG' does not have parents, check what you really want"
> startrev="^$OPTARG^ $OPTARG $startrev"
> startrevparents="$OPTARG $startrevparents"
> elif optparse --env-filter=; then
Thanks, I've adapted it to the current codebase.
Dear diary, on Sun, Jun 11, 2006 at 02:05:00PM CEST, I got a letter
where Yann Dirson <ydirson@altern.org> said that...
> This is a fix for 95621e54cedef1c4a270af5570a72fc1331b5fcb.
>
> Signed-off-by: Yann Dirson <ydirson@altern.org>
> ---
>
> cg-admin-rewritehist | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/cg-admin-rewritehist b/cg-admin-rewritehist
> index 7cbdb30..6dd8b92 100755
> --- a/cg-admin-rewritehist
> +++ b/cg-admin-rewritehist
> @@ -157,7 +157,7 @@ while optparse; do
> git-rev-parse "$OPTARG" >/dev/null || die "Unknown revision '$OPTARG'"
> git-rev-parse "$OPTARG^" >/dev/null || die "Revision '$OPTARG' does not have parents, check what you really want"
> startrev="^$OPTARG^ $OPTARG $startrev"
> - startrevparents="$OPTARG $startrevparents"
> + startrevparents="$OPTARG^ $startrevparents"
> elif optparse --env-filter=; then
> filter_env="$OPTARG"
> elif optparse --tree-filter=; then
Thanks; I've already applied a patch similar in spirit from someone
else.
--
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
* [RFD] gitweb configuration
From: Jakub Narebski @ 2006-06-17 22:48 UTC (permalink / raw)
To: git
Petr Baudis <pasky@suse.cz> writes:
> - we might want to have a configuration mechanism in place
> before enhancing gitweb. My gut feeling is that we can use
> [gitweb] section in project.git/config (and probably
> duplicate first and deprecate later existing "description" as
> well).
The problem is we have different types of configuration in gitweb, and we
should take care where to put appropriate configuration options/variables.
- build time options, like $gitexecdir ($gitbin now) or $gitweb_version
($version now) which could be set at build time a la ./configure i.e
my $gitexecdir = "@GIT_EXEC_DIR@"; or something like that.
- gitweb installation options (gitweb version need not to correspond to
git version, and we could theoretically have more than one gitweb
installation while one git-core installation). It was proposed to put
such options on gitweb.conf file in the same directory as gitweb.cgi.
Unfortunately if one would want to use git-repo-config for managing
gitweb.conf one is out of luck: git-repo-config uses $GIT_DIR/config.
Among installation options we could put also defaults for repository-wide
(repository specific) options.
Global gitweb options include:
* $projectroot - absolute fs-path which will be prepended to the
project path, i.e. where projects to display are located (dir)
* $projects_list - source of projects list (file)
* $home_text - html text to include at home page (file)
* $stylesheet - default gitweb stylesheet (file)
* $git_temp - where to place temporary files (dir)
- repository specific options, of which gitweb for now uses only
$GIT_DIR/description, and which could use repository configuration,
[gitweb] section.
Repository specific options [can] include:
* description - One line description of repository;
theoretical problem: HTML escaping.
* blame - to make 'blame'/'annotate' interface available.
* blobmimemapfile - for repository specific mime map for blob_plain.
* favicon - if default favicon is not used.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git-1.4.0 make problems
From: Junio C Hamano @ 2006-06-17 22:40 UTC (permalink / raw)
To: Rene Scharfe; +Cc: git
In-Reply-To: <44947A43.7070909@lsrfire.ath.cx>
Rene Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> Hrm. Is the header really that unfriendly? With a non-POSIX tar you
> get an extra file and a nice, if somewhat cryptic, reminder to upgrade
> your archiver. ;-) Seriously, this is way below my annoyance-radar,
> but I'm obviously biased.
I do not mind tar-tree producing the header by default and
having to override it with ^{tree} -- actually I think it is a
good default. I think that particular use in our Makefile,
however, is not necessary.
> What do you think about the following patch for starters?
Documentation updates are always welcome, and I think this is a
good change. Thanks.
^ permalink raw reply
* Re: [PATCH] gitweb: safely output binary files for 'blob_plain' action
From: Junio C Hamano @ 2006-06-17 22:30 UTC (permalink / raw)
To: Petr Baudis; +Cc: Jakub Narebski, git, Kay Sievers
In-Reply-To: <20060617220106.GJ2609@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
>> In other words, something like this:
>>
>> (in torvalds/linux-2.6.git/config)
>>
>> [gitweb]
>> description = "Linus's kernel tree"
>> ; defaultblobcharset = "latin1"
>> blobmimemapfile = "mime-map"
>>
>> (in torvalds/linux-2.6.git/mime-map, first match decides)
>>
>> fs/nls/nls_euc-jp.c text/plain; charset=euc_jp
>> *.c text/plain; charset=utf-8
>> *.h text/plain; charset=utf-8
>
> You could as well just support the mime.types format and load
> /etc/mime.types for this kind of mapping (see below for a patch). The
> advantage is that this pretty much covers all the MIME types you will
> need, the disadvantage is that it's less flexible and the charset part
> wouldn't probably fit in nicely.
Ah, I thought Jakub's patch was already taking care of
mime.types but apparently that was not the case. As you say,
using /etc/mime.types for this is obviously a good point to
start.
> We could obviously do both. :-)
The point of my example was about charset part; comparing the
suffix part only is not good enough for .po files, so we should
obviously do both.
^ permalink raw reply
* Re: git-1.4.0 make problems
From: Rene Scharfe @ 2006-06-17 22:11 UTC (permalink / raw)
To: Michael Somos; +Cc: Git Mailing List
In-Reply-To: <200606171016.k5HAGQ1D005560@grail.cba.csuohio.edu>
Michael Somos wrote:
> A good suggestion, but I am a newbie as you can tell, and would prefer to
> play in a sandbox for some time before I would attempt it.
You already sent a diff in your first message, so you're not that much
of a newbie. :-)
Thanks for telling us about your first encounter with git, by the way.
Take your time, and have fun learning and using git!
René
^ permalink raw reply
* Re: [PATCH] gitweb: safely output binary files for 'blob_plain' action
From: Petr Baudis @ 2006-06-17 22:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git, Kay Sievers
In-Reply-To: <7v8xnv8ozp.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sat, Jun 17, 2006 at 11:13:30PM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> - we might want to have a configuration mechanism in place
> before enhancing gitweb. My gut feeling is that we can use
> [gitweb] section in project.git/config (and probably
> duplicate first and deprecate later existing "description" as
> well).
Agreed. (I planned to back this up with a patch, then looked at the
clock.)
Hmm, after I'm over my exam period, since there's now another .pl thing
in the git tree I might start working on some kind of universal Git.pm
interface. I'm gonna need it for Cogito in the longer term anyway. ;-)
> - the blob charset should be per path -- otherwise the feature
> would be not useful for projects that maintains bunch of po
> files.
>
> In other words, something like this:
>
> (in torvalds/linux-2.6.git/config)
>
> [gitweb]
> description = "Linus's kernel tree"
> ; defaultblobcharset = "latin1"
> blobmimemapfile = "mime-map"
>
> (in torvalds/linux-2.6.git/mime-map, first match decides)
>
> fs/nls/nls_euc-jp.c text/plain; charset=euc_jp
> *.c text/plain; charset=utf-8
> *.h text/plain; charset=utf-8
You could as well just support the mime.types format and load
/etc/mime.types for this kind of mapping (see below for a patch). The
advantage is that this pretty much covers all the MIME types you will
need, the disadvantage is that it's less flexible and the charset part
wouldn't probably fit in nicely.
We could obviously do both. :-)
---
[PATCH] Support for the standard mime.types map in gitweb
gitweb will try to look up the filename mimetype in /etc/mime.types
and optionally a user-configured mime.types map as well.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
Depends on Jakub's mime patches.
gitweb/gitweb.cgi | 44 ++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.cgi b/gitweb/gitweb.cgi
index 9250548..0116531 100755
--- a/gitweb/gitweb.cgi
+++ b/gitweb/gitweb.cgi
@@ -46,6 +46,11 @@ # default blob_plain mimetype and defaul
my $default_blob_plain_mimetype = 'text/plain';
my $default_text_plain_charset = undef; # was: 'utf-8'
+# file to use for guessing MIME types before trying /etc/mime.types
+# (relative to the current git repository)
+my $mimetypes_file = undef;
+
+
# input validation and dispatch
my $action = $cgi->param('a');
if (defined $action) {
@@ -1414,6 +1419,40 @@ sub git_blob {
git_footer_html();
}
+sub mimetype_guess_file {
+ my $filename = shift;
+ my $mimemap = shift;
+ -r $mimemap or return undef;
+
+ my %mimemap;
+ open(MIME, $mimemap) or return undef;
+ while (<MIME>) {
+ my ($mime, $exts) = split(/\t+/);
+ my @exts = split(/\s+/, $exts);
+ foreach my $ext (@exts) {
+ $mimemap{$ext} = $mime;
+ }
+ }
+ close(MIME);
+
+ $filename =~ /\.(.*?)$/;
+ return $mimemap{$1};
+}
+
+sub mimetype_guess {
+ my $filename = shift;
+ my $mime;
+ $filename =~ /\./ or return undef;
+
+ if ($mimetypes_file) {
+ my $file = $mimetypes_file;
+ $file =~ m#^/# or $file = "$projectroot/$path/$file";
+ $mime = mimetype_guess_file($filename, $file);
+ }
+ $mime ||= mimetype_guess_file($filename, '/etc/mime.types');
+ return $mime;
+}
+
sub git_blob_plain_mimetype {
my $fd = shift;
my $filename = shift;
@@ -1421,6 +1460,11 @@ sub git_blob_plain_mimetype {
# just in case
return $default_blob_plain_mimetype unless $fd;
+ if ($filename) {
+ my $mime = mimetype_guess($filename);
+ $mime and return $mime;
+ }
+
if (-T $fd) {
return 'text/plain' .
($default_text_plain_charset ? '; charset='.$default_text_plain_charset : '');
--
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 related
* Re: git-1.4.0 make problems
From: Rene Scharfe @ 2006-06-17 21:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Michael Somos
In-Reply-To: <7vbqsra4d2.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano schrieb:
> I've been using (in my non-git related project aka day-job)
>
> git-tar-tree HEAD^{tree} $(PROJECT)-$(RELNAME) >$(PROJECT)-$(RELNAME).tar
>
> to avoid this. Although all of my target machines have gtar that are
> recent enough so I do not need it, but when the tarball has version
> string in its name, there is not much point having the pax header to
> identify the contents (where the pax header shines is when the result
> does not have the version string in its name).
>
> This might be a sensible thing to do for our dist target as well.
> The product of our dist target is for people who build from the
> source to bootstrap themselves (if they have git, then fetching the
> source using git is preferred anyway), as opposed to using pre-built
> binaries, so being as friendly as we can to different implementations
> of tar is a good thing.
Hrm. Is the header really that unfriendly? With a non-POSIX tar you
get an extra file and a nice, if somewhat cryptic, reminder to upgrade
your archiver. ;-) Seriously, this is way below my annoyance-radar,
but I'm obviously biased.
What do you think about the following patch for starters? It adds an
example to the git-tar-tree documentation showing your "tree trick"
and corrects two formatting buglets.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
diff --git a/Documentation/git-tar-tree.txt b/Documentation/git-tar-tree.txt
index 831537b..c93a8fe 100644
--- a/Documentation/git-tar-tree.txt
+++ b/Documentation/git-tar-tree.txt
@@ -45,11 +45,16 @@ git tar-tree HEAD | (cd /var/tmp/ && mkd
latest commit on the current branch, and extracts it in
`/var/tmp/junk` directory.
-git tar-tree v2.6.17 linux-2.6.17 | gzip >linux-2.6.17.tar.gz
+git tar-tree v2.6.17 linux-2.6.17 | gzip >linux-2.6.17.tar.gz::
Create a tarball for v2.6.17 release.
-git tar-tree --remote=example.com:git.git v0.99 >git-0.99.tar
+git tar-tree v2.6.17{caret}\{tree\} linux-2.6.17 | gzip >linux-2.6.17.tar.gz::
+
+ Create a tarball for v2.6.17 release, but without a
+ global extended pax header.
+
+git tar-tree --remote=example.com:git.git v0.99 >git-0.99.tar::
Get a tarball v0.99 from example.com.
^ permalink raw reply related
* Post 1.4.0 merge status
From: Junio C Hamano @ 2006-06-17 21:38 UTC (permalink / raw)
To: git
I thank everybody who submitted patches while I was away.
I'm trying to catch up with you and have merged the following so
far to "master". Will push them out shortly after I review them
for the last time, hopefully sometime today:
- pulled git-svn updates from Eric Wong (I first applied the
patches from the list to a test branch, and compared it with
the result of the pull onto the master -- they match, so I
decided to take the pull result).
- pulled gitk from Paul to fix "Re-read references".
- git whatchanged to show full-history from Linus.
- Portability of t4101 test for diff implementations that do
not do "\No newline..." from Dennis Stosberg.
- mailinfo fix from Eric W Biederman not to confuse "From: "
lines in the middle of log message as an in-body header.
- gitweb 'blame' that can be switched on/off from Florian
Foster.
- gitweb README update from Jakub.
- git-blame updates to add -time from Fredrik.
- three patches to cvsimport from Martin.
- strlcpy from Peter Eriksen.
- a p4import update from Sean.
- cvsexportcommit typofix from Sven Verdoolaege.
I'll be looking at these after the above;
- 2 patches to diff (color and -b/w) from Johannes.
- avoiding "make prefix=A ; make prefix=B install" confusion
from Yakov.
I've queued the following to look at in the next round;
- format-patch -s fix from Eric W Biederman;
- 7+1 patches to make am and commands required for it built-in
from Lukas.
- raw-blob output from gitweb by Jakub.
- big "SHA1"->"SHA-1" and other documentation updates from
Horst; I was hoping to merge this while flying over Pacific,
but I seemed to have duplicates and was too tired and fell
asleep.
^ permalink raw reply
* Re: [PATCH for cvsps] Handle cvs repo with modules
From: Yann Dirson @ 2006-06-17 21:33 UTC (permalink / raw)
To: Alexander Litvinov; +Cc: git, cvsps
In-Reply-To: <200606151249.17518.lan@academsoft.ru>
On Thu, Jun 15, 2006 at 12:49:17PM +0700, Alexander Litvinov wrote:
> Parse 'Working file' lines from cvs log output. This alow to work
> with cvs repos with modules. To enable this you need to add
> --no-rlog to cvsps command line args. This patch was made to import
> such repo into git. But git-cvsimport can't load such data.
Just forgot to mention it, but this patch was applied to master.
Thanks,
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* Re: [BUG] stgit branch renaming into new dir crashes
From: Yann Dirson @ 2006-06-17 21:31 UTC (permalink / raw)
To: Catalin Marinas; +Cc: GIT list
In-Reply-To: <b0943d9e0606160506g23179531v7921b67ac0e0aa0d@mail.gmail.com>
On Fri, Jun 16, 2006 at 01:06:56PM +0100, Catalin Marinas wrote:
> On 13/06/06, Yann Dirson <ydirson@altern.org> wrote:
> >When trying to rename a branch to a name including a slash, there is
> >no explicit creation of leading dirs, and stgit crashes:
> >
> >$ stg branch -r multitag dev/multitag
> >Traceback (most recent call last):
> [...]
>
> What version of StGIT are you using? It seems to be OK with 0.10.
Right, that was with 0.9, and works perfectly with 0.10. Relying too
much on /usr/bin/ ... :)
Best regards,
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* Re: [PATCH] cvsimport: ignore CVSPS_NO_BRANCH and impossible branches
From: Yann Dirson @ 2006-06-17 21:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Martin Langhoff, git
In-Reply-To: <7vzmgb8plx.fsf@assigned-by-dhcp.cox.net>
On Sat, Jun 17, 2006 at 02:00:10PM -0700, Junio C Hamano wrote:
> Martin Langhoff <martin@catalyst.net.nz> writes:
>
> > cvsps output often contains references to CVSPS_NO_BRANCH, commits that it
> > could not trace to a branch. Ignore that branch.
> >
> > Additionally, cvsps will sometimes draw circular relationships between
> > branches -- where two branches are recorded as opening from the other.
> > In those cases, and where the ancestor branch hasn't been seen, ignore
> > it.
>
> This sounds more like an workaround than a real fix to me,
> although I'd apply it for now. I see Yann is collecting cvsps
> patches but maybe there will be a real fix soonish?
I have not dig yet into the cases that trigger CVSPS_NO_BRANCH so
can't make any promise, unless someone comes in with a patch already
written :)
Since the patch seems to ensure the user gets warned when a branch
gets ignored this way, allowing it in could probably allow at least
some people to have cvsimport does a partial job, rather than failing
midway. Maybe a final warning when all patchsets could not be
imported could be issued, so the existing ones do not get simply lost
in the verbose output.
Best regards,
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* Re: [PATCH] gitweb: safely output binary files for 'blob_plain' action
From: Junio C Hamano @ 2006-06-17 21:13 UTC (permalink / raw)
To: Petr Baudis; +Cc: Jakub Narebski, git, Kay Sievers
In-Reply-To: <20060617153540.GI2609@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Dear diary, on Sat, Jun 17, 2006 at 01:32:15PM CEST, I got a letter
> where Jakub Narebski <jnareb@gmail.com> said that...
>> Introduced new configuration variables: $default_blob_plain_mimetype
>> and $default_text_plain_charset (only 'utf-8' is guaranteed to work
>> for the latter).
>
> Nah, defaulting to 'utf-8' is horrible - usually, you just don't have a
> clue and should refrain from sending any charset information at all, so
> I think undef is a much saner default.
Concurred. I see Jakub's second patch to make this
configurable, but I wonder about a few things:
- we might want to have a configuration mechanism in place
before enhancing gitweb. My gut feeling is that we can use
[gitweb] section in project.git/config (and probably
duplicate first and deprecate later existing "description" as
well).
- the blob charset should be per path -- otherwise the feature
would be not useful for projects that maintains bunch of po
files.
In other words, something like this:
(in torvalds/linux-2.6.git/config)
[gitweb]
description = "Linus's kernel tree"
; defaultblobcharset = "latin1"
blobmimemapfile = "mime-map"
(in torvalds/linux-2.6.git/mime-map, first match decides)
fs/nls/nls_euc-jp.c text/plain; charset=euc_jp
*.c text/plain; charset=utf-8
*.h text/plain; charset=utf-8
I do not think defaultblobcharset above is a good idea though.
You could just have the last entry in mime-map file to be:
* text/plain; charset=latin1
^ permalink raw reply
* Re: [PATCH] cvsimport: ignore CVSPS_NO_BRANCH and impossible branches
From: Junio C Hamano @ 2006-06-17 21:00 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git, Yann Dirson
In-Reply-To: <11500135293734-git-send-email-martin@catalyst.net.nz>
Martin Langhoff <martin@catalyst.net.nz> writes:
> cvsps output often contains references to CVSPS_NO_BRANCH, commits that it
> could not trace to a branch. Ignore that branch.
>
> Additionally, cvsps will sometimes draw circular relationships between
> branches -- where two branches are recorded as opening from the other.
> In those cases, and where the ancestor branch hasn't been seen, ignore
> it.
This sounds more like an workaround than a real fix to me,
although I'd apply it for now. I see Yann is collecting cvsps
patches but maybe there will be a real fix soonish?
^ permalink raw reply
* Re: git-1.4.0 make problems
From: Junio C Hamano @ 2006-06-17 20:56 UTC (permalink / raw)
To: Rene Scharfe; +Cc: git, Michael Somos
In-Reply-To: <4493A810.6010706@lsrfire.ath.cx>
Rene Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> | 1) The untar process creates a stray file "pax_global_header".
> | I am using GNU tar v1.13.22 and I get this message :
> |
> | ======================================================================
> | > tar jxf ~/u/source/git-1.4.0.tar.bz2
> | tar: pax_global_header: Unknown file type 'g', extracted as normal
> | file
> | ======================================================================
>
> You can ignore or delete that file. It is a pax extended global header,
> containing the git commit ID as a comment. GNU tar started supporting
> pax headers with version 1.13.93 (released 2004-02-23). Version 1.13.22
> was released on 2001-08-29, by the way. May I ask what operating system
> and version you are using?
I've been using (in my non-git related project aka day-job)
git-tar-tree HEAD^{tree} $(PROJECT)-$(RELNAME) >$(PROJECT)-$(RELNAME).tar
to avoid this. Although all of my target machines have gtar
that are recent enough so I do not need it, but when the tarball
has version string in its name, there is not much point having
the pax header to identify the contents (where the pax header
shines is when the result does not have the version string in
its name).
This might be a sensible thing to do for our dist target as
well. The product of our dist target is for people who build
from the source to bootstrap themselves (if they have git, then
fetching the source using git is preferred anyway), as opposed
to using pre-built binaries, so being as friendly as we can to
different implementations of tar is a good thing.
^ permalink raw reply
* Re: [PATCH] Update gitweb README: gitweb is now included with git
From: Junio C Hamano @ 2006-06-17 20:46 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e708tr$ea8$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> ---
> ftp://ftp.kernel.org/pub/software/scm/gitweb/ and
> http://www.kernel.org/pub/software/scm/gitweb/ are empty.
>
> http://www.kernel.org/git/?p=git/gitweb.git;a=summary
> does not exist.
Thanks.
^ permalink raw reply
* Re: Shrink "struct object" a bit
From: Linus Torvalds @ 2006-06-17 19:13 UTC (permalink / raw)
To: Philip Pokorny; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <44942176.1070107@mindspring.com>
On Sat, 17 Jun 2006, Philip Pokorny wrote:
>
> A minor thing, but doesn't this mean the "report_missing" message would change
> from:
>
> > Cannot obtain needed object ab12cdef1234567890abcd
> > while processing commit fedcbadeadbeefdeadbe
>
> to
>
> > Cannot obtain needed none ab12cdef1234567890abcd
> > while processing commit fedcbadeadbeefdeadbe
Yeah. I guess you could either just keep the old conditional, or just
change the object type-name for the unspecified mode 0 to something like
"untyped object" which would cause a much more readable errors.
Linus
^ 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