* Re: Automatically remote prune
From: Petr Baudis @ 2009-11-06 10:31 UTC (permalink / raw)
To: Jay Soffian; +Cc: Junio C Hamano, John Tapsell, Git List
In-Reply-To: <76718490911051638w7cd5306bx65ed8d9ac525d2c3@mail.gmail.com>
On Thu, Nov 05, 2009 at 07:38:39PM -0500, Jay Soffian wrote:
> On Thu, Nov 5, 2009 at 7:17 PM, Petr Baudis <pasky@suse.cz> wrote:
> > On Thu, Nov 05, 2009 at 06:09:03PM -0500, Jay Soffian wrote:
> >> Actually, mirror mode applies to push only. Unless I'm missing
> >> something obvious.
> >
> > Perhaps you are, mirror mode applies to fetch as well; that's how e.g.
> > repo.or.cz mirror mode is done currently.
>
> Can you please be more specific? There is no mention of mirror in
> builtin-fetch.c, only builtin-push.c. Further, the docs for
> "remote.<name>.mirror" indicate it's a push option only.
>
> So please explain what you mean by "that's how repo.or.cz mirror mode is done".
Ok, I got a bit confused there. :-) For fetches, it just sets up the
refspec to point to main namespace instead of refs/remote/, of course it
doesn't use the remote.*.mirror config. I'm not sure what Junio meant by
the change being easy, seeing that push uses a technical trick in
send-pack that doesn't seem to be straightforwardly applicable to
fetch... but I don't know this part of code too well.
--
Petr "Pasky" Baudis
A lot of people have my books on their bookshelves.
That's the problem, they need to read them. -- Don Knuth
^ permalink raw reply
* [PATCH] git_odb_open ckeck for valid path to database
From: Esben Mose Hansen @ 2009-11-06 12:32 UTC (permalink / raw)
To: ae; +Cc: git, Esben Mose Hansen
---
src/errors.c | 1 +
src/git/common.h | 3 +++
src/odb.c | 13 +++++++++++++
tests/t0204-opendb_errors.c | 38 ++++++++++++++++++++++++++++++++++++++
4 files changed, 55 insertions(+), 0 deletions(-)
create mode 100644 tests/t0204-opendb_errors.c
diff --git a/src/errors.c b/src/errors.c
index f348997..074c01c 100644
--- a/src/errors.c
+++ b/src/errors.c
@@ -36,6 +36,7 @@ static struct {
{ GIT_ENOTOID, "Not a git oid" },
{ GIT_ENOTFOUND, "Object does not exist in the scope searched" },
{ GIT_ENOMEM, "Not enough space" },
+ { GIT_ENOTDIR, "Not a directory" }
};
const char *git_strerror(int num)
diff --git a/src/git/common.h b/src/git/common.h
index c470e0e..96f2971 100644
--- a/src/git/common.h
+++ b/src/git/common.h
@@ -65,6 +65,9 @@
/** Consult the OS error information. */
#define GIT_EOSERR (GIT_ERROR - 4)
+/** The path is not a directory */
+#define GIT_ENOTDIR (GIT_ERROR - 5)
+
GIT_BEGIN_DECL
/** A revision traversal pool. */
diff --git a/src/odb.c b/src/odb.c
index 6d646a4..89d6d03 100644
--- a/src/odb.c
+++ b/src/odb.c
@@ -30,6 +30,10 @@
#include "hash.h"
#include "odb.h"
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <unistd.h>
+
#define GIT_PACK_NAME_MAX (5 + 40 + 1)
struct git_pack {
git_odb *db;
@@ -1023,6 +1027,15 @@ int git_odb_open(git_odb **out, const char *objects_dir)
free(db);
return GIT_ERROR;
}
+ struct stat objects_dir_stat;
+ if (stat(db->objects_dir, &objects_dir_stat)) {
+ free(db);
+ return GIT_EOSERR;
+ }
+ if (!S_ISDIR(objects_dir_stat.st_mode)) {
+ free(db);
+ return GIT_ENOTDIR;
+ }
gitlck_init(&db->lock);
diff --git a/tests/t0204-opendb_errors.c b/tests/t0204-opendb_errors.c
new file mode 100644
index 0000000..e9b52c9
--- /dev/null
+++ b/tests/t0204-opendb_errors.c
@@ -0,0 +1,38 @@
+#include "test_lib.h"
+#include "test_helpers.h"
+#include <git/odb.h>
+#include "fileops.h"
+
+static char *odb_dir = "test-objects";
+
+static unsigned char one_bytes[] = {
+ 0x31, 0x78, 0x9c, 0xe3, 0x02, 0x00, 0x00, 0x0b,
+ 0x00, 0x0b,
+};
+
+static unsigned char one_data[] = {
+ 0x0a,
+};
+
+static object_data one = {
+ one_bytes,
+ sizeof(one_bytes),
+ "8b137891791fe96927ad78e64b0aad7bded08bdc",
+ "blob",
+ "test-objects/8b",
+ "test-objects/8b/137891791fe96927ad78e64b0aad7bded08bdc",
+ one_data,
+ sizeof(one_data),
+};
+
+BEGIN_TEST(opendb_errors)
+ git_odb *db;
+ int error = git_odb_open(&db, odb_dir);
+ must_be_true(error == GIT_EOSERR);
+ must_be_true(errno == ENOENT);
+ must_pass(write_object_files(odb_dir, &one));
+ error = git_odb_open(&db, one.file);
+ must_be_true(error == GIT_ENOTDIR);
+
+ must_pass(remove_object_files(odb_dir, &one));
+END_TEST
--
1.6.3.3
^ permalink raw reply related
* gitk: Update Japanese translation
From: Mizar @ 2009-11-06 13:57 UTC (permalink / raw)
To: paulus, git, gitster
[-- Attachment #1: Type: text/plain, Size: 2479 bytes --]
The main changes are as follows.
Several issues remain and is pending because there is no improvement.
http://github.com/mizar/gitk/issues
| msgid ""
| "\n"
| "Gitk - a commit viewer for git\n"
| "\n"
| -"Copyright c 2005-2008 Paul Mackerras\n"
| +"Copyright © 2005-2008 Paul Mackerras\n"
| "\n"
| "Use and redistribute under the terms of the GNU General Public License"
| msgstr ""
| "\n"
| "Gitk - gitコミットビューア\n"
| "\n"
| -"Copyright c 2005-2008 Paul Mackerras\n"
| +"Copyright © 2005-2008 Paul Mackerras\n"
| "\n"
| "使用および再配布は GNU General Public License に従ってください"
| msgid "Author"
| -msgstr "作成者"
| +msgstr "作者"
| msgid "Committer"
| -msgstr "コミットした人"
| +msgstr "コミット者"
| msgid "Write commit to file"
| -msgstr "コミットをファイルに書き込む"
| +msgstr "コミットをファイルに書き出す"
| msgid "Error writing commit to file: %s"
| -msgstr "ファイルへのコミット書き込みエラー: %s"
| +msgstr "ファイルへのコミット書き出しエラー: %s"
| msgid "Write"
| -msgstr "書き込み"
| +msgstr "書き出し"
| msgid "Error writing commit:"
| -msgstr "コミット書き込みエラー:"
| +msgstr "コミット書き出しエラー:"
| -msgstr "この子孫を見つけてマークする"
| +msgstr "これとマークをつけた所との子孫を見つける"
| msgid "<Shift-Up>\tFind backwards (upwards, later commits)"
| -msgstr "<Shift-Up>\t後ろを検索 (上方・後のコミット)"
| +msgstr "<Shift-Up>\t後方を検索 (上方の・新しいコミット)"
| msgid "<Shift-Down>\tFind forwards (downwards, earlier commits)"
| -msgstr "<Shift-Down>\t前を検索（下方・前のコミット）"
| +msgstr "<Shift-Down>\t前方を検索（下方の・古いコミット）"
| msgid "Author:"
| -msgstr "作成者:"
| +msgstr "作者:"
| msgid "Committer:"
| -msgstr "コミットした人:"
| +msgstr "コミット者:"
| msgid "Children"
| -msgstr "子供達"
| +msgstr "子"
| +msgid "Interface"
| +msgstr "インターフェイス"
| +msgid "interface"
| +msgstr "インターフェイス"
| -msgid ""
| -"Sorry, gitk cannot run with this version of Tcl/Tk.\n"
| -" Gitk requires at least Tcl/Tk 8.4."
| -msgstr ""
| -"申し訳ありませんが、このバージョンの Tcl/Tk では gitk を実行できません。\n"
| -" Gitk は最低でも Tcl/Tk 8.4 を必要とします。"
[-- Attachment #2: patch0.patch.gz --]
[-- Type: application/x-gzip, Size: 9048 bytes --]
[-- Attachment #3: ja.po.gz --]
[-- Type: application/x-gzip, Size: 8152 bytes --]
^ permalink raw reply
* gitk : french translation
From: Emmanuel Trillaud @ 2009-11-06 14:05 UTC (permalink / raw)
To: Git Mailing List
[-- Attachment #1: Type: text/plain, Size: 304 bytes --]
Hello all,
I made an attempt to translate gitk in french. The translation is
_almost_ complete
and I would really appreciate to have some comments by the french people here.
I also need to improve some translations I am not happy with so it's
really a work in progress.
Best regards,
Emmanuel Trillaud
[-- Attachment #2: fr.po.bz2 --]
[-- Type: application/x-bzip2, Size: 6915 bytes --]
^ permalink raw reply
* How to merge into my working copy?
From: Patrick Doyle @ 2009-11-06 14:53 UTC (permalink / raw)
To: git
I would like to pull a set of changes from a branch back into the
working copy of my current branch without affecting the index. I
can't figure out the right combination of --commit, --no-commit, -ff,
-no-ff, --log, --no-log, --squash, --no-squash, etc... options to use
with git-merge.
Basically, I created a branch off my mainline branch a few days ago.
Made some commits on that branch. Then went back to my mainline
branch, made a few commits there, and now I would like to make my
working copy look like a merge of its current state with the changes
from the branch, minus any associated commits.
I probably should have just used git-stash to tuck those changes away,
but I didn't.
--wpd
^ permalink raw reply
* Re: How to merge into my working copy?
From: Bruce Stephens @ 2009-11-06 14:59 UTC (permalink / raw)
To: Patrick Doyle; +Cc: git
In-Reply-To: <e2a1d0aa0911060653t7bbb54ebp948eac0dffeaba64@mail.gmail.com>
Patrick Doyle <wpdster@gmail.com> writes:
[...]
> Basically, I created a branch off my mainline branch a few days ago.
> Made some commits on that branch. Then went back to my mainline
> branch, made a few commits there, and now I would like to make my
> working copy look like a merge of its current state with the changes
> from the branch, minus any associated commits.
>
> I probably should have just used git-stash to tuck those changes away,
> but I didn't.
Rather than spending time worrying about optimal ways to do this,
wouldn't it work just to do merge (to get the right tree) followed by
rebase -i to get the commits in the way you want (removing the merge,
anyway)?
[...]
^ permalink raw reply
* [PATCH] gitweb: Fix blob linenr links in pathinfo mode
From: Petr Baudis @ 2009-11-06 15:08 UTC (permalink / raw)
To: git; +Cc: Petr Baudis
In pathinfo mode, we use <base href> that refers to the base location
of gitweb in order for various external media links to work well.
However, this means that for the page to refer to itself, it must
regenerate full link, and this is exactly what the blob view page
did not do for line numbers.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
gitweb/gitweb.perl | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index e4cbfc3..62325ea 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -5127,7 +5127,8 @@ sub git_blob {
chomp $line;
$nr++;
$line = untabify($line);
- printf "<div class=\"pre\"><a id=\"l%i\" href=\"#l%i\" class=\"linenr\">%4i</a> %s</div>\n",
+ printf "<div class=\"pre\"><a id=\"l%i\" href=\"" . href(-replay => 1)
+ . "#l%i\" class=\"linenr\">%4i</a> %s</div>\n",
$nr, $nr, $nr, esc_html($line, -nbsp=>1);
}
}
--
tg: (8cc62c1..) t/blob/pathinfo (depends on: vanilla/master)
^ permalink raw reply related
* [PATCH] gitweb: Refactor project list routines
From: Petr Baudis @ 2009-11-06 15:10 UTC (permalink / raw)
To: git; +Cc: Petr Baudis
This is a preparatory patch for separation of project list and frontpage
actions; it factors out most logic of git_project_list():
* git_project_list_all() as a git_project_list_body() wrapper for
complete project listing
* git_project_search_form() for printing the project search form
Also, git_project_list_ctags() is now separated out of
git_project_list_body(), showing tag cloud for given project list.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
gitweb/gitweb.perl | 69 +++++++++++++++++++++++++++++++---------------------
1 files changed, 41 insertions(+), 28 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index e4cbfc3..e82ca45 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -4201,10 +4201,9 @@ sub git_patchset_body {
# project in the list, removing invalid projects from returned list
# NOTE: modifies $projlist, but does not remove entries from it
sub fill_project_list_info {
- my ($projlist, $check_forks) = @_;
+ my ($projlist, $check_forks, $show_ctags) = @_;
my @projects;
- my $show_ctags = gitweb_check_feature('ctags');
PROJECT:
foreach my $pr (@$projlist) {
my (@activity) = git_get_last_activity($pr->{'path'});
@@ -4254,12 +4253,26 @@ sub print_sort_th {
}
}
+sub git_project_list_ctags {
+ my ($projects) = @_;
+
+ my %ctags;
+ foreach my $p (@$projects) {
+ foreach my $ct (keys %{$p->{'ctags'}}) {
+ $ctags{$ct} += $p->{'ctags'}->{$ct};
+ }
+ }
+ my $cloud = git_populate_project_tagcloud(\%ctags);
+ print git_show_project_tagcloud($cloud, 64);
+}
+
sub git_project_list_body {
# actually uses global variable $project
my ($projlist, $order, $from, $to, $extra, $no_header) = @_;
my $check_forks = gitweb_check_feature('forks');
- my @projects = fill_project_list_info($projlist, $check_forks);
+ my $show_ctags = gitweb_check_feature('ctags');
+ my @projects = fill_project_list_info($projlist, $check_forks, $show_ctags);
$order ||= $default_projects_order;
$from = 0 unless defined $from;
@@ -4278,16 +4291,8 @@ sub git_project_list_body {
@projects = sort {$a->{$oi->{'key'}} <=> $b->{$oi->{'key'}}} @projects;
}
- my $show_ctags = gitweb_check_feature('ctags');
if ($show_ctags) {
- my %ctags;
- foreach my $p (@projects) {
- foreach my $ct (keys %{$p->{'ctags'}}) {
- $ctags{$ct} += $p->{'ctags'}->{$ct};
- }
- }
- my $cloud = git_populate_project_tagcloud(\%ctags);
- print git_show_project_tagcloud($cloud, 64);
+ git_project_list_ctags(\@projects);
}
print "<table class=\"project_list\">\n";
@@ -4361,6 +4366,28 @@ sub git_project_list_body {
print "</table>\n";
}
+sub git_project_search_form {
+ print $cgi->startform(-method => "get") .
+ "<p class=\"projsearch\">Search:\n" .
+ $cgi->textfield(-name => "s", -value => $searchtext) . "\n" .
+ "</p>" .
+ $cgi->end_form() . "\n";
+}
+
+sub git_project_list_all {
+ my $order = $input_params{'order'};
+ if (defined $order && $order !~ m/none|project|descr|owner|age/) {
+ die_error(400, "Unknown order parameter");
+ }
+
+ my @list = git_get_projects_list();
+ if (!@list) {
+ die_error(404, "No projects found");
+ }
+
+ git_project_list_body(\@list, $order);
+}
+
sub git_shortlog_body {
# uses global variable $project
my ($commitlist, $from, $to, $refs, $extra) = @_;
@@ -4630,28 +4657,14 @@ sub git_search_grep_body {
## actions
sub git_project_list {
- my $order = $input_params{'order'};
- if (defined $order && $order !~ m/none|project|descr|owner|age/) {
- die_error(400, "Unknown order parameter");
- }
-
- my @list = git_get_projects_list();
- if (!@list) {
- die_error(404, "No projects found");
- }
-
git_header_html();
if (-f $home_text) {
print "<div class=\"index_include\">\n";
insert_file($home_text);
print "</div>\n";
}
- print $cgi->startform(-method => "get") .
- "<p class=\"projsearch\">Search:\n" .
- $cgi->textfield(-name => "s", -value => $searchtext) . "\n" .
- "</p>" .
- $cgi->end_form() . "\n";
- git_project_list_body(\@list, $order);
+ git_project_search_form();
+ git_project_list_all();
git_footer_html();
}
--
tg: (8cc62c1..) t/frontpage/refactor (depends on: vanilla/master)
^ permalink raw reply related
* [PATCH] gitweb: Support for no project list on gitweb front page
From: Petr Baudis @ 2009-11-06 15:11 UTC (permalink / raw)
To: git; +Cc: Petr Baudis
On very large sites like repo.or.cz (but maybe also git.debian.org,
git.kernel.org, etc.), it is desirable not to have the project list
on the front page since generating it is significant overhead and it
takes significant data transfer and load time for the user, who might
prefer to instead use the search form and possibly content tags to
navigate to the target project. A link to the full list of projects is
still available on the front page for users who wish to browse it. The
whole feature is turned off by default.
The patch introduces a new config variable $frontpage_no_project_list,
by default 0 keeping the current behavior; if set to 1, no project list
will be shown, but all projects will be still scanned if ctags are
enabled; if set to 2, no project will be shown and no projects will
be scanned while showing the front page. The compromise value of 1 is
useful for sites where project scan time is not an issue or which
use additional project list caching patches.
The patch furthermore modifies project_list action not to show the
index text, and introduces new default action frontpage which is by
default identical to old project_list action, but can be further
controlled by the $frontpage_no_project_list variable.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
gitweb/README | 8 ++++++++
gitweb/gitweb.css | 5 +++++
gitweb/gitweb.perl | 32 +++++++++++++++++++++++++++++---
3 files changed, 42 insertions(+), 3 deletions(-)
diff --git a/gitweb/README b/gitweb/README
index 66c6a93..c5fd1b8 100644
--- a/gitweb/README
+++ b/gitweb/README
@@ -223,6 +223,14 @@ not include variables usually directly set during build):
repositories from launching cross-site scripting (XSS) attacks. Set this
to true if you don't trust the content of your repositories. The default
is false.
+ * $frontpage_no_project_list
+ If 0, the gitweb frontpage will contain the project list; if 1 instead,
+ it will contain just the index text, search form, tag cloud (if enabled)
+ and a link to the actual project list. The page is reduced, but all
+ projects still need to be scanned for the tag cloud construction. If the
+ option is set to 2, not even the tag cloud will be shown; this is fastest.
+ This option is useful for sites with large amount of projects. The default
+ is 0.
Projects list file format
diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
index cb3f0ba..9fee3f0 100644
--- a/gitweb/gitweb.css
+++ b/gitweb/gitweb.css
@@ -97,6 +97,11 @@ div.readme {
padding: 8px;
}
+p.projectlist_link {
+ text-align: center;
+ font-weight: bold;
+}
+
a.title:hover {
background-color: #d9d8d1;
}
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 97e88b4..48326a4 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -152,6 +152,11 @@ our @diff_opts = ('-M'); # taken from git_commit
# the gitweb domain.
our $prevent_xss = 0;
+# Whether to include project list on the gitweb front page; 0 means yes,
+# 1 means no list but show tag cloud if enabled (all projects still need
+# to be scanned), 2 means no list and no tag cloud (very fast)
+our $frontpage_no_project_list = 0;
+
# information about snapshot formats that gitweb is capable of serving
our %known_snapshot_formats = (
# name => {
@@ -601,6 +606,7 @@ our %actions = (
"object" => \&git_object,
# those below don't need $project
"opml" => \&git_opml,
+ "frontpage" => \&git_frontpage,
"project_list" => \&git_project_list,
"project_index" => \&git_project_index,
);
@@ -901,13 +907,13 @@ if (!defined $action) {
} elsif (defined $project) {
$action = 'summary';
} else {
- $action = 'project_list';
+ $action = 'frontpage';
}
}
if (!defined($actions{$action})) {
die_error(400, "Unknown action");
}
-if ($action !~ m/^(?:opml|project_list|project_index)$/ &&
+if ($action !~ m/^(?:opml|frontpage|project_list|project_index)$/ &&
!$project) {
die_error(400, "Project needed");
}
@@ -4377,6 +4383,7 @@ sub git_project_list_body {
sub git_project_search_form {
print $cgi->startform(-method => "get") .
+ $cgi->hidden({-name=>"a", -value=>"project_list"}) . "\n" .
"<p class=\"projsearch\">Search:\n" .
$cgi->textfield(-name => "s", -value => $searchtext) . "\n" .
"</p>" .
@@ -4665,7 +4672,7 @@ sub git_search_grep_body {
## ======================================================================
## actions
-sub git_project_list {
+sub git_frontpage {
git_header_html();
if (-f $home_text) {
print "<div class=\"index_include\">\n";
@@ -4673,6 +4680,25 @@ sub git_project_list {
print "</div>\n";
}
git_project_search_form();
+ if (not $frontpage_no_project_list) {
+ git_project_list_all();
+ } else {
+ my $show_ctags = gitweb_check_feature('ctags');
+ if ($frontpage_no_project_list == 1 and $show_ctags) {
+ my @list = git_get_projects_list();
+ my @projects = fill_project_list_info(\@list, gitweb_check_feature('forks'), $show_ctags);
+ git_project_list_ctags(\@projects);
+ }
+ print "<p class=\"projectlist_link\">" .
+ $cgi->a({-href => href(action=>'project_list')}, "Browse all projects") .
+ "</p>\n";
+ }
+ git_footer_html();
+}
+
+sub git_project_list {
+ git_header_html();
+ git_project_search_form();
git_project_list_all();
git_footer_html();
}
--
tg: (e731dcd..) t/frontpage/separate (depends on: t/frontpage/ctags)
^ permalink raw reply related
* [PATCH] gitweb: Polish the content tags support
From: Petr Baudis @ 2009-11-06 15:10 UTC (permalink / raw)
To: git; +Cc: Petr Baudis
This patch integrates the tag filtering CGI parameter into the framework
for parameter passing, dropping 'by_tag' and instead using query name 't'
and symbolic name 'ctag_filter'. Compatibility support for 'by_tag' query
name is retained.
This means that content tag links are now created using $cgi->a() and
the href() method, and that they now point to the proper action;
project_list in case of global content tags, forks in case of per-fork
content tags. Also any other arguments like sorting order of projects
are replayed within the links.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
gitweb/gitweb.perl | 37 +++++++++++++++++++++++--------------
1 files changed, 23 insertions(+), 14 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index e82ca45..97e88b4 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -566,6 +566,7 @@ our @cgi_param_mapping = (
searchtext => "s",
searchtype => "st",
snapshot_format => "sf",
+ ctag_filter => 't',
extra_options => "opt",
search_use_regexp => "sr",
);
@@ -622,6 +623,11 @@ while (my ($name, $symbol) = each %cgi_param_mapping) {
}
}
+# Backwards compatibility - by_tag= <=> t=
+if ($cgi->param('by_tag')) {
+ $input_params{'ctag_filter'} = $cgi->param('by_tag');
+}
+
# now read PATH_INFO and update the parameter list for missing parameters
sub evaluate_path_info {
return if defined $input_params{'project'};
@@ -2257,7 +2263,7 @@ sub git_get_project_ctags {
}
sub git_populate_project_tagcloud {
- my $ctags = shift;
+ my ($ctags, $action) = @_;
# First, merge different-cased tags; tags vote on casing
my %ctags_lc;
@@ -2280,7 +2286,8 @@ sub git_populate_project_tagcloud {
$title =~ s/ / /g;
$title =~ s/^/ /g;
$title =~ s/$/ /g;
- $cloud->add($title, $home_link."?by_tag=".$_, $ctags_lc{$_}->{count});
+ $cloud->add($title, href(-replay=>1, action=>$action, ctag_filter=>$_),
+ $ctags_lc{$_}->{count});
}
} else {
$cloud = \%ctags_lc;
@@ -2289,14 +2296,15 @@ sub git_populate_project_tagcloud {
}
sub git_show_project_tagcloud {
- my ($cloud, $count) = @_;
+ my ($cloud, $count, $action) = @_;
print STDERR ref($cloud)."..\n";
if (ref $cloud eq 'HTML::TagCloud') {
return $cloud->html_and_css($count);
} else {
my @tags = sort { $cloud->{$a}->{count} <=> $cloud->{$b}->{count} } keys %$cloud;
return '<p align="center">' . join (', ', map {
- "<a href=\"$home_link?by_tag=$_\">$cloud->{$_}->{topname}</a>"
+ $cgi->a({-href => href(-replay=>1, action=>$action, ctag_filter=>$_)},
+ $cloud->{$_}->{topname});
} splice(@tags, 0, $count)) . '</p>';
}
}
@@ -4254,7 +4262,8 @@ sub print_sort_th {
}
sub git_project_list_ctags {
- my ($projects) = @_;
+ my ($projects, $action) = @_;
+ $action ||= 'project_list';
my %ctags;
foreach my $p (@$projects) {
@@ -4262,13 +4271,13 @@ sub git_project_list_ctags {
$ctags{$ct} += $p->{'ctags'}->{$ct};
}
}
- my $cloud = git_populate_project_tagcloud(\%ctags);
- print git_show_project_tagcloud($cloud, 64);
+ my $cloud = git_populate_project_tagcloud(\%ctags, $action);
+ print git_show_project_tagcloud($cloud, 64, $action);
}
sub git_project_list_body {
# actually uses global variable $project
- my ($projlist, $order, $from, $to, $extra, $no_header) = @_;
+ my ($projlist, $order, $from, $to, $extra, $no_header, $ctags_action) = @_;
my $check_forks = gitweb_check_feature('forks');
my $show_ctags = gitweb_check_feature('ctags');
@@ -4292,7 +4301,7 @@ sub git_project_list_body {
}
if ($show_ctags) {
- git_project_list_ctags(\@projects);
+ git_project_list_ctags(\@projects, $ctags_action);
}
print "<table class=\"project_list\">\n";
@@ -4309,7 +4318,7 @@ sub git_project_list_body {
"</tr>\n";
}
my $alternate = 1;
- my $tagfilter = $cgi->param('by_tag');
+ my $tagfilter = $input_params{'ctag_filter'};
for (my $i = $from; $i <= $to; $i++) {
my $pr = $projects[$i];
@@ -4682,7 +4691,7 @@ sub git_forks {
git_header_html();
git_print_page_nav('','');
git_print_header_div('summary', "$project forks");
- git_project_list_body(\@list, $order);
+ git_project_list_body(\@list, $order, undef, undef, undef, undef, 'forks');
git_footer_html();
}
@@ -4756,12 +4765,12 @@ sub git_summary {
my $show_ctags = gitweb_check_feature('ctags');
if ($show_ctags) {
my $ctags = git_get_project_ctags($project);
- my $cloud = git_populate_project_tagcloud($ctags);
+ my $cloud = git_populate_project_tagcloud($ctags, 'project_list');
print "<tr id=\"metadata_ctags\"><td>Content tags:<br />";
print "</td>\n<td>" unless %$ctags;
print "<form action=\"$show_ctags\" method=\"post\"><input type=\"hidden\" name=\"p\" value=\"$project\" />Add: <input type=\"text\" name=\"t\" size=\"8\" /></form>";
print "</td>\n<td>" if %$ctags;
- print git_show_project_tagcloud($cloud, 48);
+ print git_show_project_tagcloud($cloud, 48, 'project_list');
print "</td></tr>";
}
@@ -4805,7 +4814,7 @@ sub git_summary {
git_project_list_body(\@forklist, 'age', 0, 15,
$#forklist <= 15 ? undef :
$cgi->a({-href => href(action=>"forks")}, "..."),
- 'no_header');
+ 'no_header', 'forks');
}
git_footer_html();
--
tg: (73bafe5..) t/frontpage/ctags (depends on: t/frontpage/refactor)
^ permalink raw reply related
* Re: Preserving branches after merging on ancestor
From: rhlee @ 2009-11-06 15:21 UTC (permalink / raw)
To: git
In-Reply-To: <20091106050353.GA8824@progeny.tock>
Hi John, Björn and Eric,
Thank you very much for your replies from which I gained a lot insight about
git merging and different workflows.
Yes, I have tried out --no-ff and it does the job for me. (Incidentally,
doing that take it look neater in git gui as all the master nodes appear on
top of each other. Using empty commits, the merged branches appear on top
the master nodes in the graph.)
Jonathan Nieder-2 wrote:
>
> Then your response pushed me towards the question of whether --no-ff is a
> good idea in general
>
John, I get the feeling from what you say in general that fast forwards are
default behaviour for merges for a reason and by using the --no-ff option I
am making my workflow and git history uncessesarily awkward and working
against best practices?
Jonathan Nieder-2 wrote:
>
>> I guess Richard took the "branch topic1, merge topic1, branch topic2,
>> merge topic2" thing just as an example because that ends up with two
>> fast-forwards.
>
> Hmm, I found Richard’s example pretty realistic. I used to work like
> that, and I don’t think I am the only one.
>
I'm not saying there is any one "right" workflow. But is there a more
suitable workflow than than "branch topic1, merge topic1, branch topic2,
merge topic2"?
Thanks,
Richard
--
View this message in context: http://n2.nabble.com/Preserving-branches-after-merging-on-ancestor-tp3954131p3959325.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH] gitweb: Refactor project list routines
From: Petr Baudis @ 2009-11-06 15:22 UTC (permalink / raw)
To: git
In-Reply-To: <1257520246-6548-1-git-send-email-pasky@suse.cz>
Oops, I'm sorry, I expected tg mail to submit the mails in series...
The correct order is:
[PATCH] gitweb: Refactor project list routines
[PATCH] gitweb: Support for no project list on gitweb front page
[PATCH] gitweb: Polish the content tags support
(The blob linenr patch is independent.)
Petr "Pasky" Baudis
^ permalink raw reply
* Re: Timur Sufiev: Re: [PATCH I18N filenames v2 3/3] Provide compatibility with MinGW
From: Peter Krefting @ 2009-11-06 14:55 UTC (permalink / raw)
To: Timur Sufiev; +Cc: git
In-Reply-To: <4af3f3cb.0305560a.7a34.0f43@mx.google.com>
Timur Sufiev:
> 1. Many git front-ends, e.g. TortoiseGit, use 8-bit set, not UTF-16:
All of them do, that is because the output is using 8-bit. That is why the
internal encoding need to remain eight-bit, for instance UTF-8.
> they call git plumbing commands and pass filenames to command line (in
> local 8-bit encoding).
Well, yes. On Windows, however, there is the complication that the command
line is available in two versions. There is a eight-bit and a UTF-16 version
of it. Which one is constructed from which depends on how the application
was launched. We can read the UTF-16 version and hope that it contains
proper names (possibly looking at the eight-bit version as UTF-8 if
necessary).
> 2. UTF-16 is a proper solution for Windows, but my patch is useful for
> other OSes with locales different from UTF-8 (e.g. Linux with KOI8-R
> locale).
Well, your patch re-implements the fopen() calls, converting the file name
at that point (as well as readdir() and friends). I would do that on Windows
as well, with the modification that on Windows, I would convert to UTF-16
and use _wfopen() instead. On systems that have it, you could also make it
convert to UTF-32 and use their wfopen() (I'm not aware of many other OSes
having those functions, though).
> Still there is a possibility that one day we'll stumble upon some UTF-8
> symbol which cannot not be correctly mapped into 8-bit encoding. UTF-16
> would be a remedy in this case, but what if don't have it (see 2)?
That is of course an issue. There are several approaches to that:
- Fail with an error.
- Convert to a place-holder character.
- QP encode the file name, perhaps?
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Git drawbacks?
From: Dmitry Smirnov @ 2009-11-06 16:17 UTC (permalink / raw)
To: git
Hi,
Sorry if I selected the wrong place to discuss the drawbacks of the Git. Just
point to the proper one...
I'm just trying to select the best VCS for me personally.
I have a very small experience with Git but I see is also not very sutable for
me.
First, it seems to be very hard to setup some really big project (like Android,
for example). Otherwise, why do they need to invent 'repo'? What purpose it
solves? It looks like it
1. Integrates few subcomponents (projects) and checkout the code in the proper
configuration. The question is why this is not the Git task? For me, it looks
like the ClearCase client spec.
2.? What others (except integration with review tool)?
The next issue with git is its clone. Why do I need the whole set of revisions?
Why do I need to get 1GB of Android? You could say this should happen once. I
would agree but when I tried to resync the Android tree after 2 months, I was
struggled with many errors (both git and repo). Finally, I had decided to sync
again. :-)
There is one point against clone. The typical situation in my office is to have
few Perforce clients with the same or slightly different code. This is just
wasting a space since you need them all but versions of many files are the same.
I'm trying to imagine the same situation with Git. Are there any benefits? It
seems, no. Moreover, I will have not only few working trees but few repository
clones!
It is obvious that configuration management with Git is very difficult (for ex,
http://groups.google.com/group/repo-
discuss/browse_thread/thread/2fa368ed7cac5d79/64ced51656240ddc?
lnk=gst&q=create+android+bare+repository#64ced51656240ddc)
Let's consider the foolwing use case. Suppose I'm intending to create a new
product that consists of specific versions (or branches) of some subcomponents
(or directories). How can I do this with Git? Subsequent changes could either be
submitted to the appropriate component branch or branched to the new one (this
way is possible with Git, of course, if I will branch the code I need to this
new branch).
So, I'm wondering, why Git (or any other VCS) is not trying to solve these
problems? Perhaps, there is a simple solution with Git I'm not aware of?
Here is the wish list for the VCS I would prefer:
1. Atomit commits
2. The possibility to get any slice of the code repository with the possibility
to commit my changes on tip or on separate branch.
3. The minimum footprint of the same code on my local machine.
4. No code/history on my machine untill I really need it.
5. Easy mirroring and replication
I would say, ClearCase might be my favorite if it is not commercial. :-)
Dmitry
^ permalink raw reply
* Re: Git drawbacks?
From: Avery Pennarun @ 2009-11-06 16:49 UTC (permalink / raw)
To: Dmitry Smirnov; +Cc: git
In-Reply-To: <loom.20091106T160709-387@post.gmane.org>
On Fri, Nov 6, 2009 at 11:17 AM, Dmitry Smirnov <divis1969@gmail.com> wrote:
> Here is the wish list for the VCS I would prefer:
> 1. Atomit commits
> 2. The possibility to get any slice of the code repository with the possibility
> to commit my changes on tip or on separate branch.
> 3. The minimum footprint of the same code on my local machine.
> 4. No code/history on my machine untill I really need it.
> 5. Easy mirroring and replication
>
> I would say, ClearCase might be my favorite if it is not commercial. :-)
#1 and #5 are features of any DVCS, so git already has them. #2, 3,
and 4 are all just saying the same thing: "I can't afford the disk
space to store the entire repo." Are you sure this is true, or is it
a preconception? Even a 1GB repository is tiny by modern disk
standards.
My (limited) experience with ClearCase is that it's so slow that you'd
do *anything* to track fewer files in your working copy, so they put a
lot of work into exactly that, and no work into performance. This
lousy performance isn't the case in git (except in Windows). Are you
using Windows, by chance?
Have fun,
Avery
^ permalink raw reply
* Re: [PATCH] pre-commit.sample: Diff against the empty tree when HEAD is invalid
From: Heiko Voigt @ 2009-11-06 17:11 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Junio C Hamano, git
In-Reply-To: <20091105105757.GA31787@atjola.homenet>
Hallo,
On Thu, Nov 05, 2009 at 11:57:57AM +0100, Björn Steinbrink wrote:
> This was already the case for the old "diff --check" call, but the new
> one that checks whether there are any non-ascii file names was missing
> it, making that check fail for root commits.
>
> Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
[...]
> - test "$(git diff --cached --name-only --diff-filter=A -z |
> + test "$(git diff --cached --name-only --diff-filter=A -z $against |
Looks sensible to me. Thanks for that fix.
As this went unnoticed for quite some time it seems as either not many
are actually using our example hook or at least not starting new
projects with it. I fit in the latter group I suppose.
cheers Heiko
^ permalink raw reply
* Re: Git drawbacks?
From: Dmitry Smirnov @ 2009-11-06 17:35 UTC (permalink / raw)
To: git
In-Reply-To: <32541b130911060849s2d8f13f5sb9b8390f075f8d15@mail.gmail.com>
> > Here is the wish list for the VCS I would prefer:
> > 1. Atomit commits
> > 2. The possibility to get any slice of the code repository with the
possibility
> > to commit my changes on tip or on separate branch.
> > 3. The minimum footprint of the same code on my local machine.
> > 4. No code/history on my machine untill I really need it.
> > 5. Easy mirroring and replication
> >
> > I would say, ClearCase might be my favorite if it is not commercial.
>
> #1 and #5 are features of any DVCS, so git already has them. #2, 3,
> and 4 are all just saying the same thing:
No, #2 is about the repository slicing, branching, merging (SCM in other words).
Let's suppose I have the product that have 2 directories: component1 and
component2. They were developing together for previous product (on the same
branch, for example). Now, I would like to have component1 and replace
component2 with some 3rd party component. What should I do with Git to get this?
Or maybe I wish to stick with some version of component2 and provide only bug
fixes for this product...
Or let's take a look at GDB. They are using binutils which are in separate
repository (they use CVS, but let's imagine they use Git). How many effors they
will need for SCM? For example, they would prefer to stick to some stable
version/branch of the binutils but should be able to commit bug fixes.
Once again, perhaps there is some way to do this with Git? I did not yet find
it.
> "I can't afford the disk
> space to store the entire repo." Are you sure this is true, or is it
> a preconception? Even a 1GB repository is tiny by modern disk
> standards.
oh, yes, since we have big drives and fast internet, we do not have to worry
about space and download time... :-)
> My (limited) experience with ClearCase is that it's so slow that you'd
> do *anything* to track fewer files in your working copy, so they put a
> lot of work into exactly that, and no work into performance.
This probably true. Thought I did not have a lot of problems with it unless I
use GUI.
> This
> lousy performance isn't the case in git (except in Windows). Are you
> using Windows, by chance?
yes. I did not yet noticed any performance problems with Git on windows, except
a sync/download time (for android, mostly)
^ permalink raw reply
* Re: Git drawbacks?
From: Jacob Helwig @ 2009-11-06 17:41 UTC (permalink / raw)
To: Dmitry Smirnov; +Cc: git
In-Reply-To: <loom.20091106T180313-750@post.gmane.org>
On Fri, Nov 6, 2009 at 09:35, Dmitry Smirnov <divis1969@gmail.com> wrote:
> No, #2 is about the repository slicing, branching, merging (SCM in other words).
> Let's suppose I have the product that have 2 directories: component1 and
> component2. They were developing together for previous product (on the same
> branch, for example). Now, I would like to have component1 and replace
> component2 with some 3rd party component. What should I do with Git to get this?
> Or maybe I wish to stick with some version of component2 and provide only bug
> fixes for this product...
> Or let's take a look at GDB. They are using binutils which are in separate
> repository (they use CVS, but let's imagine they use Git). How many effors they
> will need for SCM? For example, they would prefer to stick to some stable
> version/branch of the binutils but should be able to commit bug fixes.
>
> Once again, perhaps there is some way to do this with Git? I did not yet find
> it.
>
Sounds like you want submodules. Check out the git-submodule(1) manpage.
^ permalink raw reply
* Re: Git drawbacks?
From: Avery Pennarun @ 2009-11-06 17:51 UTC (permalink / raw)
To: Dmitry Smirnov; +Cc: git
In-Reply-To: <loom.20091106T180313-750@post.gmane.org>
On Fri, Nov 6, 2009 at 12:35 PM, Dmitry Smirnov <divis1969@gmail.com> wrote:
> No, #2 is about the repository slicing, branching, merging (SCM in other words).
> Let's suppose I have the product that have 2 directories: component1 and
> component2. They were developing together for previous product (on the same
> branch, for example). Now, I would like to have component1 and replace
> component2 with some 3rd party component. What should I do with Git to get this?
> Or maybe I wish to stick with some version of component2 and provide only bug
> fixes for this product...
There are three methods I know of to manage this:
1) Just commit whatever version of a subproject you want as a subtree
of your current project, and if you want to replace/delete/upgrade it,
just do that. (You rarely want to track the actual *history* of the
third party tool, just the history of versions *you* used, which is
easy to do.)
2) Use git-submodule to link repositories together. (Arguably, one
major reason 'repo' was written is that git-submodule is too
complicated, though.)
3) Try my git-subtree tool, which basically makes it easier to
split/join repositories (similar to #1) without losing the history
(similar to #2).
>> This
>> lousy performance isn't the case in git (except in Windows). Are you
>> using Windows, by chance?
>
> yes. I did not yet noticed any performance problems with Git on windows, except
> a sync/download time (for android, mostly)
Basically, performance is linear with the number of files in your
repo. If you can check out just a "slice" of your repo (say 10% of
the whole), you'll have faster performance (eg. 10x) from any VCS.
git on Linux is so fast that this isn't very necessary most of the
time. But git on Windows isn't really any faster than other VCSes on
Windows, so the time-per-file is much greater, and thus the penalty
for huge repositories is much worse. Doing things like switching
branches, which is near-instantaneous on Linux even with tens of
thousands of files, really crawls on Windows.
So I can see an argument that Windows users would want arbitrary
"slices" much more often than Linux+git users, but I think this is
largely due to performance, not because people really *want* to be
stuck with a restricted view of the repo.
Have fun,
Avery
^ permalink raw reply
* Re: How to merge into my working copy?
From: Junio C Hamano @ 2009-11-06 17:53 UTC (permalink / raw)
To: Patrick Doyle; +Cc: git
In-Reply-To: <e2a1d0aa0911060653t7bbb54ebp948eac0dffeaba64@mail.gmail.com>
Patrick Doyle <wpdster@gmail.com> writes:
> I would like to pull a set of changes from a branch back into the
> working copy of my current branch without affecting the index. I
> can't figure out the right combination of --commit, --no-commit, -ff,
> -no-ff, --log, --no-log, --squash, --no-squash, etc... options to use
> with git-merge.
>
> Basically, I created a branch off my mainline branch a few days ago.
> Made some commits on that branch. Then went back to my mainline
> branch, made a few commits there, and now I would like to make my
> working copy look like a merge of its current state with the changes
> from the branch, minus any associated commits.
If you do not have to have your extra "without affecting the index"
constraint (which I do not see a sensible reason to want to, by the way),
you can "merge --no-commit that_branch", I think.
^ permalink raw reply
* question: connecting to multiple remote svn projects
From: Dave Rodgman @ 2009-11-06 17:55 UTC (permalink / raw)
To: git
Hi,
Given a layout in a single subversion repository like this:
module1/branches/1.0/work
module2/branches/1.0/work
I would like achieve the following layout locally, in git:
module1/work
module2/work
Obviously I can create multiple git repositories in separate directories,
but I would like them to be in a single repository. I can also get the
same layout as subversion, but this breaks various bits of build
infrastructure. I've fiddled with --branches, etc on git svn init
but can't figure out how to achieve this.
I don't care about tracking the subversion branches in git, or being able
to switch between subversion branches.
Is this possible? How can I do this?
many thanks
Dave
^ permalink raw reply
* Re: [PATCHv3/RFC 4/5] gitweb: Create links leading to 'blame_incremental' using JavaScript
From: Jakub Narebski @ 2009-11-06 18:05 UTC (permalink / raw)
To: Petr Baudis
Cc: git, Fredrik Kuivinen, Giuseppe Bilotta, Luben Tuikov,
Martin Koegler
In-Reply-To: <20091105203316.GD17748@machine.or.cz>
On Thu, Nov 05, 2009, Petr Baudis wrote:
> On Tue, Sep 01, 2009 at 01:39:19PM +0200, Jakub Narebski wrote:
> > @@ -4806,6 +4820,10 @@ sub git_tag {
> >
> > sub git_blame_common {
> > my $format = shift || 'porcelain';
> > + if ($format eq 'porcelain' && $cgi->param('js')) {
> > + $format = 'incremental';
> > + $action = 'blame_incremental'; # for page title etc
> > + }
> >
> > # permissions
> > gitweb_check_feature('blame')
>
> I'm a bit concerned here. I have somewhat backed out of incremental
> blame myself because I have found (in accord with Junio's old findings)
> that in most cases, incremental blame can be actually slower than normal
> blame because of slow browsers where it takes long to update the page in
> each step.
>
> I'm sorry if I missed this in one of your mails, but how fast is
> incremental blame in your implementation? If this still might be an
> issue, I think it should be configurable whether to use incremental
> blame, or perhaps use some quick heuristic wrt. file size (negative
> bias) and history length (positive bias) [not sure if that information
> is quickly available].
Unfortunately I can't benchmark the speed of incremental blame well
because of testing it on a single computer.
What I have found that incremental blame spares at least _server time_,
which means that the time to prepare starting view for incremental blame
(with the contents of file in blame format, unblamed) plus the time to
generate incremental blame data is usually about the same or faster
than the time to generate ordinary blame view. Quite faster if file
have large number of blamed commits:
$ git blame -p <file> | grep author-time | wc -l
But even if incremental blame turns out to be slower than incremental
blame it still has the advantage of being _incremental_. You have at
least some result soon. Even more with current implementation which
includes progress report for incremental blame.
What needs to be addressed however is to remove totally unnecessary
critical section / locking code, as JavaScript is single threaded.
We should take care however that JavaScript code of interactive blame
doesn't take all CPU, for example using technique presented in
"Timed array processing in JavaScript" by Nicholas C. Zakas
http://www.nczonline.net/blog/2009/08/11/timed-array-processing-in-javascript/
.....................................................................
If you want below there are very simple benchmark of blame and
incremental blame on a _single_ computer:
AMD Athlon 1 GHz, 512MB RAM, Linux 2.6.14-11.1.aur.2, Apache 2.0.54
I don't remember however if it is for the most current code.
File | 'blame'[1] | 'blame_incremental'[2]
================================================================
blob.h | 2.346s | 0.443s + (2.244s / 2.921s)
GIT-VERSION-GEN | 2.449s | 1.346s + (3.157s / 3.876s)
README | 2.713s | 0.508s + (2.952s / 3.659s)
revision.c | 19.964s | 4.872s + (11.306s / 32.124s)
gitweb/gitweb.perl | 83.912s | 12.069s + (52.922s / 223.133s)
$ git blame --porcelain gitweb/gitweb.perl >/dev/null
0m11.437s user + 0m0.740s sys, 66300minor pagefaults
$ git blame --incremental gitweb/gitweb.perl >/dev/null
0m11.477s user + 0m0.816s sys, 68945minor pagefaults
Footnotes:
~~~~~~~~~~
[1] Total wall-clock time as returned by gitweb in the page footer.
[2] XXs + (XXs server blame_data / XXs client JavaScript).
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: How to merge into my working copy?
From: Patrick Doyle @ 2009-11-06 18:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8wejzgim.fsf@alter.siamese.dyndns.org>
On Fri, Nov 6, 2009 at 12:53 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> If you do not have to have your extra "without affecting the index"
> constraint (which I do not see a sensible reason to want to, by the way),
> you can "merge --no-commit that_branch", I think.
>
After bouncing this around a couple of times with Bruce Stephens, and
only now noticing that I hit "Reply" instead of "Reply-All"... sigh),
I realized that what I wanted was:
$ git merge --squash that_branch
$ git reset
I only wanted to affect my working copy, editing and adding things to
the index (which I think of as "staging area for my next commit") as I
was ready.
--wpd
^ permalink raw reply
* Re: gitk : french translation
From: Thomas Moulard @ 2009-11-06 18:16 UTC (permalink / raw)
To: Emmanuel Trillaud; +Cc: Git Mailing List
In-Reply-To: <9f50533b0911060605p6ad28ad9neac3620a1809c3db@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1239 bytes --]
On Fri, Nov 6, 2009 at 3:05 PM, Emmanuel Trillaud <etrillaud@gmail.com> wrote:
> Hello all,
> I made an attempt to translate gitk in french. The translation is
> _almost_ complete
> and I would really appreciate to have some comments by the french people here.
> I also need to improve some translations I am not happy with so it's
> really a work in progress.
Here is an updated translation with the following changes:
- translated strings which was still untranslated
- fixed some fuzzy translations
- make some consistency changes
* s/diff/différences/
* s/patch/correctif/ everywhere
- fixed some spelling problems.
IMHO the most important should be to decide how to translate the git vocabulary.
The Subversion project has guidelines concerning that issue:
http://svn.collab.net/viewvc/svn/trunk/subversion/po/fr.po?revision=39920&view=markup
It may be a good idea to stick with what they are doing if possible.
The only exception should their translation of ``commit'' by
``propagation'' which
I find awkward. Especially in a Git context , ``git commit'' really
does not propagate anything.
BTW any reason to translate the GUIs (gitk / git-gui) but not the
command line tools?
--
Thomas Moulard
[-- Attachment #2: fr.po.bz2 --]
[-- Type: application/x-bzip2, Size: 7116 bytes --]
^ permalink raw reply
* Re: Git drawbacks?
From: david @ 2009-11-06 18:57 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Dmitry Smirnov, git
In-Reply-To: <32541b130911060951q3358ce9ahe28fb0cf902853f2@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2206 bytes --]
On Fri, 6 Nov 2009, Avery Pennarun wrote:
>>> This
>>> lousy performance isn't the case in git (except in Windows). Are you
>>> using Windows, by chance?
>>
>> yes. I did not yet noticed any performance problems with Git on windows, except
>> a sync/download time (for android, mostly)
>
> Basically, performance is linear with the number of files in your
> repo. If you can check out just a "slice" of your repo (say 10% of
> the whole), you'll have faster performance (eg. 10x) from any VCS.
>
> git on Linux is so fast that this isn't very necessary most of the
> time. But git on Windows isn't really any faster than other VCSes on
> Windows, so the time-per-file is much greater, and thus the penalty
> for huge repositories is much worse. Doing things like switching
> branches, which is near-instantaneous on Linux even with tens of
> thousands of files, really crawls on Windows.
but is that scale based on the number of files you are tracking, or the
number of revisions that exist in the repository.
i.e. 10,000 files in the source code with 10 revisions each vs 1,000
files with 100 revisions each.
my understanding of git is that it's the number of files, with very little
impact due to having lots of revisions. so eliminating 90 revisions of
each file would not significantly speed up git in the second case.
going back to the initial poster's comments. if the android repo is 1G,
eliminating the history will probably have significantly less impact than
you expect it to. for source code the compression factor that git is able
to get is spectacular. I've seen several cases posted with large projects
where the full repo with ALL history is <2x the size of a tar.gz of the
latest release.
David Lang
> So I can see an argument that Windows users would want arbitrary
> "slices" much more often than Linux+git users, but I think this is
> largely due to performance, not because people really *want* to be
> stuck with a restricted view of the repo.
>
> Have fun,
>
> Avery
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ 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