* Re: Different svn-id URLs in history
From: Michael J Gruber @ 2008-10-08 8:32 UTC (permalink / raw)
To: Knut Eldhuset; +Cc: git
In-Reply-To: <48EC546F.7060106@3d-radar.com>
Knut Eldhuset venit, vidit, dixit 08.10.2008 08:34:
> Michael J Gruber wrote:
>> Knut Eldhuset venit, vidit, dixit 07.10.2008 12:58:
>>> Hi,
>>>
>>> After cloning my svn repository, I notice that the svn-id URL is
>>> different when going back in history:
>>>
>>> git-svn-id: https://server/trunk@300
>>>
>>> vs
>>>
>>> git-svn-id: https://server/trunk/some_folder/project/src@250
>>>
>> I take this is as an invitation for guesswork (given the amount of
>> details)...
>
> Sorry about that... I'm confused.
>> You probably have commits which don't follow your usual svn repo layout
>> (trunk/some_folder/project/src) but commit to trunk/ directly. The output of
>>
>> svn log -v -r300 https://server/trunk@300
>> svn log -v -r250 https://server/trunk/some_folder/project/src@250
>>
>> should give some clues.
>>
>
> Svn log shows that the same path has been modified in both cases. I see
Does "same path" mean:
- same relative to the above paths or
- same absolute path?
> something strange in git, though. Our svn repository has about 6500
> commits, but git shows over 10.000. Further investigation shows that a
> lot of svn commits have two entries in git. Some branches off of trunk
> do not start at r1, but off of a duplicate rNNNN. Could this be due to
> our unhealthy practice of creating branches off of subtrees in svn? By
> this I mean create a branch off of
> https://server/trunk/some_folder/project/src instead of
> https://server/trunk. If so, what can be done to fix this?
>
> As a sidenote, during git svn clone, I noticed that each time a new
> branch or tag was discovered, the "scanning" started back at r1. Is this
> normal? I would think the history before the branch was already
> imported. Of course, this could maybe be due to the bad branching
> practice described above.
svn is typically "abused" in the sense that one svn repo is used for
separate projects (your subtrees). git-svn can deal with non-standard
repo layouts.
I assume you can't share the svn repo publically, can you?
So, in order to help you, we would need to know
- the layout of your svn repo: where are trunk, branches and tags, how
did you create branches and tags in svn, are "projects" entirely separate
- your incarnation of git-svn
Michael
^ permalink raw reply
* Re: [PATCH] gitweb: refactor input parameters parse/validation
From: Giuseppe Bilotta @ 2008-10-08 9:10 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Shawn O. Pearce
In-Reply-To: <200810071639.25324.jnareb@gmail.com>
On Tue, Oct 7, 2008 at 4:39 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> Giuseppe Bilotta wrote:
>> On Tue, Oct 7, 2008 at 12:57 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>>> On Fri, 3 Oct 2008, Giuseppe Bilotta wrote:
>
>>>> + # find which part of PATH_INFO is project
>>>> + my $project = $path_info;
>>>
>>> Hmmm... now $project is local (lexically) here.
>>
>> Yes, itt's only used temporarily here, to see if a proper $project
>> can be defined. It gets redefined outside. It just made sense to name
>> it like this 8-)
>
> Well, if $project is local in evaluate_path_info(), so could be
> $path_info...
But $path_info in evaluate_path_info() has the same purpose and the
same (initial) data as $path_info outside of evaluate_path_info(), the
same is not true for $project.
>>>> + $project =~ s,/+$,,;
>>>> + while ($project && !check_head_link("$projectroot/$project")) {
>>>> + $project =~ s,/*[^/]*$,,;
>>>> + }
>>>> + # validate project
>>>> + $project = validate_project($project);
>>>
>>> I'm not sure if it is worth worrying over, but I think you repeat
>>> check_head_link() check here.
>>>
>>> [After examining code further]. But I think you do double validation;
>>> once you do it here, and once you do it copying to global variables
>>> such as $action or $project, and double checking check_head_link()
>>> won't be easy to avoid; fortunately it is cheap filesystem-level check
>>> (might be slow only when stat is extremely slow, and is not cached).
>>
>> I know. This is actually the reason why I had interleaved path_info
>> definition and global validation in my previous version of the patch.
>> The big issue here is that path_info evaluation _needs_ (partial)
>> validation.
>>
>> A possible alternative could be to only put validated parameters into
>> %input_params. This would completely separate the validation for cgi
>> and path_info (modulo shared subs).
>>
>> Of course, the check_head_link would still be repeated inside
>> evaluate_path_info, but the other params could skip a double
>> validation.
>
> Wouldn't it be simpler and as good solution to just leave validation
> off evaluate_path_info() (well, of course except check_head_link() test),
> and allow it to be validated when assigning global 'params' variables?
> check_head_link() would be repeated for path_info links, but that
> should not affect performance much.
Well, it does have a performance hit in the case of invalid $project
since it spends time working on the rest of the URL before bailing
out, but it's probably the cleanest solution. I'll do it this way.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: Different svn-id URLs in history
From: Knut Eldhuset @ 2008-10-08 9:20 UTC (permalink / raw)
To: git
In-Reply-To: <48EC7022.7030707@drmicha.warpmail.net>
Michael J Gruber wrote:
> Knut Eldhuset venit, vidit, dixit 08.10.2008 08:34:
>> Michael J Gruber wrote:
>>> Knut Eldhuset venit, vidit, dixit 07.10.2008 12:58:
>>>> Hi,
>>>>
>>>> After cloning my svn repository, I notice that the svn-id URL is
>>>> different when going back in history:
>>>>
>>>> git-svn-id: https://server/trunk@300
>>>>
>>>> vs
>>>>
>>>> git-svn-id: https://server/trunk/some_folder/project/src@250
>>>>
>>> I take this is as an invitation for guesswork (given the amount of
>>> details)...
>> Sorry about that... I'm confused.
>>> You probably have commits which don't follow your usual svn repo layout
>>> (trunk/some_folder/project/src) but commit to trunk/ directly. The output of
>>>
>>> svn log -v -r300 https://server/trunk@300
>>> svn log -v -r250 https://server/trunk/some_folder/project/src@250
>>>
>>> should give some clues.
>>>
>> Svn log shows that the same path has been modified in both cases. I see
>
> Does "same path" mean:
> - same relative to the above paths or
> - same absolute path?
Both say "/trunk/some_folder/project/src/some_file".
>
>> something strange in git, though. Our svn repository has about 6500
>> commits, but git shows over 10.000. Further investigation shows that a
>> lot of svn commits have two entries in git. Some branches off of trunk
>> do not start at r1, but off of a duplicate rNNNN. Could this be due to
>> our unhealthy practice of creating branches off of subtrees in svn? By
>> this I mean create a branch off of
>> https://server/trunk/some_folder/project/src instead of
>> https://server/trunk. If so, what can be done to fix this?
>>
>> As a sidenote, during git svn clone, I noticed that each time a new
>> branch or tag was discovered, the "scanning" started back at r1. Is this
>> normal? I would think the history before the branch was already
>> imported. Of course, this could maybe be due to the bad branching
>> practice described above.
>
> svn is typically "abused" in the sense that one svn repo is used for
> separate projects (your subtrees). git-svn can deal with non-standard
> repo layouts.
>
> I assume you can't share the svn repo publically, can you?
Sorry, no.
> So, in order to help you, we would need to know
>
> - the layout of your svn repo: where are trunk, branches and tags, how
> did you create branches and tags in svn, are "projects" entirely separate
https://server/trunk
https://server/branches
https://server/tags
We really only have one "project" source tree at
https://server/trunk/some_folder/project/src
However, once the sources were at
https://server/trunk/some_folder/project/old_source
Therefore we have the following:
$ svn log -v -r4871 https://server/
------------------------------------------------------------------------
r4871 | nn | 2007-09-25 13:36:25 +0200 (Tue, 25 Sep 2007) | 3 lines
Changed paths:
M /trunk/project
D /trunk/project/old_source/some_file
A /trunk/project/src/client/some_file (from
/trunk/project/old_source/some_file:4795)
commit-message
------------------------------------------------------------------------
$ svn log -v -r4869 https://server/
------------------------------------------------------------------------
r4869 | nn | 2007-09-25 13:14:34 +0200 (Tue, 25 Sep 2007) | 3 lines
Changed paths:
M /trunk/project
A /trunk/project/src
A /trunk/project/src/client
commit-message
------------------------------------------------------------------------
$ svn log -v -r4868 https://server/
------------------------------------------------------------------------
r4868 | nn | 2007-09-25 13:14:28 +0200 (Tue, 25 Sep 2007) | 3 lines
Changed paths:
M /trunk/project
commit-message
------------------------------------------------------------------------
$ svn log -v -r4867 https://server/
------------------------------------------------------------------------
r4867 | nn | 2007-09-25 12:04:58 +0200 (Tue, 25 Sep 2007) | 3 lines
Changed paths:
M /trunk/project
A /trunk/project/some_file
commit-message
------------------------------------------------------------------------
r4868 appears twice in git. One commit is on master/trunk and has parent
and child, while the other is on a branch and has no parent.
> - your incarnation of git-svn
>
# git --version
git version 1.6.0.2
Regards,
Knut
^ permalink raw reply
* Re: Different svn-id URLs in history
From: Knut Eldhuset @ 2008-10-08 9:23 UTC (permalink / raw)
To: git
In-Reply-To: <48EC7B52.4000100@3d-radar.com>
Knut Eldhuset wrote:
> Michael J Gruber wrote:
>> Knut Eldhuset venit, vidit, dixit 08.10.2008 08:34:
>>> Michael J Gruber wrote:
>>>> Knut Eldhuset venit, vidit, dixit 07.10.2008 12:58:
>>>>> Hi,
>>>>>
>>>>> After cloning my svn repository, I notice that the svn-id URL is
>>>>> different when going back in history:
>>>>>
>>>>> git-svn-id: https://server/trunk@300
>>>>>
>>>>> vs
>>>>>
>>>>> git-svn-id: https://server/trunk/some_folder/project/src@250
>>>>>
>>>> I take this is as an invitation for guesswork (given the amount of
>>>> details)...
>>> Sorry about that... I'm confused.
>>>> You probably have commits which don't follow your usual svn repo layout
>>>> (trunk/some_folder/project/src) but commit to trunk/ directly. The
>>>> output of
>>>>
>>>> svn log -v -r300 https://server/trunk@300
>>>> svn log -v -r250 https://server/trunk/some_folder/project/src@250
>>>>
>>>> should give some clues.
>>>>
>>> Svn log shows that the same path has been modified in both cases. I see
>>
>> Does "same path" mean:
>> - same relative to the above paths or
>> - same absolute path?
>
> Both say "/trunk/some_folder/project/src/some_file".
>
>>
>>> something strange in git, though. Our svn repository has about 6500
>>> commits, but git shows over 10.000. Further investigation shows that
>>> a lot of svn commits have two entries in git. Some branches off of
>>> trunk do not start at r1, but off of a duplicate rNNNN. Could this be
>>> due to our unhealthy practice of creating branches off of subtrees in
>>> svn? By this I mean create a branch off of
>>> https://server/trunk/some_folder/project/src instead of
>>> https://server/trunk. If so, what can be done to fix this?
>>>
>>> As a sidenote, during git svn clone, I noticed that each time a new
>>> branch or tag was discovered, the "scanning" started back at r1. Is
>>> this normal? I would think the history before the branch was already
>>> imported. Of course, this could maybe be due to the bad branching
>>> practice described above.
>>
>> svn is typically "abused" in the sense that one svn repo is used for
>> separate projects (your subtrees). git-svn can deal with non-standard
>> repo layouts.
>>
>> I assume you can't share the svn repo publically, can you?
>
> Sorry, no.
>
>> So, in order to help you, we would need to know
>>
>> - the layout of your svn repo: where are trunk, branches and tags, how
>> did you create branches and tags in svn, are "projects" entirely separate
>
> https://server/trunk
> https://server/branches
> https://server/tags
>
> We really only have one "project" source tree at
> https://server/trunk/some_folder/project/src
>
> However, once the sources were at
> https://server/trunk/some_folder/project/old_source
>
> Therefore we have the following:
>
> $ svn log -v -r4871 https://server/
> ------------------------------------------------------------------------
> r4871 | nn | 2007-09-25 13:36:25 +0200 (Tue, 25 Sep 2007) | 3 lines
> Changed paths:
> M /trunk/project
> D /trunk/project/old_source/some_file
> A /trunk/project/src/client/some_file (from
> /trunk/project/old_source/some_file:4795)
>
> commit-message
> ------------------------------------------------------------------------
>
> $ svn log -v -r4869 https://server/
> ------------------------------------------------------------------------
> r4869 | nn | 2007-09-25 13:14:34 +0200 (Tue, 25 Sep 2007) | 3 lines
> Changed paths:
> M /trunk/project
> A /trunk/project/src
> A /trunk/project/src/client
>
> commit-message
>
> ------------------------------------------------------------------------
>
> $ svn log -v -r4868 https://server/
> ------------------------------------------------------------------------
> r4868 | nn | 2007-09-25 13:14:28 +0200 (Tue, 25 Sep 2007) | 3 lines
> Changed paths:
> M /trunk/project
>
> commit-message
>
> ------------------------------------------------------------------------
>
> $ svn log -v -r4867 https://server/
> ------------------------------------------------------------------------
> r4867 | nn | 2007-09-25 12:04:58 +0200 (Tue, 25 Sep 2007) | 3 lines
> Changed paths:
> M /trunk/project
> A /trunk/project/some_file
>
> commit-message
> ------------------------------------------------------------------------
>
> r4868 appears twice in git. One commit is on master/trunk and has parent
> and child, while the other is on a branch and has no parent.
>
Sorry, that should be r4869.
>> - your incarnation of git-svn
>>
>
> # git --version
> git version 1.6.0.2
>
>
Regards,
Knut
^ permalink raw reply
* Re: [StGit PATCH 6/6] Refresh and expand the tutorial (not finished)
From: Karl Hasselström @ 2008-10-08 9:24 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20081007071223.GC31332@diana.vm.bytemark.co.uk>
On 2008-10-07 09:12:23 +0200, Karl Hasselström wrote:
> On 2008-10-06 22:25:45 +0100, Catalin Marinas wrote:
>
> > Do you plan to do more work on the tutorial (so that we don't
> > duplicate)?
>
> I was planning to finish it if nobody else stepped up. But it'd be
> great if I didn't have to do it alone. :-)
>
> I guess we can avoid duplicate work if we send out a mail saying
> "I'll now be working on part XXX" before we start writing.
This means that the tutorial patch needs to be pretty much immutable,
so you can merge it right away. I'll address your comments in
follow-up patches.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* [PATCHv2] gitweb: refactor input parameters parse/validation
From: Giuseppe Bilotta @ 2008-10-08 9:26 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Shawn O. Pearce, Giuseppe Bilotta
In-Reply-To: <200810071257.38423.jnareb@gmail.com>
Since input parameters can be obtained both from CGI parameters and
PATH_INFO, we would like most of the code to be agnostic about the way
parameters were retrieved. We thus collect all the parameters into the
new %input_params hash, delaying validation after the collection is
completed.
Although the kludge removal is minimal at the moment, it makes life much
easier for future expansions such as more extensive PATH_INFO use or
other form of input such as command-line support.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
Some cleanups and clarifications suggested by Jakub were merged in this
revised version of the patch, although I'm keeping $path_info global
gitweb/gitweb.perl | 315 +++++++++++++++++++++++++++++-----------------------
1 files changed, 178 insertions(+), 137 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 83f810a..c54d82b 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -29,7 +29,9 @@ our $my_uri = $cgi->url(-absolute => 1);
# if we're called with PATH_INFO, we have to strip that
# from the URL to find our real URL
-if (my $path_info = $ENV{"PATH_INFO"}) {
+# we make $path_info global because it's also used later on
+my $path_info = $ENV{"PATH_INFO"};
+if ($path_info) {
$my_url =~ s,\Q$path_info\E$,,;
$my_uri =~ s,\Q$path_info\E$,,;
}
@@ -390,34 +392,155 @@ $projects_list ||= $projectroot;
# ======================================================================
# input validation and dispatch
-our $action = $cgi->param('a');
+
+# input parameters can be collected from a variety of sources (presently, CGI
+# and PATH_INFO), so we define an %input_params hash that collects them all
+# together during validation: this allows subsequent uses (e.g. href()) to be
+# agnostic of the parameter origin
+
+my %input_params = ();
+
+# input parameters are stored with the long parameter name as key. This will
+# also be used in the href subroutine to convert parameters to their CGI
+# equivalent, and since the href() usage is the most frequent one, we store
+# the name -> CGI key mapping here, instead of the reverse.
+#
+# XXX: Warning: If you touch this, check the search form for updating,
+# too.
+
+my @cgi_param_mapping = (
+ project => "p",
+ action => "a",
+ file_name => "f",
+ file_parent => "fp",
+ hash => "h",
+ hash_parent => "hp",
+ hash_base => "hb",
+ hash_parent_base => "hpb",
+ page => "pg",
+ order => "o",
+ searchtext => "s",
+ searchtype => "st",
+ snapshot_format => "sf",
+ extra_options => "opt",
+ search_use_regexp => "sr",
+);
+my %cgi_param_mapping = @cgi_param_mapping;
+
+# we will also need to know the possible actions, for validation
+my %actions = (
+ "blame" => \&git_blame,
+ "blobdiff" => \&git_blobdiff,
+ "blobdiff_plain" => \&git_blobdiff_plain,
+ "blob" => \&git_blob,
+ "blob_plain" => \&git_blob_plain,
+ "commitdiff" => \&git_commitdiff,
+ "commitdiff_plain" => \&git_commitdiff_plain,
+ "commit" => \&git_commit,
+ "forks" => \&git_forks,
+ "heads" => \&git_heads,
+ "history" => \&git_history,
+ "log" => \&git_log,
+ "rss" => \&git_rss,
+ "atom" => \&git_atom,
+ "search" => \&git_search,
+ "search_help" => \&git_search_help,
+ "shortlog" => \&git_shortlog,
+ "summary" => \&git_summary,
+ "tag" => \&git_tag,
+ "tags" => \&git_tags,
+ "tree" => \&git_tree,
+ "snapshot" => \&git_snapshot,
+ "object" => \&git_object,
+ # those below don't need $project
+ "opml" => \&git_opml,
+ "project_list" => \&git_project_list,
+ "project_index" => \&git_project_index,
+);
+
+# finally, we have the hash of allowed extra_options for the commands that
+# allow them
+my %allowed_options = (
+ "--no-merges" => [ qw(rss atom log shortlog history) ],
+);
+
+# fill %input_params with the CGI parameters. All values except for 'opt'
+# should be single values, but opt can be an array. We should probably
+# build an array of parameters that can be multi-valued, but since for the time
+# being it's only this one, we just single it out
+while (my ($name, $symbol) = each %cgi_param_mapping) {
+ if ($symbol eq 'opt') {
+ $input_params{$name} = [ $cgi->param($symbol) ];
+ } else {
+ $input_params{$name} = $cgi->param($symbol);
+ }
+}
+
+# now read PATH_INFO and update the parameter list for missing parameters
+sub evaluate_path_info {
+ return if defined $input_params{'project'};
+ return if !$path_info;
+ $path_info =~ s,^/+,,;
+ return if !$path_info;
+
+ # find which part of PATH_INFO is project
+ my $project = $path_info;
+ $project =~ s,/+$,,;
+ while ($project && !check_head_link("$projectroot/$project")) {
+ $project =~ s,/*[^/]*$,,;
+ }
+ return unless $project;
+ $input_params{'project'} = $project;
+
+ # do not change any parameters if an action is given using the query string
+ return if $input_params{'action'};
+ $path_info =~ s,^\Q$project\E/*,,;
+
+ my ($refname, $pathname) = split(/:/, $path_info, 2);
+ if (defined $pathname) {
+ # we got "project.git/branch:filename" or "project.git/branch:dir/"
+ # we could use git_get_type(branch:pathname), but it needs $git_dir
+ $pathname =~ s,^/+,,;
+ if (!$pathname || substr($pathname, -1) eq "/") {
+ $input_params{'action'} = "tree";
+ $pathname =~ s,/$,,;
+ } else {
+ $input_params{'action'} = "blob_plain";
+ }
+ $input_params{'hash_base'} ||= $refname;
+ $input_params{'file_name'} ||= $pathname;
+ } elsif (defined $refname) {
+ # we got "project.git/branch"
+ $input_params{'action'} = "shortlog";
+ $input_params{'hash'} ||= $refname;
+ }
+}
+evaluate_path_info();
+
+our $action = $input_params{'action'};
if (defined $action) {
- if ($action =~ m/[^0-9a-zA-Z\.\-_]/) {
+ if (!validate_action($action)) {
die_error(400, "Invalid action parameter");
}
}
# parameters which are pathnames
-our $project = $cgi->param('p');
+our $project = $input_params{'project'};
if (defined $project) {
- if (!validate_pathname($project) ||
- !(-d "$projectroot/$project") ||
- !check_head_link("$projectroot/$project") ||
- ($export_ok && !(-e "$projectroot/$project/$export_ok")) ||
- ($strict_export && !project_in_list($project))) {
+ if (!validate_project($project)) {
undef $project;
die_error(404, "No such project");
}
}
-our $file_name = $cgi->param('f');
+our $file_name = $input_params{'file_name'};
if (defined $file_name) {
if (!validate_pathname($file_name)) {
die_error(400, "Invalid file parameter");
}
}
-our $file_parent = $cgi->param('fp');
+our $file_parent = $input_params{'file_parent'};
if (defined $file_parent) {
if (!validate_pathname($file_parent)) {
die_error(400, "Invalid file parent parameter");
@@ -425,44 +548,41 @@ if (defined $file_parent) {
}
# parameters which are refnames
-our $hash = $cgi->param('h');
+our $hash = $input_params{'hash'};
if (defined $hash) {
if (!validate_refname($hash)) {
die_error(400, "Invalid hash parameter");
}
}
-our $hash_parent = $cgi->param('hp');
+our $hash_parent = $input_params{'hash_parent'};
if (defined $hash_parent) {
if (!validate_refname($hash_parent)) {
die_error(400, "Invalid hash parent parameter");
}
}
-our $hash_base = $cgi->param('hb');
+our $hash_base = $input_params{'hash_base'};
if (defined $hash_base) {
if (!validate_refname($hash_base)) {
die_error(400, "Invalid hash base parameter");
}
}
-my %allowed_options = (
- "--no-merges" => [ qw(rss atom log shortlog history) ],
-);
-
-our @extra_options = $cgi->param('opt');
-if (defined @extra_options) {
- foreach my $opt (@extra_options) {
- if (not exists $allowed_options{$opt}) {
- die_error(400, "Invalid option parameter");
- }
- if (not grep(/^$action$/, @{$allowed_options{$opt}})) {
- die_error(400, "Invalid option parameter for this action");
- }
+our @extra_options = @{$input_params{'extra_options'}};
+# @extra_options is always defined, since it can only be (currently) set from
+# CGI, and $cgi->param() returns the empty array in array context if the param
+# is not set
+foreach my $opt (@extra_options) {
+ if (not exists $allowed_options{$opt}) {
+ die_error(400, "Invalid option parameter");
+ }
+ if (not grep(/^$action$/, @{$allowed_options{$opt}})) {
+ die_error(400, "Invalid option parameter for this action");
}
}
-our $hash_parent_base = $cgi->param('hpb');
+our $hash_parent_base = $input_params{'hash_parent_base'};
if (defined $hash_parent_base) {
if (!validate_refname($hash_parent_base)) {
die_error(400, "Invalid hash parent base parameter");
@@ -470,23 +590,23 @@ if (defined $hash_parent_base) {
}
# other parameters
-our $page = $cgi->param('pg');
+our $page = $input_params{'page'};
if (defined $page) {
if ($page =~ m/[^0-9]/) {
die_error(400, "Invalid page parameter");
}
}
-our $searchtype = $cgi->param('st');
+our $searchtype = $input_params{'searchtype'};
if (defined $searchtype) {
if ($searchtype =~ m/[^a-z]/) {
die_error(400, "Invalid searchtype parameter");
}
}
-our $search_use_regexp = $cgi->param('sr');
+our $search_use_regexp = $input_params{'search_use_regexp'};
-our $searchtext = $cgi->param('s');
+our $searchtext = $input_params{'searchtext'};
our $search_regexp;
if (defined $searchtext) {
if (length($searchtext) < 2) {
@@ -495,86 +615,11 @@ if (defined $searchtext) {
$search_regexp = $search_use_regexp ? $searchtext : quotemeta $searchtext;
}
-# now read PATH_INFO and use it as alternative to parameters
-sub evaluate_path_info {
- return if defined $project;
- my $path_info = $ENV{"PATH_INFO"};
- return if !$path_info;
- $path_info =~ s,^/+,,;
- return if !$path_info;
- # find which part of PATH_INFO is project
- $project = $path_info;
- $project =~ s,/+$,,;
- while ($project && !check_head_link("$projectroot/$project")) {
- $project =~ s,/*[^/]*$,,;
- }
- # validate project
- $project = validate_pathname($project);
- if (!$project ||
- ($export_ok && !-e "$projectroot/$project/$export_ok") ||
- ($strict_export && !project_in_list($project))) {
- undef $project;
- return;
- }
- # do not change any parameters if an action is given using the query string
- return if $action;
- $path_info =~ s,^\Q$project\E/*,,;
- my ($refname, $pathname) = split(/:/, $path_info, 2);
- if (defined $pathname) {
- # we got "project.git/branch:filename" or "project.git/branch:dir/"
- # we could use git_get_type(branch:pathname), but it needs $git_dir
- $pathname =~ s,^/+,,;
- if (!$pathname || substr($pathname, -1) eq "/") {
- $action ||= "tree";
- $pathname =~ s,/$,,;
- } else {
- $action ||= "blob_plain";
- }
- $hash_base ||= validate_refname($refname);
- $file_name ||= validate_pathname($pathname);
- } elsif (defined $refname) {
- # we got "project.git/branch"
- $action ||= "shortlog";
- $hash ||= validate_refname($refname);
- }
-}
-evaluate_path_info();
-
# path to the current git repository
our $git_dir;
$git_dir = "$projectroot/$project" if $project;
# dispatch
-my %actions = (
- "blame" => \&git_blame,
- "blobdiff" => \&git_blobdiff,
- "blobdiff_plain" => \&git_blobdiff_plain,
- "blob" => \&git_blob,
- "blob_plain" => \&git_blob_plain,
- "commitdiff" => \&git_commitdiff,
- "commitdiff_plain" => \&git_commitdiff_plain,
- "commit" => \&git_commit,
- "forks" => \&git_forks,
- "heads" => \&git_heads,
- "history" => \&git_history,
- "log" => \&git_log,
- "rss" => \&git_rss,
- "atom" => \&git_atom,
- "search" => \&git_search,
- "search_help" => \&git_search_help,
- "shortlog" => \&git_shortlog,
- "summary" => \&git_summary,
- "tag" => \&git_tag,
- "tags" => \&git_tags,
- "tree" => \&git_tree,
- "snapshot" => \&git_snapshot,
- "object" => \&git_object,
- # those below don't need $project
- "opml" => \&git_opml,
- "project_list" => \&git_project_list,
- "project_index" => \&git_project_index,
-);
-
if (!defined $action) {
if (defined $hash) {
$action = git_get_type($hash);
@@ -604,35 +649,12 @@ sub href (%) {
# default is to use -absolute url() i.e. $my_uri
my $href = $params{-full} ? $my_url : $my_uri;
- # XXX: Warning: If you touch this, check the search form for updating,
- # too.
-
- my @mapping = (
- project => "p",
- action => "a",
- file_name => "f",
- file_parent => "fp",
- hash => "h",
- hash_parent => "hp",
- hash_base => "hb",
- hash_parent_base => "hpb",
- page => "pg",
- order => "o",
- searchtext => "s",
- searchtype => "st",
- snapshot_format => "sf",
- extra_options => "opt",
- search_use_regexp => "sr",
- );
- my %mapping = @mapping;
-
$params{'project'} = $project unless exists $params{'project'};
if ($params{-replay}) {
- while (my ($name, $symbol) = each %mapping) {
+ while (my ($name, $symbol) = each %cgi_param_mapping) {
if (!exists $params{$name}) {
- # to allow for multivalued params we use arrayref form
- $params{$name} = [ $cgi->param($symbol) ];
+ $params{$name} = $input_params{$name};
}
}
}
@@ -651,8 +673,8 @@ sub href (%) {
# now encode the parameters explicitly
my @result = ();
- for (my $i = 0; $i < @mapping; $i += 2) {
- my ($name, $symbol) = ($mapping[$i], $mapping[$i+1]);
+ for (my $i = 0; $i < @cgi_param_mapping; $i += 2) {
+ my ($name, $symbol) = ($cgi_param_mapping[$i], $cgi_param_mapping[$i+1]);
if (defined $params{$name}) {
if (ref($params{$name}) eq "ARRAY") {
foreach my $par (@{$params{$name}}) {
@@ -672,6 +694,25 @@ sub href (%) {
## ======================================================================
## validation, quoting/unquoting and escaping
+sub validate_action {
+ my $input = shift || return undef;
+ return undef unless exists $actions{$action};
+ return $action;
+}
+
+sub validate_project {
+ my $input = shift || return undef;
+ if (!validate_pathname($input) ||
+ !(-d "$projectroot/$input") ||
+ !check_head_link("$projectroot/$input") ||
+ ($export_ok && !(-e "$projectroot/$input/$export_ok")) ||
+ ($strict_export && !project_in_list($input))) {
+ return undef;
+ } else {
+ return $input;
+ }
+}
+
sub validate_pathname {
my $input = shift || return undef;
@@ -3988,7 +4029,7 @@ sub git_search_grep_body {
## actions
sub git_project_list {
- my $order = $cgi->param('o');
+ my $order = $input_params{'order'};
if (defined $order && $order !~ m/none|project|descr|owner|age/) {
die_error(400, "Unknown order parameter");
}
@@ -4011,7 +4052,7 @@ sub git_project_list {
}
sub git_forks {
- my $order = $cgi->param('o');
+ my $order = $input_params{'order'};
if (defined $order && $order !~ m/none|project|descr|owner|age/) {
die_error(400, "Unknown order parameter");
}
@@ -4545,7 +4586,7 @@ sub git_snapshot {
my @supported_fmts = gitweb_check_feature('snapshot');
@supported_fmts = filter_snapshot_fmts(@supported_fmts);
- my $format = $cgi->param('sf');
+ my $format = $input_params{'snapshot_format'};
if (!@supported_fmts) {
die_error(403, "Snapshots not allowed");
}
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH] gitweb: refactor input parameters parse/validation
From: Jakub Narebski @ 2008-10-08 9:45 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Shawn O. Pearce
In-Reply-To: <cb7bb73a0810080210s49d1683dj4e2fef8072522abd@mail.gmail.com>
Giuseppe Bilotta wrote:
> On Tue, Oct 7, 2008 at 4:39 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> > Giuseppe Bilotta wrote:
> > Wouldn't it be simpler and as good solution to just leave validation
> > off evaluate_path_info() (well, of course except check_head_link() test),
> > and allow it to be validated when assigning global 'params' variables?
> > check_head_link() would be repeated for path_info links, but that
> > should not affect performance much.
>
> Well, it does have a performance hit in the case of invalid $project
> since it spends time working on the rest of the URL before bailing
> out, but it's probably the cleanest solution. I'll do it this way.
I have forgot about this fact, that parameter validation serves also
as early escape. But I don't think it is much performance hit in
practice; it is performance (optimization) vs. maintability tradeoff.
--
Jakub Narebski
Poland
^ permalink raw reply
* Feature Request: Branch Annotations
From: Rotem Yaari @ 2008-10-08 10:49 UTC (permalink / raw)
To: git
In-Reply-To: <d2115f4f0810080348t62e18b14x1dfe798974332b05@mail.gmail.com>
Hi,
I usually work with many branches in git, each of which represents a
different state of development/stability, but also development tasks
assigned to me.
Sometimes, besides the name of the branch, it could be useful to have
a short description of a branch which quickly reminds me what that
branch is intended for.
Currently I see no way in git to achieve this (there's a description
for a repository, but not for individual branches).
Any opinions on this?
Thanks in advance,
--
Rotem
^ permalink raw reply
* Re: Feature Request: Branch Annotations
From: Thomas Adam @ 2008-10-08 10:55 UTC (permalink / raw)
To: Rotem Yaari; +Cc: git
In-Reply-To: <d2115f4f0810080349o30b6bc2labc2745b8d981e0d@mail.gmail.com>
2008/10/8 Rotem Yaari <vmalloc@gmail.com>:
> Hi,
>
> I usually work with many branches in git, each of which represents a
> different state of development/stability, but also development tasks
> assigned to me.
> Sometimes, besides the name of the branch, it could be useful to have
> a short description of a branch which quickly reminds me what that
> branch is intended for.
>
> Currently I see no way in git to achieve this (there's a description
> for a repository, but not for individual branches).
>
> Any opinions on this?
Wasn't this discussed here before, with a prototype? ISTR it was, but
dropped due to lack of interest? Have a look through the archives.
-- Thomas Adam
^ permalink raw reply
* Re: Feature Request: Branch Annotations
From: Baz @ 2008-10-08 11:41 UTC (permalink / raw)
To: Thomas Adam; +Cc: Rotem Yaari, git
In-Reply-To: <18071eea0810080355g743c7bbfq9d7d39c9a76eb59d@mail.gmail.com>
2008/10/8 Thomas Adam <thomas.adam22@gmail.com>:
> 2008/10/8 Rotem Yaari <vmalloc@gmail.com>:
>> Hi,
>>
>> I usually work with many branches in git, each of which represents a
>> different state of development/stability, but also development tasks
>> assigned to me.
>> Sometimes, besides the name of the branch, it could be useful to have
>> a short description of a branch which quickly reminds me what that
>> branch is intended for.
>>
>> Currently I see no way in git to achieve this (there's a description
>> for a repository, but not for individual branches).
>>
>> Any opinions on this?
>
> Wasn't this discussed here before, with a prototype? ISTR it was, but
> dropped due to lack of interest? Have a look through the archives.
The most recent thread was 'branch description' back in April, which
discussed alternatives, but petered out:
http://kerneltrap.org/mailarchive/git/2008/4/15/1442684/thread
An older thread on 'topic descriptions' where Junio described his use
of the config file for this:
http://kerneltrap.org/mailarchive/git/2006/12/6/232466/thread
And there's a similar feature in stgit, which uses the same config
setting that Junio did:
http://kerneltrap.org/mailarchive/git/2007/5/14/246358
http://kerneltrap.org/mailarchive/git/2007/4/12/243404
-Baz
>
> -- Thomas Adam
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: Feature Request: Branch Annotations
From: Marc Weber @ 2008-10-08 12:08 UTC (permalink / raw)
To: git
In-Reply-To: <2faad3050810080441sdb1b29bxe92c467c2dd9a908@mail.gmail.com>
On Wed, Oct 08, 2008 at 12:41:43PM +0100, Baz wrote:
> 2008/10/8 Thomas Adam <thomas.adam22@gmail.com>:
> > 2008/10/8 Rotem Yaari <vmalloc@gmail.com>:
> >> Hi,
> >>
> >> I usually work with many branches in git, each of which represents a
> >> different state of development/stability, but also development tasks
> >> assigned to me.
> >> Sometimes, besides the name of the branch, it could be useful to have
> >> a short description of a branch which quickly reminds me what that
> >> branch is intended for.
> >>
> >> Currently I see no way in git to achieve this (there's a description
> >> for a repository, but not for individual branches).
> >>
> >> Any opinions on this?
[...]
Probably I've missed something. but doesn't top git add some special
files to remember branch relations?
I guess it removes them before merging upstream ?
I would have to reread the README or topGit source to confirm this.
Marc Weber
^ permalink raw reply
* [ANNOUNCE] tig-0.12.1
From: Jonas Fonseca @ 2008-10-08 13:14 UTC (permalink / raw)
To: git
Hello,
It's time for another release of tig, this one tagged as a minor update
focusing mainly on bug fixes. There are, however, also a few nice
usability improvements, such as support for reverting uncommitted and
unstaged changes and reloading of repository references when refreshing
the views using them. Note that this version of tig depends on git
version 1.5.4 or newer!
In the pipeline, I have a scary patch containing 859 insertions and 462
deletions, which I plan to release as the equally scary version 0.13.
The patch imports git's run-command.c module, which should remove
problems related to using stdio and will also remove the need to do
nasty things such as shell quoting. This is still a work in progress and
needs some more polishing and testing, but should anybody be interested,
it is available in the wip/run-command branch (to be rebased at will).
What is tig?
------------
Tig is an ncurses-based text-mode interface for git. It functions mainly
as a git repository browser, but can also assist in staging changes for
commit at chunk level and act as a pager for output from various git
commands.
- Homepage: http://jonas.nitro.dk/tig/
- Manual: http://jonas.nitro.dk/tig/manual.html
- Tarballs: http://jonas.nitro.dk/tig/releases/
- Git URL: git://repo.or.cz/tig.git
- Gitweb: http://repo.or.cz/w/tig.git
Release notes
-------------
Improvements:
- Status view: revert uncommitted diff chunks and unstaged files with
changes. Bound to '!' by default.
- Main view: use --topo-order also when rev-list arguments are given on
the command line.
- Log view: support for refreshing.
Bug fixes:
- Status view: use ls-files' --exclude-standard so user specific ignore
rules are effective. The option was added in git version 1.5.4.
- Stage view: fix assertion failure triggered when updating while
status view is not displayed.
- Help view: avoid confusion by showing "(no key)" instead of "'?'" for
unbound requests.
- Reload repository references when refreshing the main (and log) view.
- Do not maximize views when refreshing.
Change summary
--------------
The diffstat and log summary for changes made in this release.
NEWS | 22 +++
TODO | 9 +-
VERSION | 2 +-
configure.ac | 8 +-
contrib/announcement.sh | 53 ++++++
manual.txt | 2 +
tig.c | 381 +++++++++++++++++++++++++++------------
7 files changed, 351 insertions(+), 126 deletions(-)
Jonas Fonseca (25):
Add script for preparing release announcements
TODO: support for jumping to parents' blame in the blame view
status: add support for checking out files with unstaged changes
main: automatically refresh after run requests
Main: use --topo-order when arguments are given on the command line
Cleanup exclude rule setup by using ls-files --exclude-standard flag
Also allow files to be checked out from stage view
Avoid refreshing views when checkout is canceled by user
Reload repository references when refreshing the main view
Make GIT_CONFIG only contain the config subcommand
Improve handling of unmatched quotes in ~/.tigrc
Cleanup and make option argument strings const
Improve checkout error reporting
Show complete shortlog for small releases
Simplify view refreshing by adding new OPEN_REFRESH flag for open_view
Make OPEN_REFRESH imply OPEN_NOMAXIMIZE
Add support for refreshing the log view
Fix bug introduced in commit for using --exclude-standard flag
Clear the status line when closing a view
Help view: use "(no key)" instead of "'?'" to not confuse unbound actions
Help view: move requests from the Misc group into separate groups
Consolidate and share view resetting via new reset_view()
Avoid triggering assertion failure when reloading the status view
Rename checkout to revert and support individual diff chunks reverts
tig-0.12.1
--
Jonas Fonseca
^ permalink raw reply
* git-am: can't apply to an empty repository
From: Imre Deak @ 2008-10-08 13:24 UTC (permalink / raw)
To: git
When trying to build a repository from mbox format patches I have the
following problem:
Creating a hypothetical mbox patch:
$ echo "From: imre deak <imre.deak@gmail.com>" > 1.patch
$ touch a
$ git diff --no-index /dev/null a >> 1.patch
$ cat 1.patch
From: imre deak <imre.deak@gmail.com>
diff --git a/a b/a
new file mode 100644
index 0000000..e69de29
Apply it to a newly created repository:
$ git init
Initialized empty Git repository in /home/imde/conv/git/.git/
$ git am 1.patch
fatal: HEAD: not a valid SHA1
fatal: bad revision 'HEAD'
Is this supposed to work at all?
--Imre
^ permalink raw reply
* Re: Feature Request: Branch Annotations
From: David Soria Parra @ 2008-10-08 13:29 UTC (permalink / raw)
To: Rotem Yaari; +Cc: git
In-Reply-To: <d2115f4f0810080349o30b6bc2labc2745b8d981e0d@mail.gmail.com>
> Any opinions on this?
would be great to have something like that build in git-core like
git branch -i 'Fix bla' ds/fix next
git branch -i
ds/fix (Fix Bla)
david
^ permalink raw reply
* Re: git-who
From: Rhodes, Kate @ 2008-10-08 13:48 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <48EC4F9D.4020202@viscovery.net>
No. No, that's far too simple.
;)
-Kate
On Oct 8, 2008, at 2:13 AM, Johannes Sixt wrote:
> Rhodes, Kate schrieb:
>> Once upon a someone asked about seeing who had touched some files.
>> Petr
>> Baudis responded with a quickie script that did the job.
>
> Wouldn't
>
> git shortlog -s -- path/to/file
>
> solve your problem?
>
> -- Hannes
>
^ permalink raw reply
* Re: [RFC] git rev-contains [Was: merge -s ffonly]
From: Deskin Miller @ 2008-10-08 14:30 UTC (permalink / raw)
To: =?ISO-8859-1?Q?Uwe_Kleine-K=F6nig_
Cc: Shawn O. Pearce, git, Randal L. Schwartz
In-Reply-To: <20081007185815.GA10744@strlen.de>
On Tue, Oct 07, 2008 at 08:58:15PM +0200, =?ISO-8859-1?Q?Uwe_Kleine-K=F6nig_ wrote:
> > + if test -n "$(git rev-list $1..HEAD)"
> I already wrote similar tests and I wonder if this couldn't be done in a
> new builtin command more effectively. Something like
>
> git rev-contains HEAD "$1"
>
> . I expect it to be faster and maybe it prevents a command line
> overflow?! [...]
I'm not sure this warrants a builtin; seems like test is perfectly capable of
doing what you want:
if test '(' -n "$(git rev-list --max-count=1 $1..HEAD)" ')' -a \
'(' -z "$(git rev-list --max-count=1 HEAD..$1)" ')'
The second check is needed to ensure that the commits actually have an
ancestor-descendant relationship. And --max-count means your command line
won't overflow.
Or what about this:
if test "$(git merge-base $1 HEAD)" = "$(git rev-parse $1)"
My $0.02,
Deskin Miller
^ permalink raw reply
* Re: [PATCH 2/2 v2] check-attr: Add --stdin-paths option
From: Shawn O. Pearce @ 2008-10-08 15:24 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Johannes Sixt, Alexander Gavrilov, git, Paul Mackerras
In-Reply-To: <20081007001652.GR21650@dpotapov.dyndns.org>
Dmitry Potapov <dpotapov@gmail.com> wrote:
> This allows multiple paths to be specified on stdin.
> diff --git a/Documentation/git-check-attr.txt b/Documentation/git-check-attr.txt
> index 2b821f2..0839a57 100644
> --- a/Documentation/git-check-attr.txt
> +++ b/Documentation/git-check-attr.txt
> @@ -9,6 +9,7 @@ git-check-attr - Display gitattributes information.
> SYNOPSIS
> --------
> 'git check-attr' attr... [--] pathname...
> +'git check-attr' --stdin-paths attr... < <list-of-paths
I wonder if the option should just be "--stdin". And since its being
used mostly by automated tools (gitk/git-gui) I wonder if a -z should
also be supported for input termination with NUL instead of LF.
> diff --git a/t/t0003-attributes.sh b/t/t0003-attributes.sh
> index 3d8e06a..f6901b4 100755
> --- a/t/t0003-attributes.sh
> +++ b/t/t0003-attributes.sh
> @@ -47,6 +47,23 @@ test_expect_success 'attribute test' '
>
> '
>
> +test_expect_success 'attribute test: read paths from stdin' '
A test case for the quoting might also be good.
> +
> + cat <<EOF > expect
> +f: test: f
> +a/f: test: f
> +a/c/f: test: f
> +a/g: test: a/g
> +a/b/g: test: a/b/g
> +b/g: test: unspecified
> +a/b/h: test: a/b/h
> +a/b/d/g: test: a/b/d/*
> +EOF
> +
> + sed -e "s/:.*//" < expect | git check-attr --stdin-paths test > actual &&
> + test_cmp expect actual
--
Shawn.
^ permalink raw reply
* Re: [RFC] git rev-contains [Was: merge -s ffonly]
From: Uwe Kleine-König @ 2008-10-08 15:41 UTC (permalink / raw)
To: Deskin Miller; +Cc: Shawn O. Pearce, git, Randal L. Schwartz
In-Reply-To: <20081008143050.GG3052@riemann.deskinm.fdns.net>
Hello Deskin,
On Wed, Oct 08, 2008 at 10:30:50AM -0400, Deskin Miller wrote:
> On Tue, Oct 07, 2008 at 08:58:15PM +0200, =?ISO-8859-1?Q?Uwe_Kleine-K=F6nig_ wrote:
> > > + if test -n "$(git rev-list $1..HEAD)"
> > I already wrote similar tests and I wonder if this couldn't be done in a
> > new builtin command more effectively. Something like
> >
> > git rev-contains HEAD "$1"
> >
> > . I expect it to be faster and maybe it prevents a command line
> > overflow?! [...]
>
> I'm not sure this warrants a builtin; seems like test is perfectly capable of
> doing what you want:
>
> if test '(' -n "$(git rev-list --max-count=1 $1..HEAD)" ')' -a \
> '(' -z "$(git rev-list --max-count=1 HEAD..$1)" ')'
>
> The second check is needed to ensure that the commits actually have an
> ancestor-descendant relationship.
This is needed for the original patch, too, isn't it.
> And --max-count means your command line
> won't overflow.
ah, --max-count is a nice idea. Topgit could benefit from it.
> Or what about this:
>
> if test "$(git merge-base $1 HEAD)" = "$(git rev-parse $1)"
It's not entirely clear to me, this works in general, because a
merge-base isn't unique. It should work in this case, though.
Best regards
Uwe
^ permalink raw reply
* Re: Git and tagging hook
From: Kristis Makris @ 2008-10-08 16:47 UTC (permalink / raw)
To: Jakub Narebski
Cc: git-u79uwXL29TY76Z2rM5mHXA, scmbug-users-G8y9j4K4DsPiwOUmbS1EgQ
In-Reply-To: <gcg67d$4o2$1@ger.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 791 bytes --]
On Tue, 2008-10-07 at 19:28 +0200, Jakub Narebski wrote:
> Kristis Makris wrote:
>
> > But the post-receive is NOT executed when I apply a tag.
> >
> > I want the integration when I apply the tag to a local repository, NOT
> > only when I push/pull.
>
> If you are talking about taging locally, you can simply make an alias
> or do something after tagging. Search archives for description when
> it is worth to add a hook, and when it is not.
I am looking for a guarantee that is better than casually saying
"simply". I will be providing the integration work to users that may not
be as comfortable with making aliases.
I still don't see why a hook on local tagging is not available. Is it
possible to add support in Git for such a hook ? Both pre-tag and
post-tag.
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #2: Type: text/plain, Size: 188 bytes --]
_______________________________________________
scmbug-users mailing list
scmbug-users-G8y9j4K4DsPiwOUmbS1EgQ@public.gmane.org
http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
^ permalink raw reply
* Re: Git and tagging hook
From: Andreas Ericsson @ 2008-10-08 17:40 UTC (permalink / raw)
To: Kristis Makris; +Cc: Jakub Narebski, git
In-Reply-To: <1223484445.4055.8.camel@localhost>
Kristis Makris wrote:
> On Tue, 2008-10-07 at 19:28 +0200, Jakub Narebski wrote:
>> Kristis Makris wrote:
>>
>>> But the post-receive is NOT executed when I apply a tag.
>>>
>>> I want the integration when I apply the tag to a local repository, NOT
>>> only when I push/pull.
>> If you are talking about taging locally, you can simply make an alias
>> or do something after tagging. Search archives for description when
>> it is worth to add a hook, and when it is not.
>
> I am looking for a guarantee that is better than casually saying
> "simply". I will be providing the integration work to users that may not
> be as comfortable with making aliases.
>
> I still don't see why a hook on local tagging is not available. Is it
> possible to add support in Git for such a hook ? Both pre-tag and
> post-tag.
Because noone's ever needed one before. If aliases can't do what you
want, write a patch to support it and hope Junio accepts it. It's really
quite straight-forward. Make sure you read Documentation/SubmittingPatches
before you send it.
Note though that use of tags on the developer's side will still be up
to the developer and not something you can force through other means
than policy or convention.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git-who
From: Linus Torvalds @ 2008-10-08 18:35 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Rhodes, Kate, Git Mailing List
In-Reply-To: <48EC4F9D.4020202@viscovery.net>
On Wed, 8 Oct 2008, Johannes Sixt wrote:
>
> Wouldn't
>
> git shortlog -s -- path/to/file
I suspect "-sn" is better. It sorts by number rather than by name, and if
you're interested in who has touched a file, you probably wants to know
who has touched it _most_.
And as usual, the nice thing about it is that all the normal git rules
apply, so you can do it by multiple files or subdirectories, and you can
filter by time. And ignore merges, since they tend to be about upper-level
maintainers than about the people doing patches.
So for the kernel, you can do something like
git shortlog -ns --no-merges --since=6.months.ago drivers/scsi include/scsi
and see who has been doing scsi-related stuff lately.
Of course, when it comes to relevance, it may be more interesting to just
look at 'git blame' output, and then you're limited to single files at a
time. And performance is going to be a problem, especially if you enable
movement detection.
But we don't have anything special for that. You can do it with something
like
git blame -M -w kernel/sched.c |
grep -v '^^' |
cut -d'(' -f2- |
cut -c1-20 |
sort |
uniq -c |
sort -n
which will ignore the root commit (so as not to give me all the credit for
old history), but it would probably be better (but more complex - need
perl or some other "real" language with associative arrays etc to remember
the commit information) to parse the output of "git blame --incremental"
instead.
Linus
^ permalink raw reply
* [PATCH] builtin-apply: fix typo leading to stack corruption
From: Imre Deak @ 2008-10-08 21:24 UTC (permalink / raw)
To: git
This typo led to stack corruption for lines with whitespace fixes
and length > 1024.
---
builtin-apply.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-apply.c b/builtin-apply.c
index 20bef1f..720dc7f 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -1696,7 +1696,7 @@ static int match_fragment(struct image *img,
fixlen = ws_fix_copy(buf, orig, oldlen, ws_rule, NULL);
/* Try fixing the line in the target */
- if (sizeof(tgtfixbuf) < tgtlen)
+ if (sizeof(tgtfixbuf) > tgtlen)
tgtfix = tgtfixbuf;
else
tgtfix = xmalloc(tgtlen);
--
1.6.0.2.308.g754c
^ permalink raw reply related
* Re: Feature Request: Branch Annotations
From: Junio C Hamano @ 2008-10-08 23:12 UTC (permalink / raw)
To: David Soria Parra; +Cc: Rotem Yaari, git
In-Reply-To: <48ECB5CB.4010703@gmx.net>
David Soria Parra <sn_@gmx.net> writes:
>> Any opinions on this?
>
> would be great to have something like that build in git-core like
>
> git branch -i 'Fix bla' ds/fix next
> git branch -i
> ds/fix (Fix Bla)
Haven't people watched Linus on google tech talk? Here is an excerpt from
the transcript (http://git.or.cz/gitwiki/LinusTalk200705Transcript):
... well actually you shouldn't call it "test", you should basically
name your branches the way you name your functions, you should call
them something short and sweet and to the point -- What is that branch
doing.
IOW, why did you name the branch "ds/fix" and not "ds/fix-bla"?
^ permalink raw reply
* Re: Feature Request: Branch Annotations
From: David Soria Parra @ 2008-10-08 23:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Rotem Yaari, git
In-Reply-To: <7vwsgiptph.fsf@gitster.siamese.dyndns.org>
> Haven't people watched Linus on google tech talk? Here is an excerpt from
> the transcript (http://git.or.cz/gitwiki/LinusTalk200705Transcript):
>
> ... well actually you shouldn't call it "test", you should basically
> name your branches the way you name your functions, you should call
> them something short and sweet and to the point -- What is that branch
> doing.
>
> IOW, why did you name the branch "ds/fix" and not "ds/fix-bla"?
Okay I just choosed a bad example. Actually I call it ds/fix-function,
but nevertheless more additional description can be useful when dealing
with a lot of branches. But yes, there might be porcelains that can do that.
^ permalink raw reply
* Re: Feature Request: Branch Annotations
From: Avery Pennarun @ 2008-10-08 23:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: David Soria Parra, Rotem Yaari, git
In-Reply-To: <7vwsgiptph.fsf@gitster.siamese.dyndns.org>
On 10/8/08, Junio C Hamano <gitster@pobox.com> wrote:
> David Soria Parra <sn_@gmx.net> writes:
>
> >> Any opinions on this?
> >
> > would be great to have something like that build in git-core like
> >
> > git branch -i 'Fix bla' ds/fix next
> > git branch -i
> > ds/fix (Fix Bla)
>
> Haven't people watched Linus on google tech talk? Here is an excerpt from
> the transcript (http://git.or.cz/gitwiki/LinusTalk200705Transcript):
>
> ... well actually you shouldn't call it "test", you should basically
> name your branches the way you name your functions, you should call
> them something short and sweet and to the point -- What is that branch
> doing.
>
> IOW, why did you name the branch "ds/fix" and not "ds/fix-bla"?
Because it would be excessive typing every time you want to do
something to that branch?
I guess bash completions would help with this (if you're using bash),
but even then it's kind of unreasonable to name branches something
like "bug-111234-widget-performance-improvements-for-customer-x",
which is the sort of information that would be awfully helpful two
months later when you're looking at old unmerged branches.
Avery
^ 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