* git-svn branches with revision id's in name
From: Stephen Duncan Jr @ 2012-01-30 19:42 UTC (permalink / raw)
To: git
A project I work on recently changed it's SVN structure, causing me to
do a new git svn clone. The new structure is like this:
{project}/branches/
/master
/develop
/qa
/feature
/feature1
/feature2
/release
/release1
/release2
/hotfix
/hotfix1
/hotfix2
So I set up my svn-remote sections as follows:
[svn-remote "svn"]
url = {url}
fetch = {project}/branches/master:refs/remotes/trunk
fetch = {project}/branches/develop:refs/remotes/develop
fetch = {project}/branches/qa:refs/remotes/qa
branches = {project}/branches/{feature,release,hotfix}/*:refs/remotes/*/*
This seems to have worked fine, for the most part, but unlike my
previous git-svn checkouts, it has created several branches with
revision numbers as part of the name:
$ git branch -a
* master
remotes/develop
remotes/develop@29271
remotes/develop@32463
remotes/develop@34103
remotes/feature/xyz
remotes/feature/xyz@26438
remotes/feature/xyz@27542
remotes/feature/xyz@35233
Why have these remote branches been created? What impact does this
have on my checkout? Can I remove safely remove them? How? I was
unable to figure out how to reference this behavior in order to search
for information on it.
--
Stephen Duncan Jr
www.stephenduncanjr.com
^ permalink raw reply
* Re: [PATCH v5 2/5] gitweb: add project_filter to limit project list to a subdirectory
From: Bernhard R. Link @ 2012-01-30 20:03 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git
In-Reply-To: <201201301657.12944.jnareb@gmail.com>
* Jakub Narebski <jnareb@gmail.com> [120130 16:56]:
> On Mon, 30 Jan 2012, Bernhard R. Link wrote:
>
> > This commit changes the project listing views (project_list,
> > project_index and opml) to limit the output to only projects in a
> > subdirectory if the new optional parameter ?pf=directory name is
> > used.
>
> It would be nice to have in this or in a separate commit an update
> to get_page_title() for HTML output, and to git_opml() updating
> <title> element in OPML output, so that it mentions that project
> list is limitied to $project_filter subdirectory.
Indeed. I overlooked that.
> > Reusing $project instead of adding a new parameter would have been
> > nicer from a UI point-of-view (including PATH_INFO support) but
> > would complicate the $project validating code that is currently
> > being used to ensure nothing is exported that should not be viewable.
>
> Nb. I wonder if we should make it invalid to have both 'project' and
> 'project_filter' parameters...
$project_filter should be ignored when $project is defined which is
enforced in all but those three actions.
action=project_list gets confused (shows wrong breadcrumbs) if $project
is defined, but that is unrelated to this changes, so one might to fix
that independently.
I'll resend the series as replies to this mail. What to do next? Wait
foranother explitit Acked-By of those? Or resend it to gitster@pobox.com
if no new issues are found?
Bernhard R. Link
^ permalink raw reply
* [PATCH 1/6] gitweb: move hard coded .git suffix out of git_get_projects_list
From: Bernhard R. Link @ 2012-01-30 20:05 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git
In-Reply-To: <20120130200355.GA2584@server.brlink.eu>
Use of the filter option of git_get_projects_list is currently
limited to forks. It hard codes removal of ".git" suffixes from
the filter.
To make it more generic move the .git suffix removal to the callers.
Signed-off-by: Bernhard R. Link <brlink@debian.org>
---
Changes to v5.5:
- split first patch in two as suggested by Jakub Narebski
---
gitweb/gitweb.perl | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 9cf7e71..0ee3290 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2831,8 +2831,6 @@ sub git_get_projects_list {
my $filter = shift || '';
my @list;
- $filter =~ s/\.git$//;
-
if (-d $projects_list) {
# search in directory
my $dir = $projects_list;
@@ -6007,7 +6005,7 @@ sub git_forks {
die_error(400, "Unknown order parameter");
}
- my @list = git_get_projects_list($project);
+ my @list = git_get_projects_list((my $filter = $project) =~ s/\.git$//);
if (!@list) {
die_error(404, "No forks found");
}
@@ -6066,7 +6064,7 @@ sub git_summary {
if ($check_forks) {
# find forks of a project
- @forklist = git_get_projects_list($project);
+ @forklist = git_get_projects_list((my $filter = $project) =~ s/\.git$//);
# filter out forks of forks
@forklist = filter_forks_from_projects_list(\@forklist)
if (@forklist);
--
1.7.8.3
^ permalink raw reply related
* [PATCH v6 2/6] gitweb: prepare git_get_projects_list for use outside 'forks'.
From: Bernhard R. Link @ 2012-01-30 20:06 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git
In-Reply-To: <20120130200355.GA2584@server.brlink.eu>
Use of the filter option of git_get_projects_list is currently limited
to forks. It currently assumes the project belonging to the filter
directory was already validated to be visible in the project list.
To make it more generic add an optional argument to denote visibility
verification is still needed.
If there is a projects list file (GITWEB_LIST) only projects from
this list are returned anyway, so no more checks needed.
If there is no projects list file and the caller requests strict
checking (GITWEB_STRICT_EXPORT), do not jump directly to the
given directory but instead do a normal search and filter the
results instead.
The only effect of GITWEB_STRICT_EXPORT without GITWEB_LIST is to make
sure no project can be viewed without also be found starting from
project root. git_get_projects_list without this patch does not enforce
this but all callers only call it with a filter already checked this
way. With this parameter a caller can request this check if the filter
cannot be checked this way.
Signed-off-by: Bernhard R. Link <brlink@debian.org>
---
Changes to v5:
- split first patch in two as suggested by Jakub Narebski
- replace "and not" with the more common "&& !"
---
gitweb/gitweb.perl | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 0ee3290..9a296e2 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2829,6 +2829,7 @@ sub git_get_project_url_list {
sub git_get_projects_list {
my $filter = shift || '';
+ my $paranoid = shift;
my @list;
if (-d $projects_list) {
@@ -2839,7 +2840,7 @@ sub git_get_projects_list {
my $pfxlen = length("$dir");
my $pfxdepth = ($dir =~ tr!/!!);
# when filtering, search only given subdirectory
- if ($filter) {
+ if ($filter && !$paranoid) {
$dir .= "/$filter";
$dir =~ s!/+$!!;
}
@@ -2864,6 +2865,10 @@ sub git_get_projects_list {
}
my $path = substr($File::Find::name, $pfxlen + 1);
+ # paranoidly only filter here
+ if ($paranoid && $filter && $path !~ m!^\Q$filter\E/!) {
+ next;
+ }
# we check related file in $projectroot
if (check_export_ok("$projectroot/$path")) {
push @list, { path => $path };
--
1.7.8.3
^ permalink raw reply related
* [PATCH v6 3/6] gitweb: add project_filter to limit project list to a subdirectory
From: Bernhard R. Link @ 2012-01-30 20:07 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git
In-Reply-To: <20120130200355.GA2584@server.brlink.eu>
This commit changes the project listing views (project_list,
project_index and opml) to limit the output to only projects in a
subdirectory if the new optional parameter ?pf=directory name is
used.
The implementation of the filter reuses the implementation used for
the 'forks' action (i.e. listing all projects within that directory
from the projects list file (GITWEB_LIST) or only projects in the
given subdirectory of the project root directory without a projects
list file).
Reusing $project instead of adding a new parameter would have been
nicer from a UI point-of-view (including PATH_INFO support) but
would complicate the $project validating code that is currently
being used to ensure nothing is exported that should not be viewable.
Signed-off-by: Bernhard R. Link <brlink@debian.org>
---
changed since v5.5:
- change page titles to show what directory it is limited to
---
gitweb/gitweb.perl | 31 +++++++++++++++++++++++++------
1 files changed, 25 insertions(+), 6 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 9a296e2..b895f4c 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -760,6 +760,7 @@ our @cgi_param_mapping = (
search_use_regexp => "sr",
ctag => "by_tag",
diff_style => "ds",
+ project_filter => "pf",
# this must be last entry (for manipulation from JavaScript)
javascript => "js"
);
@@ -976,7 +977,7 @@ sub evaluate_path_info {
our ($action, $project, $file_name, $file_parent, $hash, $hash_parent, $hash_base,
$hash_parent_base, @extra_options, $page, $searchtype, $search_use_regexp,
- $searchtext, $search_regexp);
+ $searchtext, $search_regexp, $project_filter);
sub evaluate_and_validate_params {
our $action = $input_params{'action'};
if (defined $action) {
@@ -994,6 +995,13 @@ sub evaluate_and_validate_params {
}
}
+ our $project_filter = $input_params{'project_filter'};
+ if (defined $project_filter) {
+ if (!validate_pathname($project_filter)) {
+ die_error(404, "Invalid project_filter parameter");
+ }
+ }
+
our $file_name = $input_params{'file_name'};
if (defined $file_name) {
if (!validate_pathname($file_name)) {
@@ -3734,7 +3742,12 @@ sub run_highlighter {
sub get_page_title {
my $title = to_utf8($site_name);
- return $title unless (defined $project);
+ unless (defined $project) {
+ if (defined $project_filter) {
+ $title .= " - " . to_utf8($project_filter);
+ }
+ return $title;
+ }
$title .= " - " . to_utf8($project);
return $title unless (defined $action);
@@ -5984,7 +5997,7 @@ sub git_project_list {
die_error(400, "Unknown order parameter");
}
- my @list = git_get_projects_list();
+ my @list = git_get_projects_list($project_filter, $strict_export);
if (!@list) {
die_error(404, "No projects found");
}
@@ -6023,7 +6036,7 @@ sub git_forks {
}
sub git_project_index {
- my @projects = git_get_projects_list();
+ my @projects = git_get_projects_list($project_filter, $strict_export);
if (!@projects) {
die_error(404, "No projects found");
}
@@ -7860,7 +7873,7 @@ sub git_atom {
}
sub git_opml {
- my @list = git_get_projects_list();
+ my @list = git_get_projects_list($project_filter, $strict_export);
if (!@list) {
die_error(404, "No projects found");
}
@@ -7871,11 +7884,17 @@ sub git_opml {
-content_disposition => 'inline; filename="opml.xml"');
my $title = esc_html($site_name);
+ my $filter = " within subdirectory ";
+ if (defined $project_filter) {
+ $filter .= esc_html($project_filter);
+ } else {
+ $filter = "";
+ }
print <<XML;
<?xml version="1.0" encoding="utf-8"?>
<opml version="1.0">
<head>
- <title>$title OPML Export</title>
+ <title>$title OPML Export$filter</title>
</head>
<body>
<outline text="git RSS feeds">
--
1.7.8.3
^ permalink raw reply related
* [PATCH v6 4/6] gitweb: limit links to alternate forms of project_list to active project_filter
From: Bernhard R. Link @ 2012-01-30 20:09 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git
In-Reply-To: <20120130200355.GA2584@server.brlink.eu>
If project_list action is given a project_filter argument, pass that to
TXT and OPML formats.
This way [OPML] and [TXT] links provide the same list of projects as
the projects_list page they are linked from.
Signed-off-by: Bernhard R. Link <brlink@debian.org>
---
Changes since v5:
add additional description paragraph from Jakub Narebski
---
gitweb/gitweb.perl | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index b895f4c..9299504 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3981,9 +3981,11 @@ sub git_footer_html {
}
} else {
- print $cgi->a({-href => href(project=>undef, action=>"opml"),
+ print $cgi->a({-href => href(project=>undef, action=>"opml",
+ project_filter => $project_filter),
-class => $feed_class}, "OPML") . " ";
- print $cgi->a({-href => href(project=>undef, action=>"project_index"),
+ print $cgi->a({-href => href(project=>undef, action=>"project_index",
+ project_filter => $project_filter),
-class => $feed_class}, "TXT") . "\n";
}
print "</div>\n"; # class="page_footer"
--
1.7.8.3
^ permalink raw reply related
* [PATCH v6 5/6] gitweb: show active project_filter in project_list page header
From: Bernhard R. Link @ 2012-01-30 20:09 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git
In-Reply-To: <20120130200355.GA2584@server.brlink.eu>
In the page header of a project_list view with a project_filter
given show breadcrumbs in the page headers showing which directory
it is currently limited to and also containing links to the parent
directories.
Signed-off-by: Bernhard R. Link <brlink@debian.org>
---
Changes since v5:
- improve description, better?
- equalize whitespace
---
gitweb/gitweb.perl | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 9299504..27db84e 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3841,6 +3841,18 @@ sub print_header_links {
}
}
+sub print_nav_breadcrumbs_path {
+ my $dirprefix = undef;
+ while (my $part = shift) {
+ $dirprefix .= "/" if defined $dirprefix;
+ $dirprefix .= $part;
+ print $cgi->a({-href => href(project => undef,
+ project_filter => $dirprefix,
+ action => "project_list")},
+ esc_html($part)) . " / ";
+ }
+}
+
sub print_nav_breadcrumbs {
my %opts = @_;
@@ -3859,6 +3871,8 @@ sub print_nav_breadcrumbs {
print " / $opts{-action_extra}";
}
print "\n";
+ } elsif (defined $project_filter) {
+ print_nav_breadcrumbs_path(split '/', $project_filter);
}
}
--
1.7.8.3
^ permalink raw reply related
* [PATCH v6 6/6] gitweb: place links to parent directories in page header
From: Bernhard R. Link @ 2012-01-30 20:10 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git
In-Reply-To: <20120130200355.GA2584@server.brlink.eu>
Change html page headers to not only link the project root and the
currently selected project but also the directories in between using
project_filter. (Allowing to jump to a list of all projects within
that intermediate directory directly and making the project_filter
feature visible to users).
Signed-off-by: Bernhard R. Link <brlink@debian.org>
Acked-by: Jakub Narebski <jnareb@gmail.com>
---
What are the rules for copying Acked-by? This change and it's
description are unchanged since v4 which got a Acked-by. Do
I keep that Acked-by if only the other patches change or do I reset
it?
---
gitweb/gitweb.perl | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 27db84e..c45e0e7 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3858,7 +3858,10 @@ sub print_nav_breadcrumbs {
print $cgi->a({-href => esc_url($home_link)}, $home_link_str) . " / ";
if (defined $project) {
- print $cgi->a({-href => href(action=>"summary")}, esc_html($project));
+ my @dirname = split '/', $project;
+ my $projectbasename = pop @dirname;
+ print_nav_breadcrumbs_path(@dirname);
+ print $cgi->a({-href => href(action=>"summary")}, esc_html($projectbasename));
if (defined $action) {
my $action_print = $action ;
if (defined $opts{-action_extra}) {
--
1.7.8.3
^ permalink raw reply related
* Re: Bug: "git checkout -b" should be allowed in empty repo
From: Junio C Hamano @ 2012-01-30 20:10 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git
In-Reply-To: <7v39axc9gp.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Note that I am not saying that we shouldn't add support for special cases
> with special case codepaths.
>
> Perhaps we would need to sprinkle more special case magic like this (this
> is for the special case that arises from the same cause)?
> ...
And the special case for "checkout -b" may look like this.
The early part of switch_branches() that computes old is probably be
better moved to the caller cmd_checkout() and used in the new code that
detects the "unborn" case, and passed as to switch_branches() as the third
parameter. Such improvements, adding tests and pleasant commit log
message is left as an exercise for the interested and motivated, as usual
;-)
builtin/checkout.c | 24 ++++++++++++++++++++++++
1 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/builtin/checkout.c b/builtin/checkout.c
index f1984d9..195c40b 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -922,6 +922,19 @@ static int parse_branchname_arg(int argc, const char **argv,
return argcount;
}
+static int switch_unborn_to_new_branch(struct checkout_opts *opts, const char *old_ref)
+{
+ int status;
+ struct strbuf branch_ref = STRBUF_INIT;
+
+ strbuf_addf(&branch_ref, "refs/heads/%s", opts->new_branch);
+ warning(_("Leaving the unborn branch '%s' behind..."),
+ skip_prefix(old_ref, "refs/heads/"));
+ status = create_symref("HEAD", branch_ref.buf, "checkout -b");
+ strbuf_reset(&branch_ref);
+ return status;
+}
+
int cmd_checkout(int argc, const char **argv, const char *prefix)
{
struct checkout_opts opts;
@@ -1093,5 +1106,16 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
if (opts.writeout_stage)
die(_("--ours/--theirs is incompatible with switching branches."));
+ if (!new.commit) {
+ unsigned char rev[20];
+ int flag, status;
+ char *old_ref = resolve_refdup("HEAD", rev, 0, &flag);
+
+ if ((flag & REF_ISSYMREF) && is_null_sha1(rev)) {
+ status = switch_unborn_to_new_branch(&opts, old_ref);
+ free(old_ref);
+ return status;
+ }
+ }
return switch_branches(&opts, &new);
}
^ permalink raw reply related
* [PATCH] merge: add instructions to the commit message when editing
From: Thomas Rast @ 2012-01-30 20:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd3a1caxb.fsf@alter.siamese.dyndns.org>
Before f824628 (merge: use editor by default in interactive sessions,
2012-01-10), git-merge only started an editor if the user explicitly
asked for it with --edit. Thus it seemed unlikely that the user would
need extra guidance.
After f824628 the _normal_ thing is to start an editor. Give at least
an indication of why we are doing it.
The sentence about justification is one of the few things about
standard git that are not agnostic to the workflow that the user
chose. However, f824628 was proposed by Linus specifically to
discourage users from merging unrelated upstream progress into topic
branches. So we may as well take another step in the same direction.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
builtin/merge.c | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/builtin/merge.c b/builtin/merge.c
index bfb7547..ed628b8 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -885,11 +885,22 @@ static void abort_commit(const char *err_msg)
exit(1);
}
+static const char merge_editor_comment[] =
+N_("Please enter the commit message for your merge commit. You should\n"
+"justify it especially if it merges an updated upstream into a topic\n"
+"branch.\n"
+"\n"
+"Lines starting with '#' will be ignored, and an empty message aborts\n"
+"the commit.\n");
+
static void prepare_to_commit(void)
{
struct strbuf msg = STRBUF_INIT;
+ const char *comment = _(merge_editor_comment);
strbuf_addbuf(&msg, &merge_msg);
strbuf_addch(&msg, '\n');
+ if (0 < option_edit)
+ strbuf_add_lines(&msg, "# ", comment, strlen(comment));
write_merge_msg(&msg);
run_hook(get_index_file(), "prepare-commit-msg",
git_path("MERGE_MSG"), "merge", NULL, NULL);
--
1.7.9.350.ga960f
^ permalink raw reply related
* Re: [PATCH v5 2/5] gitweb: add project_filter to limit project list to a subdirectory
From: Junio C Hamano @ 2012-01-30 20:34 UTC (permalink / raw)
To: Bernhard R. Link; +Cc: Jakub Narebski, git
In-Reply-To: <20120130200355.GA2584@server.brlink.eu>
"Bernhard R. Link" <brl@mail.brlink.eu> writes:
> I'll resend the series as replies to this mail.
Thanks; I'll queue them in 'pu' for now (if Jakub wants to Ack the pieces,
I'll amend them).
Regarding the first patch in the series, while it may be a valid perl to
introduce a new variable, assign to it and then munge its contents with
s///, all inside a parameter list of a function call, it is doing a bit
too much and makes it hard to see if the variable may or may not later be
used in the same scope (in this case, it is not).
I am tempted to squash the following in.
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index b764d51..f215eaa 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -6003,7 +6003,8 @@ sub git_forks {
die_error(400, "Unknown order parameter");
}
- my @list = git_get_projects_list((my $filter = $project) =~ s/\.git$//);
+ my ($filter = $project) =~ s/\.git$//;
+ my @list = git_get_projects_list($filter);
if (!@list) {
die_error(404, "No forks found");
}
@@ -6062,7 +6063,8 @@ sub git_summary {
if ($check_forks) {
# find forks of a project
- @forklist = git_get_projects_list((my $filter = $project) =~ s/\.git$//);
+ my ($filter = $project) =~ s/\.git$//;
+ @forklist = git_get_projects_list($filter);
# filter out forks of forks
@forklist = filter_forks_from_projects_list(\@forklist)
if (@forklist);
--
1.7.9.154.g413bff
^ permalink raw reply related
* Re: [PATCH] git-svn: un-break "git svn rebase" when log.abbrevCommit=true
From: Dan Johnson @ 2012-01-30 20:41 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: git, Eric Wong
In-Reply-To: <1327803073-7000-1-git-send-email-avarab@gmail.com>
On Sat, Jan 28, 2012 at 9:11 PM, Ævar Arnfjörð Bjarmason
<avarab@gmail.com> wrote:
> Change git-svn to parse --no-abbrev-commit --no-decorate to git-log
Did you mean _pass_ --no-abbrev-commit here?
--
-Dan
^ permalink raw reply
* Re: [PATCH v5 2/5] gitweb: add project_filter to limit project list to a subdirectory
From: Jakub Narebski @ 2012-01-30 20:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Bernhard R. Link, git
In-Reply-To: <7v39axaq0v.fsf@alter.siamese.dyndns.org>
On Mon, 30 Jan 2012, Junio C Hamano wrote:
> "Bernhard R. Link" <brl@mail.brlink.eu> writes:
>
> > I'll resend the series as replies to this mail.
>
> Thanks; I'll queue them in 'pu' for now (if Jakub wants to Ack the pieces,
> I'll amend them).
You can add Ack from me for the whole series.
> Regarding the first patch in the series, while it may be a valid perl to
> introduce a new variable, assign to it and then munge its contents with
> s///, all inside a parameter list of a function call, it is doing a bit
> too much and makes it hard to see if the variable may or may not later be
> used in the same scope (in this case, it is not).
>
> I am tempted to squash the following in.
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index b764d51..f215eaa 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -6003,7 +6003,8 @@ sub git_forks {
> die_error(400, "Unknown order parameter");
> }
>
> - my @list = git_get_projects_list((my $filter = $project) =~ s/\.git$//);
> + my ($filter = $project) =~ s/\.git$//;
This doesn't work: it is syntax error:
Can't declare scalar assignment in "my"
It has to be either
+ (my $filter = $project) =~ s/\.git$//;
or
+ my $filter = $project;
+ $filter =~ s/\.git$//;
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH v5 2/5] gitweb: add project_filter to limit project list to a subdirectory
From: Bernhard R. Link @ 2012-01-30 20:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git
In-Reply-To: <7v39axaq0v.fsf@alter.siamese.dyndns.org>
* Junio C Hamano <gitster@pobox.com> [120130 21:34]:
> "Bernhard R. Link" <brl@mail.brlink.eu> writes:
> Regarding the first patch in the series, while it may be a valid perl to
> introduce a new variable, assign to it and then munge its contents with
> s///, all inside a parameter list of a function call, it is doing a bit
> too much and makes it hard to see if the variable may or may not later be
> used in the same scope (in this case, it is not).
I'm fine either way.
I had interpreted <201201301442.06707.jnareb@gmail.com> to be meant this
way, but rereading it I am not sure it was meant this way at all.
I thought this was to express that those variables are not used outside
this scope.
Bernhard R. Link
^ permalink raw reply
* Re: git-gui Ctrl-U (unstage) broken
From: Phil Hord @ 2012-01-30 20:50 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: Pat Thoyts, Victor Engmark, git
In-Reply-To: <20120130192223.GA21444@ecki>
On Mon, Jan 30, 2012 at 2:22 PM, Clemens Buchacher <drizzd@aon.at> wrote:
> I could reproduce this issue on my Fedora 14 box at dayjob with the
> git-gui package that corresponds to git version 1.7.4.4 (git-gui version
> 0.13.0.8.g8f855 according to git.git).
>
> But I cannot reproduce with the current git version or even with git
> 1.7.1 and git-gui 0.12.0.64.g89d6 on my Arch Linux box, where I have
> Tcl/Tk version 8.5.11.
>
> I have to check which Tcl/Tk version the F14 box uses. But the bug does
> not seem to depend on the git gui version. Have you tried upgrading
> Tcl/Tk?
I haven't tried anything to fix this, but I'll add some data points.
* Ctrl-T / Ctrl-U Ctrl-J have never worked reliably for me on Ubuntu/Gnome.
* Ctrl-A does not work for "Remote > Add..." since it performs "Edit
> Select All" instead
All the other combos I tried work ok.
Maybe the last one is a clue, though I can't think what Ctrl-T might
be assigned to, and it's not listed in the menus as being assigned to
anything else. But maybe the works-ness of it is related to the
window focus.
Phil
^ permalink raw reply
* Re: [PATCH] merge: add instructions to the commit message when editing
From: Junio C Hamano @ 2012-01-30 21:03 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <0c9a880c7dca27520f957446c6b0e72e93609b03.1327954927.git.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> The sentence about justification is one of the few things about
> standard git that are not agnostic to the workflow that the user
> chose.
We try to be agnostic at plumbing level, but I do not think we ever made
such a promise at the Porcelain level like "git merge". On the contrary,
we try to encourage good workflows by coding behaviours to support BCP to
Porcelain commands. Am I misreading what you were trying to say here?
> diff --git a/builtin/merge.c b/builtin/merge.c
> index bfb7547..ed628b8 100644
> --- a/builtin/merge.c
> +++ b/builtin/merge.c
> @@ -885,11 +885,22 @@ static void abort_commit(const char *err_msg)
> exit(1);
> }
>
> +static const char merge_editor_comment[] =
> +N_("Please enter the commit message for your merge commit. You should\n"
> +"justify it especially if it merges an updated upstream into a topic\n"
> +"branch.\n"
> +"\n"
> +"Lines starting with '#' will be ignored, and an empty message aborts\n"
> +"the commit.\n");
I am tempted to rewrite this a bit, perhaps something like ...
Please enter the commit message for your merge commit. Explain
why the merge is necessary, especially if it merges an updated
upstream into a topic branch.
... because people who need to be told to "justify it" would probably be
helped by a more explicit "explain _why_ it is needed".
^ permalink raw reply
* Re: [PATCH v5 2/5] gitweb: add project_filter to limit project list to a subdirectory
From: Junio C Hamano @ 2012-01-30 21:05 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, Bernhard R. Link, git
In-Reply-To: <201201302148.03909.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
>> - my @list = git_get_projects_list((my $filter = $project) =~ s/\.git$//);
>> + my ($filter = $project) =~ s/\.git$//;
>
> This doesn't work: it is syntax error:
>
> Can't declare scalar assignment in "my"
>
> It has to be either
>
> + (my $filter = $project) =~ s/\.git$//;
Sorry, that is what I meant.
^ permalink raw reply
* Re: [PATCH v5 2/5] gitweb: add project_filter to limit project list to a subdirectory
From: Junio C Hamano @ 2012-01-30 21:08 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, Bernhard R. Link, git
In-Reply-To: <201201302148.03909.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> On Mon, 30 Jan 2012, Junio C Hamano wrote:
>> "Bernhard R. Link" <brl@mail.brlink.eu> writes:
>>
>> > I'll resend the series as replies to this mail.
>>
>> Thanks; I'll queue them in 'pu' for now (if Jakub wants to Ack the pieces,
>> I'll amend them).
>
> You can add Ack from me for the whole series.
Ok, amended and queued (but not pushed out yet).
^ permalink raw reply
* Re: [RFC/PATCH] add update to branch support for "floating submodules"
From: Phil Hord @ 2012-01-30 21:15 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Junio C Hamano, Leif Gruenwoldt, git
In-Reply-To: <4EE7BEF5.6050205@web.de>
I lost my grip on this thread over the holidays...
On Tue, Dec 13, 2011 at 4:09 PM, Jens Lehmann <Jens.Lehmann@web.de> wrote:
> Am 13.12.2011 15:17, schrieb Phil Hord:
>> On Mon, Dec 12, 2011 at 2:36 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> [...]
>>> Distro package dependency tracking is a poor analogy for many reasons, but
>>> I'll only touch a few.
>> [...]
>>> Naively, one might think that two branches, branch-1.0 and branch-2.0, can
>>> be defined in the repository of L, tell somebody (like "superproject that
>>> covers all the packages in the distro") that A wants branch-1.0 and B
>>> wants branch-2.0 of L respectively, to emulate this, but if one thinks
>>> further, one would realize that it is insufficient. For one thing, it is
>>> unclear what should happen when both A and B are asked to be checked out,
>>> but more importantly, in dependency requirements on real distro packaging,
>>> the application C could say "I want v1.0 API but v1.4 is broken and not
>>> compatible with me", which won't fit on the two-branches model. A
>>> workaround to add more branches to L could be devised but any workaround
>>> cannot be a good solution that allows a random application C among 47
>>> others to dictate how the branch structure of L project should look like.
>>>
>>> Fortunately, the dependency management is a solved problem by distro
>>> package management and build systems, and they do so without using
>>> anything from submodules. There is no point reinventing these logic in git
>>> submodules and emulating poorly.
>>>
>>> The only remotely plausible analogy around distro packaging would be a
>>> superproject full of all the packages in a distro as its submodules, and
>>> records exact versions of each and every package that goes on a release
>>> CD (or DVD). In that case, you do want to have a central registry that
>>> records what exact version of each package is used to cut the CD and the
>>> mother of all modules superproject could be one way to implement it. But
>>> that is not an example of floating, but is a direct opposite.
>>>
>>> This exchange convinced me further that anybody who wishes to use
>>> "floating" is better off either by doing one or both of the following:
>>>
>>> - using "exact" but not updating religiously, as the interdepency
>>> requirement in their project is not strict; or
>>>
>>> - not using submodules at all, but merely keeping these unrelated A, B, C
>>> and L as standalone repositories next to each other in the directory
>>> structure.
>>
>> My interdependency requirements are not so cut-and-dry. We use
>> submodules to isolate controlled regions of code. We may need to
>> share our project with a contractor who is allowed to see code
>> pertaining to "vendorA" but not that for "vendorB" or "VendorN". But
>> our in-house developers want to have all the vendor code in one place
>> for convenient integration. Submodules do this nicely for us. We can
>> give the contractor just the main modules and the VendorA modules and
>> he'll be fine. In-house devs get all the submodules (using the
>> vendor-ALL superproject).
>>
>> But this necessarily means there is too much coupling for comfort
>> between our submodules. For example, when an API changes in the main
>> submodule, each of the vendor submodules is affected because they each
>> implement that API in a custom method. Some of those vendor modules
>> belong to different people. Submodule synchronization becomes a real
>> chore.
>
> Hmm, maybe having vendor-specific branches in the superproject would
> help here. But that is hard to tell without knowing more details about
> your setup. But I suspect your vendor-ALL superproject is exactly the
> right spot to deal with these kind of problems (and if that isn't easy
> that might be a result of the difficulty of the problem you are trying
> to solve here, keeping different vendors in sync with your API ;-).
>
>> Floating would help, I think. Instead I do this:
>>
>> git pull origin topic_foo && git submodule foreach 'git pull origin topic_foo'
>>
>> git submodule foreach 'git push origin topic_foo' && git push origin topic_foo
>
> This sounds to me like you would need the "--recurse-submodules" option
> implemented for "git pull" and "git push", no?
Only if I have nested submodules, but yes, we do use --recurs* in our scripts.
> And I miss to see how
> floating would help when the tips of some submodules are not ready to
> work with other submodules tips ...
By project policy, for any branch, all submodules' tips of the
same-named branch should be interoperable. The CI server looks after
this, as much as he can.
I think of branch names as sticky notes (extra-lightweight tags,
sometimes). We have linear history in many of our vendor submodules,
but multiple "branches" indicate where each superproject branch has
presumably finished integration.
>> But not all my developers are git-gurus yet, and they sometimes mess
>> up their ad hoc scripts or miss important changes they forgot to push
>> in one submodule or another.
>
> Sure, even though current git should help you some by showing changes
> in the submodules.
Real newbies may not even remember to use 'git status' strategically.
>> Or worse, their pull or push fails and
>> they can't see the problem for all the noise. So they email it to me.
>
> We circumvent that by not pulling, but fetching and merging in the
> submodule first and after that in the superproject. You have much more
> control about what is going wrong where (and can have more
> git-experienced people help with - or even do - the merges).
I do that, too, and I wish I didn't have to. I wish I could safely
and sanely recover from a conflicted "git pull --recurse-submodules"
pull from the superproject. That is, I wish doing so were as
straightforward as recovering from the same condition would be if all
my code were in one repository instead of in submodules.
Which is the gist -- I wish submodules did not make git more
complicated than it already is.
Phil
^ permalink raw reply
* Re: [PATCH] git-svn: un-break "git svn rebase" when log.abbrevCommit=true
From: Ævar Arnfjörð Bjarmason @ 2012-01-30 21:18 UTC (permalink / raw)
To: Dan Johnson; +Cc: git, Eric Wong
In-Reply-To: <CAPBPrntdWAM056C_iZDD1XZy6KZ=5rKvH98Owgc-J8ZbBwrErg@mail.gmail.com>
On Mon, Jan 30, 2012 at 21:41, Dan Johnson <computerdruid@gmail.com> wrote:
> On Sat, Jan 28, 2012 at 9:11 PM, Ævar Arnfjörð Bjarmason
> <avarab@gmail.com> wrote:
>> Change git-svn to parse --no-abbrev-commit --no-decorate to git-log
> Did you mean _pass_ --no-abbrev-commit here?
Yup.
I'l submit another patch fixing this and using rev-list.
^ permalink raw reply
* Re: i18n: Avoid sentence puzzles
From: Ævar Arnfjörð Bjarmason @ 2012-01-30 21:12 UTC (permalink / raw)
To: Frederik Schwarzer; +Cc: git
In-Reply-To: <201201301231.21090.schwarzerf@gmail.com>
On Mon, Jan 30, 2012 at 12:31, Frederik Schwarzer <schwarzerf@gmail.com> wrote:
> in order to enable translators to prepare proper translations,
> sentence puzzles have to be avoided. While it makes perfect sense for
> English, some languages may have to separate those words to sound or
> even be correct.
>
> The attached patch demonstrates a change to achive that. I did not
> test it because its purpose is only to raise awareness and start a
> discussion about this topic. After all the question is, how important
> translations are for a tool like Git. I have started a German
> translation but many things are really hard to translate.
I added the i18n support you're having problems with, and I completely
agree that this is the sort of thing we need to do.
Unfortunately when I added the i18n support I didn't have time to get
rid of all these sentence puzzles (or, to put it another way "lego"
sentences). You should never force translators to translate partial
sentences, you should always provide them with full sentences that
they can translate completely, even if that means that there's some
duplication for some languages.
Problem reports like this one are exactly what we need at this point
for i18n, we need people spotting these issues, and then we can fix
them.
^ permalink raw reply
* Re: [PATCH v2 3/4] completion: cleanup __gitcomp*
From: Junio C Hamano @ 2012-01-30 21:25 UTC (permalink / raw)
To: Felipe Contreras
Cc: Jonathan Nieder, git, Felipe Contreras, Ted Pavlic,
SZEDER Gábor, Shawn O. Pearce
In-Reply-To: <7vpqe1au7f.fsf@alter.siamese.dyndns.org>
I managed to pick up 1 & 2:
1. be nicer with zsh (aka avoid default value assignment on : true
command);
2. simplify __git_remotes (aka use ls -1 instead of rolling a loop to do
that ourselves).
But I do not see your patch for 3 & 4 either on gmane archive nor in my
mailbox (via vger, not direct delivery from you to me). The threads for
these two patches both begin with Jonathan's review for me.
Care to resend 3 & 4?
Thanks.
^ permalink raw reply
* Re: [PATCH] merge: add instructions to the commit message when editing
From: Thomas Rast @ 2012-01-30 21:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, git
In-Reply-To: <7vy5soaons.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Thomas Rast <trast@student.ethz.ch> writes:
>
>> The sentence about justification is one of the few things about
>> standard git that are not agnostic to the workflow that the user
>> chose.
>
> We try to be agnostic at plumbing level, but I do not think we ever made
> such a promise at the Porcelain level like "git merge". On the contrary,
> we try to encourage good workflows by coding behaviours to support BCP to
> Porcelain commands. Am I misreading what you were trying to say here?
Oh, I was just trying to preempt a possible argument why this is wrong.
Maybe I was a bit over-eager in doing so ;-)
>> +static const char merge_editor_comment[] =
>> +N_("Please enter the commit message for your merge commit. You should\n"
>> +"justify it especially if it merges an updated upstream into a topic\n"
>> +"branch.\n"
>> +"\n"
>> +"Lines starting with '#' will be ignored, and an empty message aborts\n"
>> +"the commit.\n");
>
> I am tempted to rewrite this a bit, perhaps something like ...
>
> Please enter the commit message for your merge commit. Explain
> why the merge is necessary, especially if it merges an updated
> upstream into a topic branch.
>
> ... because people who need to be told to "justify it" would probably be
> helped by a more explicit "explain _why_ it is needed".
Why not. The "explain..." might be construed as a bit too coercive, but
I cannot come up with a way to defuse it (well, except again tacking on
"you should") and yours is certainly much clearer.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: Bug: "git checkout -b" should be allowed in empty repo
From: Jeff King @ 2012-01-30 21:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael Haggerty, git
In-Reply-To: <7v39axc9gp.fsf@alter.siamese.dyndns.org>
On Mon, Jan 30, 2012 at 10:48:54AM -0800, Junio C Hamano wrote:
> Note that I am not saying that we shouldn't add support for special cases
> with special case codepaths.
>
> Perhaps we would need to sprinkle more special case magic like this (this
> is for the special case that arises from the same cause)?
I like your patch better than trying to pass around "0{40}", but:
> diff --git a/builtin/branch.c b/builtin/branch.c
> index 7095718..0997e75 100644
> --- a/builtin/branch.c
> +++ b/builtin/branch.c
> @@ -640,6 +640,13 @@ static int edit_branch_description(const char *branch_name)
> struct strbuf buf = STRBUF_INIT;
> struct strbuf name = STRBUF_INIT;
>
> + strbuf_addf(&name, "refs/heads/%s", branch_name);
> + if (!ref_exists(name.buf)) {
> + strbuf_reset(&name);
> + return error("No such branch '%s'.", branch_name);
> + }
> + strbuf_reset(&name);
> +
I wonder if this conditional should have:
unsigned char sha1[20];
const char *head_points_at = resolve_ref_unsafe("HEAD", sha1, 1, NULL);
if (!head_points_at || strcmp(head_points_at, name.buf))
return error("No such branch '%s'.", branch_name);
to special-case unborn branches that we are actually pointing to.
IOW, the problem with the current code is that it allows typos and other
arbitrary bogus names to be silently described, even though doing so is
probably an error. But since this branch is already in use (even though
its ref does not technically exist yet), it's probably not an error.
As an aside, the strbuf_reset inside the conditional should be
strbuf_release, no? Otherwise we are leaking. And probably the one
outside, too. Even though we release the memory later, there are error
code-paths that do not. (And yes, I know this was a quick sketch and not
a real patch, but I wanted to point it out in case it turns into a real
one).
-Peff
^ permalink raw reply
* Re: Bug: "git checkout -b" should be allowed in empty repo
From: Jeff King @ 2012-01-30 21:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael Haggerty, git
In-Reply-To: <7vaa55ar4v.fsf@alter.siamese.dyndns.org>
On Mon, Jan 30, 2012 at 12:10:08PM -0800, Junio C Hamano wrote:
> diff --git a/builtin/checkout.c b/builtin/checkout.c
> index f1984d9..195c40b 100644
> --- a/builtin/checkout.c
> +++ b/builtin/checkout.c
> @@ -922,6 +922,19 @@ static int parse_branchname_arg(int argc, const char **argv,
> return argcount;
> }
>
> +static int switch_unborn_to_new_branch(struct checkout_opts *opts, const char *old_ref)
> +{
> + int status;
> + struct strbuf branch_ref = STRBUF_INIT;
> +
> + strbuf_addf(&branch_ref, "refs/heads/%s", opts->new_branch);
> + warning(_("Leaving the unborn branch '%s' behind..."),
> + skip_prefix(old_ref, "refs/heads/"));
> + status = create_symref("HEAD", branch_ref.buf, "checkout -b");
> + strbuf_reset(&branch_ref);
> + return status;
> +}
Is it really worth warning? After all, by definition you are not leaving
any commits or useful work behind.
Also, this has the same strbuf reset/release leak as the last patch. :)
-Peff
^ 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