* Re: [PATCH v3 2/3] gitweb: Split git_project_list_body in two functions
From: Jakub Narebski @ 2008-12-05 1:52 UTC (permalink / raw)
To: Sébastien Cevey
Cc: git, Junio C Hamano, Petr Baudis, Gustavo Sverzut Barbieri
In-Reply-To: <87iqq022gz.wl%seb@cine7.net>
On Tue, 4 Dec 2008 at 01:44, Sébastien Cevey wrote:
> Extract the printing of project rows on the project page into a
> separate print_project_rows function. This makes it easier to reuse
> the code to print different subsets of the whole project list.
Err... it was not obvious for me that 'project rows' are rows of
projects list table, i.e. currently the body of projects list table.
But I think it is a good description.
>
> The row printing code is merely moved into a separate function, but
> note that $projects is passed as a reference now.
>
> Signed-off-by: Sebastien Cevey <seb@cine7.net>
Nicely done.
For what it is worth:
Acked-by: Jakub Narebski <jnareb@gmail.com>
> ---
>
> Boo, the diff is still quite scarier than it really should be...
Well, nothing short of blame -C would make it work; the issue is that
we split subroutine into two, extracting from the middle, but with
some common/similar header
2 1
1 1
2 1
2
2 -> 2
1 2
1 2
2 2
2 2
2
And diff is forward preferring, i.e. it finds match then second part
of split as add, rather than first first part of split as add then
match.
>
> gitweb/gitweb.perl | 103 +++++++++++++++++++++++++++++-----------------------
> 1 files changed, 57 insertions(+), 46 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index b31274c..a6bb702 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -3972,59 +3972,19 @@ sub print_sort_th {
> }
> }
>
> -sub git_project_list_body {
> +# print a row for each project in the given list, using the given
> +# range and extra display options
> +sub print_project_rows {
> # 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 ($projects, $from, $to, $check_forks, $show_ctags) = @_;
I see that print_project_rows gets @$projects list already sorted, and
it passes explicitly $check_forks and $show_ctags from caller.
>
> - $order ||= $default_projects_order;
> $from = 0 unless defined $from;
> - $to = $#projects if (!defined $to || $#projects < $to);
> -
> - my %order_info = (
> - project => { key => 'path', type => 'str' },
> - descr => { key => 'descr_long', type => 'str' },
> - owner => { key => 'owner', type => 'str' },
> - age => { key => 'age', type => 'num' }
> - );
> - my $oi = $order_info{$order};
> - if ($oi->{'type'} eq 'str') {
> - @projects = sort {$a->{$oi->{'key'}} cmp $b->{$oi->{'key'}}} @projects;
> - } else {
> - @projects = sort {$a->{$oi->{'key'}} <=> $b->{$oi->{'key'}}} @projects;
> - }
> + $to = $#$projects if (!defined $to || $#$projects < $to);
>
> - 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);
> - }
> -
> - print "<table class=\"project_list\">\n";
> - unless ($no_header) {
> - print "<tr>\n";
> - if ($check_forks) {
> - print "<th></th>\n";
> - }
> - print_sort_th('project', $order, 'Project');
> - print_sort_th('descr', $order, 'Description');
> - print_sort_th('owner', $order, 'Owner');
> - print_sort_th('age', $order, 'Last Change');
> - print "<th></th>\n" . # for links
> - "</tr>\n";
> - }
> my $alternate = 1;
> my $tagfilter = $cgi->param('by_tag');
> for (my $i = $from; $i <= $to; $i++) {
> - my $pr = $projects[$i];
> + my $pr = $projects->[$i];
>
> next if $tagfilter and $show_ctags and not grep { lc $_ eq lc $tagfilter } keys %{$pr->{'ctags'}};
> next if $searchtext and not $pr->{'path'} =~ /$searchtext/
> @@ -4068,6 +4028,57 @@ sub git_project_list_body {
> "</td>\n" .
> "</tr>\n";
> }
> +}
> +
> +sub git_project_list_body {
> + my ($projlist, $order, $from, $to, $extra, $no_header) = @_;
> +
> + my ($check_forks) = gitweb_check_feature('forks');
> + my @projects = fill_project_list_info($projlist, $check_forks);
> +
> + $order ||= $default_projects_order;
> +
> + my %order_info = (
> + project => { key => 'path', type => 'str' },
> + descr => { key => 'descr_long', type => 'str' },
> + owner => { key => 'owner', type => 'str' },
> + age => { key => 'age', type => 'num' }
> + );
> + my $oi = $order_info{$order};
> + if ($oi->{'type'} eq 'str') {
> + @projects = sort {$a->{$oi->{'key'}} cmp $b->{$oi->{'key'}}} @projects;
> + } else {
> + @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);
> + }
> +
> + print "<table class=\"project_list\">\n";
> + unless ($no_header) {
> + print "<tr>\n";
> + if ($check_forks) {
> + print "<th></th>\n";
> + }
> + print_sort_th('project', $order, 'Project');
> + print_sort_th('descr', $order, 'Description');
> + print_sort_th('owner', $order, 'Owner');
> + print_sort_th('age', $order, 'Last Change');
> + print "<th></th>\n" . # for links
> + "</tr>\n";
> + }
> +
> + print_project_rows(\@projects, $from, $to, $check_forks, $show_ctags);
> +
> if (defined $extra) {
> print "<tr>\n";
> if ($check_forks) {
> --
> 1.5.6.5
>
>
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 1/3] Make some of fwrite/fclose/write/close failures visible
From: Junio C Hamano @ 2008-12-05 2:04 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20081205003546.GA7294@blimp.localdomain>
All of them obviously look correct. Will apply to the tip of master.
Thanks.
^ permalink raw reply
* Re: [PATCH v3 3/3] gitweb: Optional grouping of projects by category
From: Jakub Narebski @ 2008-12-05 2:08 UTC (permalink / raw)
To: Sébastien Cevey
Cc: git, Junio C Hamano, Petr Baudis, Gustavo Sverzut Barbieri
In-Reply-To: <87hc5k22dr.wl%seb@cine7.net>
On Thu, 4 Dec 2008, Sébastien Cevey wrote:
> This adds the $projects_list_group_categories option which, if enabled,
> will result in grouping projects by category on the project list page.
> The category is specified for each project by the $GIT_DIR/category file
> or the 'category' variable in its configuration file. By default, projects
> are put in the $project_list_default_category category.
>
> Note:
> - Categories are always sorted alphabetically, with projects in
> each category sorted according to the globally selected $order.
> - When displaying a subset of all the projects (page limiting), the
> category headers are only displayed for projects present on the page.
>
> The feature is inspired from Sham Chukoury's patch for the XMMS2
> gitweb, but has been rewritten for the current gitweb development
> HEAD. The CSS for categories is inspired from Gustavo Sverzut Barbieri's
> patch to group projects by path.
>
> Thanks to Florian Ragwitz for Perl tips.
Very nice, and nicely done and thought out, idea.
>
> Signed-off-by: Sebastien Cevey <seb@cine7.net>
> ---
>
> Cleaner patch this time indeed. Still no fancy sorting of categories,
> only alphabetical.
>
> gitweb/README | 16 ++++++++++++
> gitweb/gitweb.css | 7 +++++
> gitweb/gitweb.perl | 67 +++++++++++++++++++++++++++++++++++++++++++++++++--
> 3 files changed, 87 insertions(+), 3 deletions(-)
>
> diff --git a/gitweb/README b/gitweb/README
> index 825162a..f8f8872 100644
> --- a/gitweb/README
> +++ b/gitweb/README
> @@ -188,6 +188,15 @@ not include variables usually directly set during build):
> full description is available as 'title' attribute (usually shown on
> mouseover). By default set to 25, which might be too small if you
> use long project descriptions.
> + * $projects_list_group_categories
> + Enables the grouping of projects by category on the project list page.
> + The category of a project is determined by the $GIT_DIR/category
> + file or the 'gitweb.category' variable in its repository configuration.
> + Disabled by default.
> + * $project_list_default_category
> + Default category for projects for which none is specified. If set
> + to the empty string, such projects will remain uncategorized and
> + listed at the top, above categorized projects.
> * @git_base_url_list
> List of git base URLs used for URL to where fetch project from, shown
> in project summary page. Full URL is "$git_base_url/$project".
Good.
> @@ -269,6 +278,13 @@ You can use the following files in repository:
> from the template during repository creation. You can use the
> gitweb.description repo configuration variable, but the file takes
> precedence.
> + * category (or gitweb.category)
> + Singe line category of a project, used to group projects if
> + $projects_list_group_categories is enabled. By default (file and
> + configuration variable absent), uncategorized projects are put in
> + the $project_list_default_category category. You can use the
> + gitweb.category repo configuration variable, but the file takes
> + precedence.
> * cloneurl (or multiple-valued gitweb.url)
> File with repository URL (used for clone and fetch), one per line.
> Displayed in the project summary page. You can use multiple-valued
Good.
> diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
> index a01eac8..64f2a41 100644
> --- a/gitweb/gitweb.css
> +++ b/gitweb/gitweb.css
> @@ -264,6 +264,13 @@ td.current_head {
> text-decoration: underline;
> }
>
> +td.category {
> + background-color: #d9d8d1;
> + border-top: 1px solid #000000;
> + border-left: 1px solid #000000;
> + font-weight: bold;
> +}
> +
> table.diff_tree span.file_status.new {
> color: #008000;
> }
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index a6bb702..97a9b73 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -87,6 +87,14 @@ our $projects_list = "++GITWEB_LIST++";
> # the width (in characters) of the projects list "Description" column
> our $projects_list_description_width = 25;
>
> +# group projects by category on the projects list
> +# (enabled if this variable evaluates to true)
> +our $projects_list_group_categories = 0;
> +
> +# default category if none specified
> +# (leave the empty string for no category)
> +our $project_list_default_category = "";
> +
> # default order of projects list
> # valid values are none, project, descr, owner, and age
> our $default_projects_order = "project";
Nice.
> @@ -2023,6 +2031,11 @@ sub git_get_project_description {
> return git_get_file_or_project_config('description', $path);
> }
>
> +sub git_get_project_category {
> + my $path = shift;
> + return git_get_file_or_project_config('category', $path);
> +}
> +
Good. Nicely uses earlier patch, which adds this infrastructure.
> sub git_get_project_ctags {
> my $path = shift;
> my $ctags = {};
> @@ -3915,8 +3928,9 @@ sub git_patchset_body {
>
> # . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
>
> -# fills project list info (age, description, owner, forks) for each
> -# project in the list, removing invalid projects from returned list
> +# fills project list info (age, description, owner, category, forks)
> +# for each 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) = @_;
> @@ -3939,6 +3953,11 @@ sub fill_project_list_info {
> if (!defined $pr->{'owner'}) {
> $pr->{'owner'} = git_get_project_owner("$pr->{'path'}") || "";
> }
> + if ($projects_list_group_categories && !defined $pr->{'category'}) {
> + my $cat = git_get_project_category($pr->{'path'}) ||
> + $project_list_default_category;
> + $pr->{'category'} = to_utf8($cat);
> + }
> if ($check_forks) {
> my $pname = $pr->{'path'};
> if (($pname =~ s/\.git$//) &&
Nice. I see that you choose to go with $pr->{'category'} like existing
$pr->{'owner'}, rather than $pr->{'cat'} like existing $pr->{'descr'}.
> @@ -3956,6 +3975,19 @@ sub fill_project_list_info {
> return @projects;
> }
>
> +# returns a hash of categories, containing the list of project
> +# belonging to each category
> +sub build_projlist_by_category {
> + my $projlist = shift;
> + my %categories;
> +
> + for my $pr (@$projlist) {
> + push @{$categories{ $pr->{'category'} }}, $pr;
> + }
> +
> + return %categories;
> +}
This is very nice and simple way to group by categories, and it works
quite well with sorting (assuming that @$projlist is already sorted),
but I wonder how it works with $from / $to, i.e. with selecting
projects.
> +
> # print 'sort by' <th> element, generating 'sort by $name' replay link
> # if that order is not selected
> sub print_sort_th {
> @@ -4077,7 +4109,36 @@ sub git_project_list_body {
> "</tr>\n";
> }
>
> - print_project_rows(\@projects, $from, $to, $check_forks, $show_ctags);
> + if ($projects_list_group_categories) {
> + # only display categories with projects in the $from-$to window
> + my %categories = build_projlist_by_category(\@projects);
Nice... but perhaps it would be better to simply pass $from / $to to
build_projlist_by_category function, and have in %categories only
projects which are shown... well, unless filtered out in
print_project_rows() by $show_ctags; so I think that there is nonzero
probability of empty (no project shown) categories.
> + foreach my $cat (sort keys %categories) {
> + my $num_cats = @{$categories{$cat}};
> +
> + # out of the window to display, done
> + last if defined $to and $to < 0;
> +
> + # in the window to display
> + if (!defined $from or $from < $num_cats) {
> + unless ($cat eq "") {
> + print "<tr>\n";
> + if ($check_forks) {
> + print "<td></td>\n";
> + }
> + print "<td class=\"category\" colspan=\"5\">$cat</td>\n";
> + print "</tr>\n";
> + }
> +
> + print_project_rows($categories{$cat}, $from, $to, $check_forks, $show_ctags);
> + }
> +
> + # adjust $from/$to offset, keep $from positive
> + $from = ($from > $num_cats) ? $from - $num_cats : 0 if defined $from;
> + $to -= $num_cats if defined $to;
I don't think that the games we play with $from / $to would be enough.
Check what happens (I think that it wouldn't work correctly) if we have
something like that:
project | category | shown
--------------------------
1 | A |
2 | A |
3 | B | Y
4 | C | Y
5 | B | Y
6 | C |
7 | C |
It means that we display for example second page in projects list.
> + }
> + } else {
> + print_project_rows(\@projects, $from, $to, $check_forks, $show_ctags);
> + }
Nice.
>
> if (defined $extra) {
> print "<tr>\n";
> --
> 1.5.6.5
>
>
I'll try to examine the code in more detail later... currently I don't
know why but I can't git-am the second patch (this patch) correctly...
--
Jakub Narębski
Poland
^ permalink raw reply
* [PATCH 0/4] Fix longstanding "git am" bug
From: Junio C Hamano @ 2008-12-05 2:22 UTC (permalink / raw)
To: git
Simon Schubert rerolled a patch to add "git am --directory=<dir>" from
three months ago, which is a good complement to existing "git am -p<n>",
but it had the same issue of duplicating an existing bug to the new feature.
Let's fix the existing bug first, before accepting any new feature, which
will happen after 1.6.1 goes final.
Junio C Hamano (4):
git-am --whitespace: do not lose the command line option
git-am: propagate -C<n>, -p<n> options as well
git-am: propagate --3way options as well
Test that git-am does not lose -C/-p/--whitespace options
git-am.sh | 15 +++++++++----
t/t4252-am-options.sh | 54 +++++++++++++++++++++++++++++++++++++++++++++++++
t/t4252/am-test-1-1 | 19 +++++++++++++++++
t/t4252/am-test-1-2 | 21 +++++++++++++++++++
t/t4252/am-test-2-1 | 19 +++++++++++++++++
t/t4252/am-test-2-2 | 21 +++++++++++++++++++
t/t4252/am-test-3-1 | 19 +++++++++++++++++
t/t4252/am-test-3-2 | 21 +++++++++++++++++++
t/t4252/am-test-4-1 | 19 +++++++++++++++++
t/t4252/am-test-4-2 | 22 ++++++++++++++++++++
t/t4252/file-1-0 | 7 ++++++
t/t4252/file-2-0 | 7 ++++++
12 files changed, 239 insertions(+), 5 deletions(-)
create mode 100755 t/t4252-am-options.sh
create mode 100644 t/t4252/am-test-1-1
create mode 100644 t/t4252/am-test-1-2
create mode 100644 t/t4252/am-test-2-1
create mode 100644 t/t4252/am-test-2-2
create mode 100644 t/t4252/am-test-3-1
create mode 100644 t/t4252/am-test-3-2
create mode 100644 t/t4252/am-test-4-1
create mode 100644 t/t4252/am-test-4-2
create mode 100644 t/t4252/file-1-0
create mode 100644 t/t4252/file-2-0
^ permalink raw reply
* [PATCH 1/4] git-am --whitespace: do not lose the command line option
From: Junio C Hamano @ 2008-12-05 2:22 UTC (permalink / raw)
To: git
In-Reply-To: <1228443780-3386-1-git-send-email-gitster@pobox.com>
When you start "git am --whitespace=fix" and the patch application process
is interrupted by an unapplicable patch early in the series, after
fixing the offending patch, the remainder of the patch should be processed
still with --whitespace=fix when restarted with "git am --resolved" (or
dropping the offending patch with "git am --skip").
The breakage was introduced by the commit 67dad68 (add -C[NUM] to git-am,
2007-02-08); this should fix it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
git-am.sh | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index aa60261..1bf70d4 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -121,7 +121,7 @@ It does not apply to blobs recorded in its index."
prec=4
dotest="$GIT_DIR/rebase-apply"
-sign= utf8=t keep= skip= interactive= resolved= rebasing= abort=
+sign= utf8=t keep= skip= interactive= resolved= rebasing= abort= ws=
resolvemsg= resume=
git_apply_opt=
@@ -156,7 +156,7 @@ do
--resolvemsg)
shift; resolvemsg=$1 ;;
--whitespace)
- git_apply_opt="$git_apply_opt $1=$2"; shift ;;
+ ws="--whitespace=$2"; shift ;;
-C|-p)
git_apply_opt="$git_apply_opt $1$2"; shift ;;
--)
@@ -283,7 +283,7 @@ if test "$(cat "$dotest/keep")" = t
then
keep=-k
fi
-ws=`cat "$dotest/whitespace"`
+ws=$(cat "$dotest/whitespace")
if test "$(cat "$dotest/sign")" = t
then
SIGNOFF=`git var GIT_COMMITTER_IDENT | sed -e '
@@ -454,7 +454,7 @@ do
case "$resolved" in
'')
- git apply $git_apply_opt --index "$dotest/patch"
+ git apply $git_apply_opt $ws --index "$dotest/patch"
apply_status=$?
;;
t)
--
1.6.1.rc1.60.g1d1d7
^ permalink raw reply related
* [PATCH 2/4] git-am: propagate -C<n>, -p<n> options as well
From: Junio C Hamano @ 2008-12-05 2:22 UTC (permalink / raw)
To: git
In-Reply-To: <1228443780-3386-2-git-send-email-gitster@pobox.com>
These options are meant to deal with patches that do not apply cleanly
due to the differences between the version the patch was based on and
the version "git am" is working on.
Because a series of patches applied in the same "git am" run tends to
come from the same source, it is more useful to propagate these options
after the application stops.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
git-am.sh | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index 1bf70d4..ed54e71 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -121,7 +121,7 @@ It does not apply to blobs recorded in its index."
prec=4
dotest="$GIT_DIR/rebase-apply"
-sign= utf8=t keep= skip= interactive= resolved= rebasing= abort= ws=
+sign= utf8=t keep= skip= interactive= resolved= rebasing= abort=
resolvemsg= resume=
git_apply_opt=
@@ -156,7 +156,7 @@ do
--resolvemsg)
shift; resolvemsg=$1 ;;
--whitespace)
- ws="--whitespace=$2"; shift ;;
+ git_apply_opt="$git_apply_opt $1=$2"; shift ;;
-C|-p)
git_apply_opt="$git_apply_opt $1$2"; shift ;;
--)
@@ -247,10 +247,10 @@ else
exit 1
}
- # -s, -u, -k and --whitespace flags are kept for the
- # resuming session after a patch failure.
+ # -s, -u, -k, --whitespace, -C and -p flags are kept
+ # for the resuming session after a patch failure.
# -3 and -i can and must be given when resuming.
- echo " $ws" >"$dotest/whitespace"
+ echo " $git_apply_opt" >"$dotest/apply_opt_extra"
echo "$sign" >"$dotest/sign"
echo "$utf8" >"$dotest/utf8"
echo "$keep" >"$dotest/keep"
@@ -283,7 +283,7 @@ if test "$(cat "$dotest/keep")" = t
then
keep=-k
fi
-ws=$(cat "$dotest/whitespace")
+git_apply_opt=$(cat "$dotest/apply_opt_extra")
if test "$(cat "$dotest/sign")" = t
then
SIGNOFF=`git var GIT_COMMITTER_IDENT | sed -e '
@@ -454,7 +454,7 @@ do
case "$resolved" in
'')
- git apply $git_apply_opt $ws --index "$dotest/patch"
+ git apply $git_apply_opt --index "$dotest/patch"
apply_status=$?
;;
t)
--
1.6.1.rc1.60.g1d1d7
^ permalink raw reply related
* [PATCH 3/4] git-am: propagate --3way options as well
From: Junio C Hamano @ 2008-12-05 2:22 UTC (permalink / raw)
To: git
In-Reply-To: <1228443780-3386-3-git-send-email-gitster@pobox.com>
The reasoning is the same as the previous patch, where we made -C<n>
and -p<n> propagate across a failure.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
git-am.sh | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index ed54e71..13c02d6 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -247,10 +247,11 @@ else
exit 1
}
- # -s, -u, -k, --whitespace, -C and -p flags are kept
+ # -s, -u, -k, --whitespace, -3, -C and -p flags are kept
# for the resuming session after a patch failure.
- # -3 and -i can and must be given when resuming.
+ # -i can and must be given when resuming.
echo " $git_apply_opt" >"$dotest/apply_opt_extra"
+ echo "$threeway" >"$dotest/threeway"
echo "$sign" >"$dotest/sign"
echo "$utf8" >"$dotest/utf8"
echo "$keep" >"$dotest/keep"
@@ -283,6 +284,10 @@ if test "$(cat "$dotest/keep")" = t
then
keep=-k
fi
+if test "$(cat "$dotest/threeway")" = t
+then
+ threeway=t
+fi
git_apply_opt=$(cat "$dotest/apply_opt_extra")
if test "$(cat "$dotest/sign")" = t
then
--
1.6.1.rc1.60.g1d1d7
^ permalink raw reply related
* [PATCH 4/4] Test that git-am does not lose -C/-p/--whitespace options
From: Junio C Hamano @ 2008-12-05 2:23 UTC (permalink / raw)
To: git
In-Reply-To: <1228443780-3386-4-git-send-email-gitster@pobox.com>
These tests make sure that "git am" does not lose command line options
specified when it was started, after it is interrupted by a patch that
does not apply earlier in the series.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
t/t4252-am-options.sh | 54 +++++++++++++++++++++++++++++++++++++++++++++++++
t/t4252/am-test-1-1 | 19 +++++++++++++++++
t/t4252/am-test-1-2 | 21 +++++++++++++++++++
t/t4252/am-test-2-1 | 19 +++++++++++++++++
t/t4252/am-test-2-2 | 21 +++++++++++++++++++
t/t4252/am-test-3-1 | 19 +++++++++++++++++
t/t4252/am-test-3-2 | 21 +++++++++++++++++++
t/t4252/am-test-4-1 | 19 +++++++++++++++++
t/t4252/am-test-4-2 | 22 ++++++++++++++++++++
t/t4252/file-1-0 | 7 ++++++
t/t4252/file-2-0 | 7 ++++++
11 files changed, 229 insertions(+), 0 deletions(-)
create mode 100755 t/t4252-am-options.sh
create mode 100644 t/t4252/am-test-1-1
create mode 100644 t/t4252/am-test-1-2
create mode 100644 t/t4252/am-test-2-1
create mode 100644 t/t4252/am-test-2-2
create mode 100644 t/t4252/am-test-3-1
create mode 100644 t/t4252/am-test-3-2
create mode 100644 t/t4252/am-test-4-1
create mode 100644 t/t4252/am-test-4-2
create mode 100644 t/t4252/file-1-0
create mode 100644 t/t4252/file-2-0
diff --git a/t/t4252-am-options.sh b/t/t4252-am-options.sh
new file mode 100755
index 0000000..1a1946d
--- /dev/null
+++ b/t/t4252-am-options.sh
@@ -0,0 +1,54 @@
+#!/bin/sh
+
+test_description='git am not losing options'
+. ./test-lib.sh
+
+tm="$TEST_DIRECTORY/t4252"
+
+test_expect_success setup '
+ cp "$tm/file-1-0" file-1 &&
+ cp "$tm/file-2-0" file-2 &&
+ git add file-1 file-2 &&
+ test_tick &&
+ git commit -m initial &&
+ git tag initial
+'
+
+test_expect_success 'interrupted am --whitespace=fix' '
+ rm -rf .git/rebase-apply &&
+ git reset --hard initial &&
+ test_must_fail git am --whitespace=fix "$tm"/am-test-1-? &&
+ git am --skip &&
+ grep 3 file-1 &&
+ grep "^Six$" file-2
+'
+
+test_expect_success 'interrupted am -C1' '
+ rm -rf .git/rebase-apply &&
+ git reset --hard initial &&
+ test_must_fail git am -C1 "$tm"/am-test-2-? &&
+ git am --skip &&
+ grep 3 file-1 &&
+ grep "^Three$" file-2
+'
+
+test_expect_success 'interrupted am -p2' '
+ rm -rf .git/rebase-apply &&
+ git reset --hard initial &&
+ test_must_fail git am -p2 "$tm"/am-test-3-? &&
+ git am --skip &&
+ grep 3 file-1 &&
+ grep "^Three$" file-2
+'
+
+test_expect_success 'interrupted am -C1 -p2' '
+ rm -rf .git/rebase-apply &&
+ git reset --hard initial &&
+ test_must_fail git am -p2 -C1 "$tm"/am-test-4-? &&
+ cat .git/rebase-apply/apply_opt_extra &&
+ git am --skip &&
+ grep 3 file-1 &&
+ grep "^Three$" file-2
+'
+
+test_done
diff --git a/t/t4252/am-test-1-1 b/t/t4252/am-test-1-1
new file mode 100644
index 0000000..b0c09dc
--- /dev/null
+++ b/t/t4252/am-test-1-1
@@ -0,0 +1,19 @@
+From: A U Thor <au.thor@example.com>
+Date: Thu Dec 4 16:00:00 2008 -0800
+Subject: Three
+
+Application of this should be rejected because the first line in the
+context does not match.
+
+diff --git i/file-1 w/file-1
+index 06e567b..10f8342 100644
+--- i/file-1
++++ w/file-1
+@@ -1,6 +1,6 @@
+ One
+ 2
+-3
++Three
+ 4
+ 5
+ 6
diff --git a/t/t4252/am-test-1-2 b/t/t4252/am-test-1-2
new file mode 100644
index 0000000..1b874ae
--- /dev/null
+++ b/t/t4252/am-test-1-2
@@ -0,0 +1,21 @@
+From: A U Thor <au.thor@example.com>
+Date: Thu Dec 4 16:00:00 2008 -0800
+Subject: Six
+
+Applying this patch with --whitespace=fix should lose
+the trailing whitespace after "Six".
+
+diff --git i/file-2 w/file-2
+index 06e567b..b6f3a16 100644
+--- i/file-2
++++ w/file-2
+@@ -1,7 +1,7 @@
+ 1
+ 2
+-3
++Three
+ 4
+ 5
+-6
++Six
+ 7
diff --git a/t/t4252/am-test-2-1 b/t/t4252/am-test-2-1
new file mode 100644
index 0000000..feda94a
--- /dev/null
+++ b/t/t4252/am-test-2-1
@@ -0,0 +1,19 @@
+From: A U Thor <au.thor@example.com>
+Date: Thu Dec 4 16:00:00 2008 -0800
+Subject: Three
+
+Application of this should be rejected even with -C1 because the
+preimage line in the context does not match.
+
+diff --git i/file-1 w/file-1
+index 06e567b..10f8342 100644
+--- i/file-1
++++ w/file-1
+@@ -1,6 +1,6 @@
+ 1
+ 2
+-Tres
++Three
+ 4
+ 5
+ 6
diff --git a/t/t4252/am-test-2-2 b/t/t4252/am-test-2-2
new file mode 100644
index 0000000..2ac6600
--- /dev/null
+++ b/t/t4252/am-test-2-2
@@ -0,0 +1,21 @@
+From: A U Thor <au.thor@example.com>
+Date: Thu Dec 4 16:00:00 2008 -0800
+Subject: Six
+
+Applying this patch with -C1 should be successful even though
+the first line in the context does not match.
+
+diff --git i/file-2 w/file-2
+index 06e567b..b6f3a16 100644
+--- i/file-2
++++ w/file-2
+@@ -1,7 +1,7 @@
+ One
+ 2
+-3
++Three
+ 4
+ 5
+-6
++Six
+ 7
diff --git a/t/t4252/am-test-3-1 b/t/t4252/am-test-3-1
new file mode 100644
index 0000000..608e5ab
--- /dev/null
+++ b/t/t4252/am-test-3-1
@@ -0,0 +1,19 @@
+From: A U Thor <au.thor@example.com>
+Date: Thu Dec 4 16:00:00 2008 -0800
+Subject: Three
+
+Application of this should be rejected even with -p2 because the
+preimage line in the context does not match.
+
+diff --git i/junk/file-1 w/junk/file-1
+index 06e567b..10f8342 100644
+--- i/junk/file-1
++++ w/junk/file-1
+@@ -1,6 +1,6 @@
+ 1
+ 2
+-Tres
++Three
+ 4
+ 5
+ 6
diff --git a/t/t4252/am-test-3-2 b/t/t4252/am-test-3-2
new file mode 100644
index 0000000..0081b96
--- /dev/null
+++ b/t/t4252/am-test-3-2
@@ -0,0 +1,21 @@
+From: A U Thor <au.thor@example.com>
+Date: Thu Dec 4 16:00:00 2008 -0800
+Subject: Six
+
+Applying this patch with -p2 should be successful even though
+the patch is against a wrong level.
+
+diff --git i/junk/file-2 w/junk/file-2
+index 06e567b..b6f3a16 100644
+--- i/junk/file-2
++++ w/junk/file-2
+@@ -1,7 +1,7 @@
+ 1
+ 2
+-3
++Three
+ 4
+ 5
+-6
++Six
+ 7
diff --git a/t/t4252/am-test-4-1 b/t/t4252/am-test-4-1
new file mode 100644
index 0000000..e48cd6c
--- /dev/null
+++ b/t/t4252/am-test-4-1
@@ -0,0 +1,19 @@
+From: A U Thor <au.thor@example.com>
+Date: Thu Dec 4 16:00:00 2008 -0800
+Subject: Three
+
+Application of this should be rejected even with -C1 -p2 because
+the preimage line in the context does not match.
+
+diff --git i/junk/file-1 w/junk/file-1
+index 06e567b..10f8342 100644
+--- i/junk/file-1
++++ w/junk/file-1
+@@ -1,6 +1,6 @@
+ 1
+ 2
+-Tres
++Three
+ 4
+ 5
+ 6
diff --git a/t/t4252/am-test-4-2 b/t/t4252/am-test-4-2
new file mode 100644
index 0000000..0e69bfa
--- /dev/null
+++ b/t/t4252/am-test-4-2
@@ -0,0 +1,22 @@
+From: A U Thor <au.thor@example.com>
+Date: Thu Dec 4 16:00:00 2008 -0800
+Subject: Six
+
+Applying this patch with -C1 -p2 should be successful even though
+the patch is against a wrong level and the first context line does
+not match.
+
+diff --git i/junk/file-2 w/junk/file-2
+index 06e567b..b6f3a16 100644
+--- i/junk/file-2
++++ w/junk/file-2
+@@ -1,7 +1,7 @@
+ One
+ 2
+-3
++Three
+ 4
+ 5
+-6
++Six
+ 7
diff --git a/t/t4252/file-1-0 b/t/t4252/file-1-0
new file mode 100644
index 0000000..06e567b
--- /dev/null
+++ b/t/t4252/file-1-0
@@ -0,0 +1,7 @@
+1
+2
+3
+4
+5
+6
+7
diff --git a/t/t4252/file-2-0 b/t/t4252/file-2-0
new file mode 100644
index 0000000..06e567b
--- /dev/null
+++ b/t/t4252/file-2-0
@@ -0,0 +1,7 @@
+1
+2
+3
+4
+5
+6
+7
--
1.6.1.rc1.60.g1d1d7
^ permalink raw reply related
* Re: [PATCH] git-p4: Fix bug in p4Where method.
From: Junio C Hamano @ 2008-12-05 2:23 UTC (permalink / raw)
To: Tor Arvid Lund; +Cc: Simon Hausmann, git
In-Reply-To: <1228397853-15921-1-git-send-email-torarvid@gmail.com>
Thanks. Will apply to 'master' and will be in 1.6.1 final, unless some p4
users object (I do not use p4 myself, so that is the best I could do).
^ permalink raw reply
* Re: summaries in git add --patch[PATCH 1/2]
From: Junio C Hamano @ 2008-12-05 2:23 UTC (permalink / raw)
To: William Pursell; +Cc: git
In-Reply-To: <4937B456.7080604@gmail.com>
William Pursell <bill.pursell@gmail.com> writes:
> Thanks for pointing that out. Settings changed. I do appreciate
> you taking the time to essentially hold my hand through this
> process, and hope that I'm not causing you too much extra work.
Heh, I'll be saving extra work I have to do in the future by training you
how to produce patches line the ones I may write myself. By doing so,
eventually I wouldn't have to code anything myself ;-)
> +# Generate a one line summary of a hunk.
> +sub summarize_hunk {
> + my $rhunk = shift;
> + my $summary = $rhunk->{TEXT}[0];
> +
> + # Keep the line numbers, discard extra context.
> + $summary =~ s/@@(.*?)@@.*/$1 /s;
> + $summary .= " " x (20 - length $summary);
> +
> + # Add some user context.
> + for my $line (@{$rhunk->{TEXT}}) {
> + if ($line =~ m/^[+-].*\w/) {
> + $summary .= $line;
> + last;
> + }
> + }
> +
> + chomp $summary;
> + return substr($summary, 0, 80) . "\n";
> +}
I'll queue the patches in this round as-is in 'pu' and merge to 'next', as
we should stop slushing around at some point and start polishing on a
solid ground. But as you mentioned, these hardcoded 20 and 80 do not look
very nice.
I think the division of labor between the data producer (summarize_hunk)
and presenter (display_hunks) should be shifted somewhat, so that
* summarize_hunk returns a two-tuple:
[ $line_number_hint, $first_change ]
* display_hunks runs summarize_hunk for all 20 hunks and gathers the
return values before producing a single line of output, and then
computes the maximum $line_number_hint to decide how many extra SP to
use to pad it to uniform length (instead of " " x (20 - length)).
After doing so, it loops over the hunks, using the collected return
values and formats.
In later round of polishing, you might find out that some callers of
summarize_hunk may want to read the full line, not just the first 80
(perhaps they feed their output to "less -S"). By splitting the
responsibility between these functions in the way outlined above, you do
not have to modify summarize_hunk when that day comes.
> +
> +
> +# Print a one-line summary of each hunk in the array ref in
> +# the first argument, starting wih the index in the 2nd.
> +sub display_hunks {
> + my ($hunks, $i) = @_;
> + my $ctr = 0;
> + $i ||= 0;
> + for (; $i < @$hunks && $ctr < 20; $i++, $ctr++) {
> + my $status = " ";
> + if (defined $hunks->[$i]{USE}) {
> + $status = $hunks->[$i]{USE} ? "+" : "-";
> + }
> + printf "%s%2d: %s",
> + $status,
> + $i + 1,
> + summarize_hunk($hunks->[$i]);
> + }
By the way, I do not think this will align if you have more than 100
hunks. That is also a reason why I would suggest not to format/substr
inside the summarize_hunk function.
^ permalink raw reply
* Re: [PATCH v3 3/3] gitweb: Optional grouping of projects by category
From: Sébastien Cevey @ 2008-12-05 2:32 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Junio C Hamano, Petr Baudis, Gustavo Sverzut Barbieri
In-Reply-To: <200812050308.52891.jnareb@gmail.com>
At Fri, 5 Dec 2008 03:08:52 +0100, Jakub Narebski wrote:
> Nice... but perhaps it would be better to simply pass $from / $to to
> build_projlist_by_category function, and have in %categories only
> projects which are shown...
Ah you're right, we could do that, I hadn't thought of it. Sounds
cleaner than the $from/$to dance I did in this patch.
> well, unless filtered out in print_project_rows() by $show_ctags; so
> I think that there is nonzero probability of empty (no project
> shown) categories.
Mh indeed, in fact this could happen any time we reach one of the
'next' statements in the loop in print_project_rows(), when performing
search, tag filtering, etc...
Actually, assuming the project list is split into page, this can also
lead to empty pages (if no project on the page matches the filter).
To avoid empty categories, it's a bit tricky since the header is
printed before we determine whether there are matching projects..
I need to read the code more carefully, but it seems that one solution
would be to add a function that determines whether a project should be
displayed or not (according to tags and search and forks); then we can
map this function on the list of projects.
I could do it if it sounds sane to you.
> I don't think that the games we play with $from / $to would be enough.
> Check what happens (I think that it wouldn't work correctly) if we have
> something like that:
>
> project | category | shown
> --------------------------
> 1 | A |
> 2 | A |
> 3 | B | Y
> 4 | C | Y
> 5 | B | Y
> 6 | C |
> 7 | C |
AFAIK this cannot happen with the current code, since projects are
grouped by category (according to the foreach on categories).
> I'll try to examine the code in more detail later... currently I don't
> know why but I can't git-am the second patch (this patch) correctly...
This is the third patch, are you sure you applied 1 and 2 before?
Thanks for your careful and supportive comments!
--
Sébastien Cevey / inso.cc
^ permalink raw reply
* Re: [PATCH v3 3/3] gitweb: Optional grouping of projects by category
From: Jakub Narebski @ 2008-12-05 10:45 UTC (permalink / raw)
To: Sébastien Cevey
Cc: git, Junio C Hamano, Petr Baudis, Gustavo Sverzut Barbieri
In-Reply-To: <87bpvr1hee.wl%seb@cine7.net>
On Fri, 5 Dec 2008 at 03:32, Sébastien Cevey wrote:
> At Fri, 5 Dec 2008 03:08:52 +0100, Jakub Narebski wrote:
>
> > Nice... but perhaps it would be better to simply pass $from / $to to
> > build_projlist_by_category function, and have in %categories only
> > projects which are shown...
>
> Ah you're right, we could do that, I hadn't thought of it. Sounds
> cleaner than the $from/$to dance I did in this patch.
Usually simpler is better. The more complicated code, the more chances
for bugs, and less maintability. I haven't even tried to follow
$from/$to updating logic, but noticed that we can simply pass $from
and $to to build_projlist_by_category(), and use loop $from..$to there.
> > well, unless filtered out in print_project_rows() by $show_ctags; so
> > I think that there is nonzero probability of empty (no project
> > shown) categories.
>
> Mh indeed, in fact this could happen any time we reach one of the
> 'next' statements in the loop in print_project_rows(), when performing
> search, tag filtering, etc...
>
> Actually, assuming the project list is split into page, this can also
> lead to empty pages (if no project on the page matches the filter).
> To avoid empty categories, it's a bit tricky since the header is
> printed before we determine whether there are matching projects..
>
> I need to read the code more carefully, but it seems that one solution
> would be to add a function that determines whether a project should be
> displayed or not (according to tags and search and forks); then we can
> map this function on the list of projects.
>
> I could do it if it sounds sane to you.
Nah, I think it would be best to postpone dealing with this issue, and
keep the code simple at the cost of possibly empty categories. It is
not as empty categories are an actual error...
I guess that correct way to deal with this would be to filter projects
earlier, before grouping by category, and not "at the last minute",
when displaying them. It might be even better solution wrt. dividing
projects list into pages. But that in my opinion is certainly matter
for a separate patch.
> > I'll try to examine the code in more detail later... currently I don't
> > know why but I can't git-am the second patch (this patch) correctly...
>
> This is the third patch, are you sure you applied 1 and 2 before?
Somehow I couldn't apply second patch in series:
$ git am -3 -u "[PATCH v3 2_3] gitweb: Split git_project_list_body in two functions.txt"
Applying: gitweb: Split git_project_list_body in two functions
error: patch failed: gitweb/gitweb.perl:3972
error: gitweb/gitweb.perl: patch does not apply
fatal: sha1 information is lacking or useless (gitweb/gitweb.perl).
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001.
> Thanks for your careful and supportive comments!
You are welcome. Nice to have another gitweb developer :-)
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: git-gui: Warn when username and e-mail address is unconfigured?
From: Alexander Gavrilov @ 2008-12-05 11:01 UTC (permalink / raw)
To: Jeremy Ramer
Cc: Junio C Hamano, spearce, sverre, Peter Krefting, Git Mailing List
In-Reply-To: <b9fd99020812041558w204e5f48gbed73fdbd289ad@mail.gmail.com>
On Fri, Dec 5, 2008 at 2:58 AM, Jeremy Ramer <jdramer@gmail.com> wrote:
> Yes, that does appear to be the message I get, with the following
> environment variables:
> - GIT_AUTHOR_EMAIL
> - GIT_COMMITTER_NAME
> - GIT_COMMITER_EMAIL
> - GIT_AUTHOR_NAME
>
> Now that I look closer I see that I am setting these in my .bashrc
> file. When I first started using git a year ago I was given the
> impression that these were needed. But I see that that is no longer
> the case since I use the config:
>
> git config --global user.name "Your Name"
> git config --global user.email "you@example.com"
>
> Removing them from my .bashrc removes the warning. In hindsight the
> warning should have clued me in, but I've been seeing that message
> since I first started using git on Cygwin so I figured it was a cygwin
> issue that I couldn't do anything about.
>
I wonder if what the warning says is still true. It's 2 years since
it was added, so the issue might have been fixed.
If you run "GIT_AUTHOR_NAME=foobar git gui", and make a commit,
does it set the author name to 'foobar'?
Alexander
^ permalink raw reply
* Using repo to work with multiple GIT repositories
From: kanagesh radhakrishnan @ 2008-12-05 11:20 UTC (permalink / raw)
To: git
Hello All,
My work currently resides in four different source trees, namely:
* bootloaders (git://192.168.10.1/bootloaders)
* kernel (git://192.168.10.1/kernel)
* applications (git://192.168.10.1/apps)
* build (git://192.168.10.1/build)
I maintain them as four different git repositories. They are hosted
on a local server enabling any other developer to be able to clone
from one of the trees, make changes, commit locally and then push to
the git server.
I was browsing through the Android source code and found that they
have a similar situation where code is maintained in a large number of
independent GIT repositories. The tool 'repo' is being used to
initialize and sync each tree.
I have been trying to bring in this approach to maintain my work too.
I have had success to some extent :-) I have created a manifest.git
and repo.git in my local server. The default.xml file being
maintained in manifest.git has a list of the GIT repositories being
hosted by my local GIT server.
In order to clone the four GIT trees from the server, I do the following:
$ repo init -u git://192.168.10.1/manifest.git
$ repo sync
This clones from the four source trees maintained in the GIT server.
I am able to make changes locally in each tree and commit them.
However, when I attempt to push the commits to the main repository on
the GIT server, it always says that 'everything is up to date'
$ git push user@192.168.10.1:/home/git/applications
user@192.168.10.1's password:
Everything up-to-date
Further, when I try to pull in any recent updates with the git-pull
command, I get the following error:
$ git-pull
fatal: 'origin': unable to chdir or not a git archive
fatal: The remote end hung up unexpectedly
I know pushing to the repository on the GIT server works since I am
able to push local commits when I have cloned the working copy
manually (instead of using repo init and repo sync).
-----------------------------------------------------------------
$ git-clone git://192.168.10.1/applications
Initialized empty Git repository in /home/user/work/applications/.git/
remote: Counting objects: 6857, done.
remote: Compressing objects: 100% (3805/3805), done.
remote: Total 6857 (delta 2943), reused 6853 (delta 2941)
Receiving objects: 100% (6857/6857), 9.51 MiB | 10547 KiB/s, done.
Resolving deltas: 100% (2943/2943), done.
$
<edit, make changes, save, commit changes locally>
$ git-commit -a -m "Changed rule to build with custom tools"
Created commit bd55a06: Changed rule to build with custom tools
1 files changed, 1 insertions(+), 1 deletions(-)
$
<push changes to repository on GIT server>
$ git-push user@192.168.10.1:/home/git/applications
user@192.168.10.1's password:
Counting objects: 8, done.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (6/6), 611 bytes, done.
Total 6 (delta 4), reused 0 (delta 0)
To user@192.168.10.1:/home/git/applications
dce4bea..bd55a06 master -> master
$
-----------------------------------------------------------------
May I know what I have to look at to solve this problem? Has anyone
faced a similar problem? Any pointers would be of help.
Thanks in advance.
Regards,
Kanagesh
^ permalink raw reply
* Re: [PATCH 2/4] git-am: propagate -C<n>, -p<n> options as well
From: Johannes Schindelin @ 2008-12-05 12:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1228443780-3386-3-git-send-email-gitster@pobox.com>
Hi,
On Thu, 4 Dec 2008, Junio C Hamano wrote:
> - echo " $ws" >"$dotest/whitespace"
> + echo " $git_apply_opt" >"$dotest/apply_opt_extra"
>From the other scripts, it appears we have sort of a convention to use
dashes instead of underscores for file names (see e.g.
$dotest/patch-merge-tmp-dir).
Other than that, the whole series looks good to me.
Thanks for the work, especially the tests,
Dscho
^ permalink raw reply
* Re: git alias always chdir to top
From: Pete Wyckoff @ 2008-12-05 14:09 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20081204123402.GA23740@coredump.intra.peff.net>
peff@peff.net wrote on Thu, 04 Dec 2008 07:34 -0500:
> On Wed, Dec 03, 2008 at 11:08:52AM -0500, Pete Wyckoff wrote:
>
> > It looks like handle_alias() uses setup_git_directory_gently() to
> > find the .git, which chdir()s up until it gets there. Is there a
> > way to do this without changing the process current working
> > directory instead? I could even handle an environment variable
> > saving the original cwd, but that's ickier.
>
> There has been some discussion of refactoring the setup to _not_ do that
> chdir until later, which should fix your problem. And other problems,
> too, since aliases can get confused about whether or not we're in a
> worktree (try "git config alias.st status && cd .git && git st") as a
> result of the startup sequence. Ideally the _only_ thing to happen
> before running an alias would be to look at the config to see how to run
> the alias, and everything else would be "as if" you had just run the
> alias manually.
>
> So no, there's no way to do it correctly right now. The git commands
> internally do know the original prefix, but I don't think it is exposed
> via the environment.
>
> I hope this will get fixed eventually, but refactoring this code is
> unpleasant enough and I have been busy enough that it hasn't happened
> yet. You are of course welcome to volunteer. ;)
Thanks for these comments. I missed the discussion about
refactoring to move the chdir around.
In my particular case, since the only usage of this particular git
alias is by another script, I can get away with passing the full
path name and making some assumptions about the caller.
Point taken that it would be good to clean up the alias code path
so that this issue doesn't even arise in the first place.
-- Pete
^ permalink raw reply
* ETA for release of gjit 0.4?
From: Farrukh Najmi @ 2008-12-05 14:34 UTC (permalink / raw)
To: git
Dear colleagues,
I am using jgit in my maven project. Since current version is a SNAPSHOT
(0.4-SNAPSHOT) I cannot release my project with a SNAPSHOT dependency
(maven does not allow it). WHat is the time line for releasing version
0.4 of jgit so I can plan accordingly.
Thanks for any info.
--
Regards,
Farrukh Najmi
Web: http://www.wellfleetsoftware.com
^ permalink raw reply
* Re: Git weekly news: 2008-49
From: Jakub Narebski @ 2008-12-05 16:02 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git list
In-Reply-To: <94a0d4530812041643r784ae8b1x242e3b2f9c9f41@mail.gmail.com>
"Felipe Contreras" <felipe.contreras@gmail.com> writes:
> Hi there,
>
> I've been following the git tag at delicious.com[1] and there's quite
> many interesting links, so I thought on gathering them so the git
> community can enjoy them in one pack :)
Nice work, although I think better alternative would be to weed those
links out, and put them in appropriate sections (or subsections) on
Git Wiki; to be more exact on http://git.or.cz/gitwiki/GitLinks
> The blog post is here:
> http://gitlog.wordpress.com/2008/12/05/git-weekely-news-2008-49/
First, "Official git blog"? Official? There is nothing official about
it. "Unofficial git blog", or "A git developer blog" (or "A git
follower blog"; unfortunately names like gitter or gitster for git
power user's, like TeXnician for TeX users, are taken by nicknames on
#git, if I remember correctly). Only git maintainer (Junio Hamano)
and git development community (the git mailing list) can decide that
something is "official" resource.
Second, I am a bit curious about 49 in "Git weekly news: 2008-49"
name of the post.
Third, it is collection of links, not news[1].
[1] It would be nice if somebody resurrected GitTraffic, offshot of
now defunct KernelTraffic, or at least helped to write Git articles
for KernelTrap (which currently is in a bit of hiatus).
>
> But here are the links anyway. The order is rather random.
Moreover the _quality_ of those links is very random.
> Why Git is Better than X
> http://whygitisbetterthanx.com/
Quite good link from what I superficially checked, present in
GitComparison wiki page.
>
> GitTorrent, The Movie
> http://www.advogato.org/article/994.html
This article is so full of bad information, exaggeration and
hyperbole, that it would be better to forget about it, and not put it
in the list.
> Peer-to-peer Protocol for Synchronizing of Git Repositories
> http://code.google.com/p/gittorrent/
Not news.
>
> Codebase - Git repository hosting with source browser, changesets,
> ticketing & deployment tracking.
> http://atechmedia.com/codebase
Not news. Besides it is present in GitHosting wiki page.
>
> Codebase Launches Git-based Project Management Service
> http://www.sitepoint.com/blogs/2008/12/04/codebase-launches-git-based-project-management-service/
Good link, perhaps should be added as 'see also' on GitHosting wiki
page, if it is not there already.
>
> The Git Community Book
> http://book.git-scm.com/index.html
http://book.git-scm.com/
Good link, present in GitDocumentation. But not news link.
>
> GitX: A git GUI specifically for Mac OS X
> http://gitx.frim.nl/index.html
On InterfacesFrontendsAndTools. But not a news link.
>
> Pushing and pulling with Git, part 1
> http://www.gnome.org/~federico/news-2008-11.html#pushing-and-pulling-with-git-1
Very good documentation, with nicely done graphic.
> $ cheat git
> http://cheat.errtheblog.com/s/git/
A bit big for a cheat _sheet_. perhaps it should be added to
GitCheatSheet (see example here for cheat _sheet_) and/or to
GitDocumentation wiki page.
> gh > hg
> http://github.com/blog/218-gh-hg
Seems to be a bit of curio. Not important enough to place it in
GitLinks, IMVHO.
>
> Easy Git External Dependency Management with Giternal
> http://www.rubyinside.com/giternal-easy-git-external-dependency-management-1322.html
Present on BlogPosts. Might be not as important as article about
Gitosis, because 1.) you can do this by hand, 2.) there are alternate
tools, like Piston, Giston -> Braid.
> Work with Git from Emacs
> http://xtalk.msk.su/~ott/en/writings/emacs-vcs/EmacsGit.html
Very good article, presenting various Emacs modules to work with
Git. Currently as far as I know not present on Git Wiki, but present
on 'Git' page on Emacs Wiki.
>
> It's Magit! A Emacs mode for Git.
> http://zagadka.vm.bytemark.co.uk/magit/
Probably should be added (as the rest of Emacs modes) to the
InterfacesFrontendsAndTools git wiki page.
>
> Improving my git workflow
> http://hoth.entp.com/2008/11/10/improving-my-git-workflow
This post is mainly about the same as
http://graysky.org/2008/12/git-branch-auto-tracking/
namely setting tracking information for _pushed_ branch, using single
command.
This could have been added to BlogPosts git wiki page.
>
> git-bz: Bugzilla subcommand for Git
> http://blog.fishsoup.net/2008/11/16/git-bz-bugzilla-subcommand-for-git/
Should be added in addition to git-bugzila to appropriate section at
InterfacesFrontendsAndTools wiki page. Good link.
>
> android.git.kernel.org Git
> http://android.git.kernel.org/
Is at GitProjects, but thanks for reminding about new server (new
URL). Not a news.
>
> GitSvnComparsion
> http://git.or.cz/gitwiki/GitSvnComparsion
No comment.
>
> Guides: Developing with Submodules
> http://github.com/guides/developing-with-submodules
Seems like a good reference. Probably should be added to both
GitSubmodules and BlogPosts pages at git wiki.
>
> A web-focused Git workflow
> http://joemaller.com/2008/11/25/a-web-focused-git-workflow/
I have't read it in detail, so I don't know if the workflow described
there makes sense. I would probably create some rule in Makefile and
use "make publish" or something, which would push the chages _and_
update page, or use post-update hook for that using some 'git-export'
equivalent.
Otherwise from first glance looks like good resource.
>
> Why we chose Git, a rebuttal
> http://www.unethicalblogger.com/posts/2008/11/why_we_chose_git_a_rebuttal
Nice reference I think, either for GitComparison or BlogPosts (in the
"Praise" section), or GitLinks.
> Git'n Your Shared Host On
> http://railstips.org/2008/11/24/gitn-your-shared-host-on
Not something that one cannot find in basic git documentation, but in
"Further Reading" it has nice selection of links.
>
> Git integration with Hudson and Trac
> http://www.unethicalblogger.com/posts/2008/11/git_integration_with_hudson_and_trac
Nice example of post-receive hook. Either for BlogPosts or
InterfacesFrontendsAndTools page.
> Everyday GIT With 20 Commands Or So
> http://www.kernel.org/pub/software/scm/git/docs/everyday.html
No comment.
>
> Hosting Git repositories, The Easy (and Secure) Way
> http://scie.nti.st/2007/11/14/hosting-git-repositories-the-easy-and-secure-way
Seminal reference, can be found at BlogPosts page on git wiki.
Very good link.
>
> 10 Reasons to Use Git for Research
> http://mendicantbug.com/2008/11/30/10-reasons-to-use-git-for-research/
Very nice article.
>
> [1] http://delicious.com/tag/git
I have a host of links to blog posts with git or distributed version
control info bookmarked...
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* [StGit] what happened to stg diff -r /{bottom|top}?
From: Dan Williams @ 2008-12-05 16:54 UTC (permalink / raw)
To: catalin.marinas; +Cc: git
I noticed that with the latest StGit:
# stg diff -r /bottom
stg diff: /bottom: Unknown patch or revision name
Before I bisect to find where this disappeared, is there a different
syntax I should be using?
Thanks,
Dan
^ permalink raw reply
* Re: Git weekly news: 2008-49
From: Michael J Gruber @ 2008-12-05 17:00 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Felipe Contreras, git list
In-Reply-To: <m3d4g6ipah.fsf@localhost.localdomain>
Jakub Narebski venit, vidit, dixit 05.12.2008 17:02:
> "Felipe Contreras" <felipe.contreras@gmail.com> writes:
>
>> Hi there,
>>
>> I've been following the git tag at delicious.com[1] and there's quite
>> many interesting links, so I thought on gathering them so the git
>> community can enjoy them in one pack :)
>
> Nice work, although I think better alternative would be to weed those
> links out, and put them in appropriate sections (or subsections) on
> Git Wiki; to be more exact on http://git.or.cz/gitwiki/GitLinks
>
>> The blog post is here:
>> http://gitlog.wordpress.com/2008/12/05/git-weekely-news-2008-49/
>
> First, "Official git blog"? Official? There is nothing official about
> it. "Unofficial git blog", or "A git developer blog" (or "A git
> follower blog"; unfortunately names like gitter or gitster for git
> power user's, like TeXnician for TeX users, are taken by nicknames on
> #git, if I remember correctly). Only git maintainer (Junio Hamano)
> and git development community (the git mailing list) can decide that
> something is "official" resource.
>
> Second, I am a bit curious about 49 in "Git weekly news: 2008-49"
> name of the post.
Since it's "weekly" and this week is week number 49 in this year I have
a certain guess ;)
The blog has 2 entries only: That one and the wordpress welcome thingy...
>> Why Git is Better than X
>> http://whygitisbetterthanx.com/
>
> Quite good link from what I superficially checked, present in
> GitComparison wiki page.
Very nice indeed. Minor nitpick is comparing "hg add" to "git add" and
"hg commit" to "git commit -a", I'm discussing this with Scott already.
But very nice overall.
Cheers,
Michael
P.S.: For the record or in case anyone ?oogles this:
- compare "hg add" to "git add -N" and "hg commit" to "git commit -a",
which compares equivalent commands, or
- compare "hg add" to "git add" and "hg commit" to "git commit" (after
git add, but time "git commit" only), which compares similar sounding
commands; here, the sequence of commands is equivalent, just not the
individual ones
^ permalink raw reply
* Re: Git weekly news: 2008-49
From: Felipe Contreras @ 2008-12-05 17:46 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git list
In-Reply-To: <m3d4g6ipah.fsf@localhost.localdomain>
On Fri, Dec 5, 2008 at 6:02 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> "Felipe Contreras" <felipe.contreras@gmail.com> writes:
>
>> Hi there,
>>
>> I've been following the git tag at delicious.com[1] and there's quite
>> many interesting links, so I thought on gathering them so the git
>> community can enjoy them in one pack :)
>
> Nice work, although I think better alternative would be to weed those
> links out, and put them in appropriate sections (or subsections) on
> Git Wiki; to be more exact on http://git.or.cz/gitwiki/GitLinks
Right, but next week the links will be different. This time the links
where not really from this week, but they will be on the next
iterations.
Somebody could pick the relevant links and add them in the wiki.
>> The blog post is here:
>> http://gitlog.wordpress.com/2008/12/05/git-weekely-news-2008-49/
>
> First, "Official git blog"? Official? There is nothing official about
> it. "Unofficial git blog", or "A git developer blog" (or "A git
> follower blog"; unfortunately names like gitter or gitster for git
> power user's, like TeXnician for TeX users, are taken by nicknames on
> #git, if I remember correctly). Only git maintainer (Junio Hamano)
> and git development community (the git mailing list) can decide that
> something is "official" resource.
I asked in the mailing list and the only comment I got was: go ahead.
So yeah, that doesn't look like an "official" blessing, but it's not
bad either.
Anyway, my idea is that many gitsters will participate on this blog,
it's not my personal blog, I already have one.
Who wants an account?
> Second, I am a bit curious about 49 in "Git weekly news: 2008-49"
> name of the post.
It's the week number.
> Third, it is collection of links, not news[1].
True, "Git weekly links" sounds better?
> [1] It would be nice if somebody resurrected GitTraffic, offshot of
> now defunct KernelTraffic, or at least helped to write Git articles
> for KernelTrap (which currently is in a bit of hiatus).
>
>>
>> But here are the links anyway. The order is rather random.
>
> Moreover the _quality_ of those links is very random.
Exactly, I didn't choose them, that's what people have been tagging as
"git" in delicious.com. I'm subscribed to the RSS feed and saving the
ones that appear a lot.
In fact I don't like some of them, but that's what the "public" finds
interesting.
>> Why Git is Better than X
>> http://whygitisbetterthanx.com/
>
> Quite good link from what I superficially checked, present in
> GitComparison wiki page.
>
>>
>> GitTorrent, The Movie
>> http://www.advogato.org/article/994.html
>
> This article is so full of bad information, exaggeration and
> hyperbole, that it would be better to forget about it, and not put it
> in the list.
It's popular, and a lot of people find it interesting. /me shrugs
>> Peer-to-peer Protocol for Synchronizing of Git Repositories
>> http://code.google.com/p/gittorrent/
>
> Not news.
Right, but it is to many people.
<snip/>
Thanks for the comments, but gathering all these links is already
taking me more time that I wished.
> I have a host of links to blog posts with git or distributed version
> control info bookmarked...
My objective is to do this weekly. Maybe I'll put the links in a git
repo so people can see them before I make the post. Would you find
that useful?
As an example of possible links for next week:
My RubyGems development tools and workflow
http://drnicwilliams.com/2008/12/05/my-rubygems-development-tools-and-workflow/
Pushr, or the application will deploy itself
http://www.restafari.org/pushr-or-the-application-will-deploy-itself.html
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH 2/4] git-am: propagate -C<n>, -p<n> options as well
From: Junio C Hamano @ 2008-12-05 19:18 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0812051320170.7062@intel-tinevez-2-302>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Thu, 4 Dec 2008, Junio C Hamano wrote:
>
>> - echo " $ws" >"$dotest/whitespace"
>> + echo " $git_apply_opt" >"$dotest/apply_opt_extra"
>
>>From the other scripts, it appears we have sort of a convention to use
> dashes instead of underscores for file names (see e.g.
> $dotest/patch-merge-tmp-dir).
You are right. And there is no reason to call it "extra" either.
git-am.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git c/git-am.sh w/git-am.sh
index 13c02d6..4b157fe 100755
--- c/git-am.sh
+++ w/git-am.sh
@@ -250,7 +250,7 @@ else
# -s, -u, -k, --whitespace, -3, -C and -p flags are kept
# for the resuming session after a patch failure.
# -i can and must be given when resuming.
- echo " $git_apply_opt" >"$dotest/apply_opt_extra"
+ echo " $git_apply_opt" >"$dotest/apply-opt"
echo "$threeway" >"$dotest/threeway"
echo "$sign" >"$dotest/sign"
echo "$utf8" >"$dotest/utf8"
@@ -288,7 +288,7 @@ if test "$(cat "$dotest/threeway")" = t
then
threeway=t
fi
-git_apply_opt=$(cat "$dotest/apply_opt_extra")
+git_apply_opt=$(cat "$dotest/apply-opt")
if test "$(cat "$dotest/sign")" = t
then
SIGNOFF=`git var GIT_COMMITTER_IDENT | sed -e '
^ permalink raw reply related
* Re: Git weekly news: 2008-49
From: Jakub Narebski @ 2008-12-05 19:27 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git list
In-Reply-To: <94a0d4530812050946r5ea7ddb2v1d93d28ba679813b@mail.gmail.com>
On Fri, Dec 5, 2008 at 18:46, Felipe Contreras wrote:
> On Fri, Dec 5, 2008 at 6:02 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>> "Felipe Contreras" <felipe.contreras@gmail.com> writes:
>>
>>> Hi there,
>>>
>>> I've been following the git tag at delicious.com[1]
By the way, from time to time I search blogs using either Technorati
searching for "http://git.or.cz", or Google Blog Search searching
either for "link:git.or.cz" or "Distributed Version Control".
BTW. funny thing that Google _Blog_ Search sometimes returns a host
of links to 'commit' view of gitweb... :-)
>>> and there's quite
>>> many interesting links, so I thought on gathering them so the git
>>> community can enjoy them in one pack :)
>>
>> Nice work, although I think better alternative would be to weed those
>> links out, and put them in appropriate sections (or subsections) on
>> Git Wiki; to be more exact on http://git.or.cz/gitwiki/GitLinks
>
> Right, but next week the links will be different. This time the links
> where not really from this week, but they will be on the next
> iterations.
>
> Somebody could pick the relevant links and add them in the wiki.
Well, if it is mainly as the place for "weekly links", it has some
purpose as it. And finding the links, perhaps with some minimal
reduction (removing duplicates and such), is much easier and takes
much less time than selecting "links of impact" for GitLinks page,
or selecting other page like BlogPosts, GitComparison, GitDocumentation
or InterfacesFrontendsAndTools git wiki page to add link to.
>>> The blog post is here:
>>> http://gitlog.wordpress.com/2008/12/05/git-weekely-news-2008-49/
>>
>> First, "Official git blog"? Official? There is nothing official about
>> it. "Unofficial git blog", or "A git developer blog" (or "A git
>> follower blog"; unfortunately names like gitter or gitster for git
>> power user's, like TeXnician for TeX users, are taken by nicknames on
>> #git, if I remember correctly). Only git maintainer (Junio Hamano)
>> and git development community (the git mailing list) can decide that
>> something is "official" resource.
>
> I asked in the mailing list and the only comment I got was: go ahead.
> So yeah, that doesn't look like an "official" blessing, but it's not
> bad either.
Ah, I didn't remember about it.
>
> Anyway, my idea is that many gitsters will participate on this blog,
> it's not my personal blog, I already have one.
>
> Who wants an account?
Still it looks more like "A git blog" than "Official git blog".
>> Third, it is collection of links, not news[1].
>
> True, "Git weekly links" sounds better?
Yes, IMHO it is better name.
>>>
>>> But here are the links anyway. The order is rather random.
>>
>> Moreover the _quality_ of those links is very random.
>
> Exactly, I didn't choose them, that's what people have been tagging as
> "git" in delicious.com. I'm subscribed to the RSS feed and saving the
> ones that appear a lot.
>
> In fact I don't like some of them, but that's what the "public" finds
> interesting.
Well, I think that people would treat those collection of links as
collection of links to _sensible_ contents. So at least put such links
in the "Controversial" (or something like that) section.
> <snip/>
>
> Thanks for the comments, but gathering all these links is already
> taking me more time that I wished.
>
>> I have a host of links to blog posts with git or distributed version
>> control info bookmarked...
>
> My objective is to do this weekly. Maybe I'll put the links in a git
> repo so people can see them before I make the post. Would you find
> that useful?
I don't think so.
.....................................................................
> As an example of possible links for next week:
> My RubyGems development tools and workflow
> http://drnicwilliams.com/2008/12/05/my-rubygems-development-tools-and-workflow/
How it is about git?
> Pushr, or the application will deploy itself
> http://www.restafari.org/pushr-or-the-application-will-deploy-itself.html
Nice article, extending on article about Git support for Capistrano.
Worth reading, I think, at least for Rubyists (RnR) here...
--
Jakub Narebski
Poland
^ permalink raw reply
* why not preserve file permissions?
From: jidanni @ 2008-12-05 20:08 UTC (permalink / raw)
To: git
Why not preserve permissions the way you find them, instead of just
using 644 and 755? It certainly couldn't be more complicated than what
you are doing now, and that way one could do things like use git to
update system administration files across a sneakernet containing e.g.,
# dlocate -lsconf exim4-config|sed 's/ .*//'|sort -u
-rw-r-----
-rw-r--r--
-rwxr-xr-x
> git was made for tracking source code, not 640 files.
On the sneakernet no public patches would be sent, and the
administrator would remember to make the sensitive .git directories
700. And sure, git should enforce umask or no set-uid or whatever when
doing a checkout etc. The deluxe edition of git could even print a
warning: "you are trying to track a 640 file but your .git permissions
are less restrictive." However I recommend no premium or deluxe
editions for now.
> Patches welcome.
Trust me, you don't want "grandpa who forgot the parking brake"
anywhere near your code.
^ permalink raw reply
* Re: git-gui: Warn when username and e-mail address is unconfigured?
From: Jeremy Ramer @ 2008-12-05 20:18 UTC (permalink / raw)
To: Alexander Gavrilov
Cc: Junio C Hamano, spearce, sverre, Peter Krefting, Git Mailing List
In-Reply-To: <bb6f213e0812050301t2f18061epfeff7bc74ee6f28a@mail.gmail.com>
On Fri, Dec 5, 2008 at 4:01 AM, Alexander Gavrilov <angavrilov@gmail.com> wrote:
> On Fri, Dec 5, 2008 at 2:58 AM, Jeremy Ramer <jdramer@gmail.com> wrote:
>> Yes, that does appear to be the message I get, with the following
>> environment variables:
>> - GIT_AUTHOR_EMAIL
>> - GIT_COMMITTER_NAME
>> - GIT_COMMITER_EMAIL
>> - GIT_AUTHOR_NAME
>>
>> Now that I look closer I see that I am setting these in my .bashrc
>> file. When I first started using git a year ago I was given the
>> impression that these were needed. But I see that that is no longer
>> the case since I use the config:
>>
>> git config --global user.name "Your Name"
>> git config --global user.email "you@example.com"
>>
>> Removing them from my .bashrc removes the warning. In hindsight the
>> warning should have clued me in, but I've been seeing that message
>> since I first started using git on Cygwin so I figured it was a cygwin
>> issue that I couldn't do anything about.
>>
>
> I wonder if what the warning says is still true. It's 2 years since
> it was added, so the issue might have been fixed.
>
> If you run "GIT_AUTHOR_NAME=foobar git gui", and make a commit,
> does it set the author name to 'foobar'?
I ran
export GIT_AUTHOR_NAME="foobar git gui"
and then made a commit with git gui and it did not set the author name
to foobar. It used my global config name.
>
> Alexander
>
^ 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