* [PATCH] git-push.txt: Describe --repo option in more detail
From: Johannes Sixt @ 2008-10-07 14:26 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Git Mailing List, Junio C Hamano, Daniel Barkalow
From: Johannes Sixt <johannes.sixt@telecom.at>
The --repo option was described in a way that the reader would have to
assume that it is the same as the <repository> parameter. But it actually
servers a purpose, which is now written down.
Furthermore, the --mirror option was missing from the synopsis.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
I do not have the toolchain to format the documentation, so please take
this with a grain of salt.
-- Hannes
Documentation/git-push.txt | 24 +++++++++++++++++++-----
builtin-push.c | 2 +-
2 files changed, 20 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 45c9643..6150b1b 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -9,8 +9,8 @@ git-push - Update remote refs along with associated objects
SYNOPSIS
--------
[verse]
-'git push' [--all] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>]
- [--repo=all] [-f | --force] [-v | --verbose]
+'git push' [--all | --mirror] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>]
+ [--repo=<repository>] [-f | --force] [-v | --verbose]
[<repository> <refspec>...]
DESCRIPTION
@@ -101,9 +101,23 @@ nor in any Push line of the corresponding remotes file---see below).
This flag disables the check. This can cause the
remote repository to lose commits; use it with care.
---repo=<repo>::
- When no repository is specified the command defaults to
- "origin"; this overrides it.
+--repo=<repository>::
+ This option is only relevant if no <repository> argument is
+ passed in the invocation. In this case, 'git-push' derives the
+ remote name from the current branch: If it tracks a remote
+ branch, then that remote repository is pushed to. Otherwise,
+ the name "origin" is used. For this latter case, this option
+ can be used to override the name "origin". In other words,
+ the difference between these two commands
++
+--------------------------
+git push public #1
+git push --repo=public #2
+--------------------------
++
+is that #1 always pushes to "public" whereas #2 pushes to "public"
+only if the current branch does not track a remote branch. This is
+useful if you write an alias or script around 'git-push'.
--thin::
--no-thin::
diff --git a/builtin-push.c b/builtin-push.c
index cc6666f..122fdcf 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -10,7 +10,7 @@
#include "parse-options.h"
static const char * const push_usage[] = {
- "git push [--all | --mirror] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>] [--repo=all] [-f | --force] [-v] [<repository> <refspec>...]",
+ "git push [--all | --mirror] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>] [--repo=<repository>] [-f | --force] [-v] [<repository> <refspec>...]",
NULL,
};
--
1.6.0.2.651.gd07df
^ permalink raw reply related
* Re: Git pager woes
From: J.R. Mauro @ 2008-10-07 14:24 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <48EB70C4.1070001@op5.se>
Ok. Thanks.
^ permalink raw reply
* Re: Git pager woes
From: Andreas Ericsson @ 2008-10-07 14:23 UTC (permalink / raw)
To: J.R. Mauro; +Cc: git
In-Reply-To: <3aaafc130810070643m352ea2ufa1069dc149f0d9e@mail.gmail.com>
J.R. Mauro wrote:
> Git doesn't set special options to it's pager command if the LESS
> environment variable is set. I noticed when I started using Gentoo
> that git was putting all output into a pager even if it were less than
> one page, which it didn't do under Ubuntu. A fellow Gentoo user
> confirms this; apparently Gentoo's defaults set LESS, but without a
> -F.
>
> Should git always tack on a -F when it invokes less, or should this be
> put on the user to look up what to do? Or should I go complain to the
> Gentoo folks?
Go complain to Gentoo. If the user has set it explicitly (even if that
happens behind the user's back), we absolutely mustn't fiddle with it.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Git pager woes
From: J.R. Mauro @ 2008-10-07 13:43 UTC (permalink / raw)
To: git
Git doesn't set special options to it's pager command if the LESS
environment variable is set. I noticed when I started using Gentoo
that git was putting all output into a pager even if it were less than
one page, which it didn't do under Ubuntu. A fellow Gentoo user
confirms this; apparently Gentoo's defaults set LESS, but without a
-F.
Should git always tack on a -F when it invokes less, or should this be
put on the user to look up what to do? Or should I go complain to the
Gentoo folks?
^ permalink raw reply
* [QGIT PATCH] Add safeguards to Git::userInfo()
From: Abdelrazak Younes @ 2008-10-07 13:10 UTC (permalink / raw)
To: Marco Costalba; +Cc: Git Mailing List
In-Reply-To: <e5bfff550810070457i702c2935lfcc0b60ae3df4dc4@mail.gmail.com>
On 07/10/2008 13:57, Marco Costalba wrote:
> On Tue, Oct 7, 2008 at 1:36 PM, Abdelrazak Younes<younes@lyx.org> wrote:
>
>>> Sound like a problem of startup directory: on the command line you
>>> start from the right directory...when you double click on which repo
>>> qgit is open ?
>>>
>>>
>> None of course. But when I open a repository manually I would expect that
>> this is properly filled in.
>>
>>
>
> In git.cpp, Git::userInfo() function get info about user by means of
> 'git config' calls, my guess (I cannot it test now) is that 'git
> config' does not work if we are not in a git directory.
>
OK, with this patch, I see that the local config request is apparently
successful even though the 'user' and 'email' strings stay empty.
OTOH, the two global config requests fail.
---
src/git.cpp | 19 ++++++++++++-------
1 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/src/git.cpp b/src/git.cpp
index 4ffc4ea..e77f4a1 100755
--- a/src/git.cpp
+++ b/src/git.cpp
@@ -6,6 +6,8 @@
Copyright: See COPYING file that comes with this distribution
*/
+#include <string>
+
#include <QApplication>
#include <QDateTime>
#include <QDir>
@@ -347,13 +349,16 @@ void Git::userInfo(SList info) {
errorReportingEnabled = false; // 'git config' could fail, see docs
- run("git config user.name", &user);
- run("git config user.email", &email);
- info << "Local config" << user << email;
-
- run("git config --global user.name", &user);
- run("git config --global user.email", &email);
- info << "Global config" << user << email;
+ if (bool success = run("git config user.name", &user)) {
+ success = run("git config user.email", &email);
+ if (success)
+ info << "Local config" << user << email;
+ }
+ if (bool success = run("git config --global user.name", &user)) {
+ success = run("git config --global user.email", &email);
+ if (success)
+ info << "Global config" << user << email;
+ }
errorReportingEnabled = true;
}
--
1.6.0.2.1172.ga5ed0
^ permalink raw reply related
* Re: [PATCH] gitweb: refactor input parameters parse/validation
From: Giuseppe Bilotta @ 2008-10-07 12:42 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Shawn O. Pearce, Matthias Lederhofer
In-Reply-To: <200810071257.38423.jnareb@gmail.com>
On Tue, Oct 7, 2008 at 12:57 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Fri, 3 Oct 2008, Giuseppe Bilotta wrote:
>> +# 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$,,;
>> }
>
> I think we could have left it as it was, i.e. have $path_info be
> a local variable. Unless there is something I don't see.
Well, it's being reassigned locally in evaluate_path_info ... since
we're looking at it anyway, I thought it made sense to do it once and
for all. The var could also potentially have other uses, such as
enabling the use of path_info whenever path_info was used (something
which is currently not done), so ...
>> +# input parameters are stored with the long parameter name as key, so we need
>> +# the name -> CGI key mapping here. This will also be used in the href
>> +# subroutine to convert parameters to their CGI equivalent.
>
> Actually href() subroutine would be called many times, while parsing of
> input params happens only once; that is why it is longname => shortname
> hash, and not the reverse (shortname => longname). Also it does not
> result in loss of performance as we parse all input params anyway.
>
> This explanation might be obvious, or could be put in comment
> (increasing comment to code count ;-))
It's actually a good point, I'll put it in (and not for the comment to
code ratio 8-D)
>> +my @cgi_param_mapping = (
>> +my %cgi_param_mapping = @cgi_param_mapping;
>> +my %actions = (
>
> Perhaps %allowed_options should also be there, to have everything about
> input params in single place... or perhaps not...
I had thought about it. It makes sense in a way to put it after
cgi_param_mapping. I didn't do it to reduce the code move.
>> +# 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)];
>
> I would personally use "[ $cgi->param($symbol) ]" instead for better
> (IMVHO) visibility, but this is just a matter of taste.
Ah yes, much more readable. I'll do it.
>> + } else {
>> + $input_params{$name} = $cgi->param($symbol);
>> + }
>> +}
>
> Nice. I guess that you have checked that you caught all
> $cgi->param(...) calls, and there aren't any beside those above...
I did a grep so I *think* I didn't miss any.
>> +# now read PATH_INFO and update the parameter list for missing parameters
>> +sub evaluate_path_info {
>> + return if defined $input_params{'project'};
>
> I was 'my $path_info = $ENV{"PATH_INFO"};' there, when $path_info
> wasn't global variable. Any advantages to having it global?
>
> (This is just a minor thing, not worth resending patch over, I think).
As I mentioned above, just sparing a double assignment for something
that is going to be checked anyway both at the beginning and here. And
it can also have other uses, potentially.
>> + # 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-)
>> + $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.
>> + 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/*,,;
>
> Hmmm... I wonder if it is good idea. It was done in commit 645927c
> (gitweb: fix warnings in PATH_INFO code and add export_ok/strict_export)
> by Matthias Lederhofer, but I don't see why we do not remove project
> from path_info if action is set. But this is belongs probably to
> independent code cleanup (if it is needed), so don't worry about that.
path_info information is simply discarded if action was already
defined, because it was assumed that path_info was only used for
default action. it's something that might be retaught with the rest of
the path_info enhancements.
> Perhaps it would be good to add empty line here before beginning of
> 'hash' and 'hash_base:file_name' handling.
Can do.
>> + 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
>
> Additionally git_get_type(<extended sha1>) is additional call to git
> (additional fork) currently; that might change with gitweb caching code,
> which uses permanent connection to 'git cat-file --batch/--batch-check'
> for that.
I can add that to the comment.
>> + $pathname =~ s,^/+,,;
>> + if (!$pathname || substr($pathname, -1) eq "/") {
>> + $input_params{'action'} = "tree";
>> + $pathname =~ s,/$,,;
>> + } else {
>> + $input_params{'action'} = "blob_plain";
>> + }
>> + $input_params{'hash_base'} ||= validate_refname($refname);
>> + $input_params{'file_name'} ||= validate_pathname($pathname);
>> + } elsif (defined $refname) {
>> + # we got "project.git/branch"
>> + $input_params{'action'} = "shortlog";
>> + $input_params{'hash'} ||= validate_refname($refname);
>> + }
>> +}
>
> Nice defensive programming with '||=' here for setting %input_params.
>
> [After examining code further]. But I think you do double validation;
> see comment below.
[see above]
>> +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");
>> }
>> }
>
> Hmm... don't you do double validation now? Once in evaluate_path_info,
> and once copying to global variables like $action?
>
> Very nice moving param validation for 'a'/'action' parameter to
> validate_action() subroutine.
As I mentioned, this could be the solution to the double validation,
I'll just validate the cgi params separately from the path_info ones,
and only embed validated parameters in the %input_params hash
>> +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 param was not set.
Ah, yes. I'll add it.
>> 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};
>> }
>> }
>> }
>
> Nice cleanup.
Well, one would expect, given that this was the 'trigger' ;-)
I'll try to whip up a revised patch ASAP.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [QGit bug] git user settings not retrieved when launched for Windows explorer
From: Abdelrazak Younes @ 2008-10-07 12:31 UTC (permalink / raw)
To: Marco Costalba; +Cc: Git Mailing List
In-Reply-To: <e5bfff550810070457i702c2935lfcc0b60ae3df4dc4@mail.gmail.com>
On 07/10/2008 13:57, Marco Costalba wrote:
> On Tue, Oct 7, 2008 at 1:36 PM, Abdelrazak Younes<younes@lyx.org> wrote:
>
>>> Sound like a problem of startup directory: on the command line you
>>> start from the right directory...when you double click on which repo
>>> qgit is open ?
>>>
>>>
>> None of course. But when I open a repository manually I would expect that
>> this is properly filled in.
>>
>>
>
> In git.cpp, Git::userInfo() function get info about user by means of
> 'git config' calls, my guess (I cannot it test now) is that 'git
> config' does not work if we are not in a git directory.
>
No, 'git config user.name' works fine in any directory, even on the
naked Windows console (I mean without msys bash). So that must be
something else. I've traced it down to
MyProcess::on_finished().
isErrorExit = (exitStatus != QProcess::NormalExit)
|| (exitCode != 0 && isWinShell)
|| !errorDesc.isEmpty()
|| canceling;
At this point we have:
exitStatus = NormalExit
exitCode = 1
isWinShell = false
errorDesc.isEmpty() returns true
canceling = false
Which gives 'isErrorExit = false'. I wonder if the isWinShell test is
correct?
Abdel.
^ permalink raw reply
* Re: [PATCH RFC] rebase--interactive: if preserving merges, use first-parent to limit what is shown.
From: Avi Kivity @ 2008-10-07 12:22 UTC (permalink / raw)
To: Stephan Beyer; +Cc: Stephen Haberman, git
In-Reply-To: <20081007120700.GC7209@leksak.fem-net>
Stephan Beyer wrote:
> Hi,
>
> Avi Kivity wrote:
>
>> If git rebase is to handle nonlinear history, it needs much more
>> expressive commands; not only saying which commit to pick, but also what
>> the commit's parents shall be.
>>
>
> git-sequencer has a "merge" command for that. I'm really sorry that this has
> not been sent to the list yet. Nevertheless I'm always glad to find testers
> for sequencer, so if you like, fetch
> git://repo.or.cz/git/sbeyer.git seq-builtin-dev
>
>
But this isn't a merge; it's more of a 'pick into this branch' instead.
Maybe 'merge' can do this, but we also need to populate the todo with
the required information (otherwise, git rebase -i without changes to
the todo file will not be a no-op).
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [QGit bug] git user settings not retrieved when launched for Windows explorer
From: Abdelrazak Younes @ 2008-10-07 12:08 UTC (permalink / raw)
To: Marco Costalba; +Cc: Git Mailing List
In-Reply-To: <e5bfff550810070457i702c2935lfcc0b60ae3df4dc4@mail.gmail.com>
On 07/10/2008 13:57, Marco Costalba wrote:
> On Tue, Oct 7, 2008 at 1:36 PM, Abdelrazak Younes<younes@lyx.org> wrote:
>
>>> Sound like a problem of startup directory: on the command line you
>>> start from the right directory...when you double click on which repo
>>> qgit is open ?
>>>
>>>
>> None of course. But when I open a repository manually I would expect that
>> this is properly filled in.
>>
>>
>
> In git.cpp, Git::userInfo() function get info about user by means of
> 'git config' calls, my guess (I cannot it test now) is that 'git
> config' does not work if we are not in a git directory.
>
OK, I'll have a look, thanks.
>
>
>> And if I launch qgit with the context menu (right clicking a directory in
>> the Explorer), qgit never managed to open the repository.
>>
>>
>
> This is a bug that I never managed to get rid of :-(
>
> It is strange because it works if you try in a subdirectory, as
> example try right clicking on 'src' directory of qgit project.
>
I tried and it doesn't work this way either; the statusbar tells me that
this is 'Not a git archive' :-(
Abdel.
^ permalink raw reply
* Re: [PATCH RFC] rebase--interactive: if preserving merges, use first-parent to limit what is shown.
From: Stephan Beyer @ 2008-10-07 12:07 UTC (permalink / raw)
To: Avi Kivity; +Cc: Stephen Haberman, git
In-Reply-To: <48EB32A4.80809@redhat.com>
Hi,
Avi Kivity wrote:
> If git rebase is to handle nonlinear history, it needs much more
> expressive commands; not only saying which commit to pick, but also what
> the commit's parents shall be.
git-sequencer has a "merge" command for that. I'm really sorry that this has
not been sent to the list yet. Nevertheless I'm always glad to find testers
for sequencer, so if you like, fetch
git://repo.or.cz/git/sbeyer.git seq-builtin-dev
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: [QGit bug] git user settings not retrieved when launched for Windows explorer
From: Marco Costalba @ 2008-10-07 11:57 UTC (permalink / raw)
To: Abdelrazak Younes; +Cc: Git Mailing List
In-Reply-To: <48EB49B3.1090509@lyx.org>
On Tue, Oct 7, 2008 at 1:36 PM, Abdelrazak Younes <younes@lyx.org> wrote:
>
>> Sound like a problem of startup directory: on the command line you
>> start from the right directory...when you double click on which repo
>> qgit is open ?
>>
>
> None of course. But when I open a repository manually I would expect that
> this is properly filled in.
>
In git.cpp, Git::userInfo() function get info about user by means of
'git config' calls, my guess (I cannot it test now) is that 'git
config' does not work if we are not in a git directory.
> And if I launch qgit with the context menu (right clicking a directory in
> the Explorer), qgit never managed to open the repository.
>
This is a bug that I never managed to get rid of :-(
It is strange because it works if you try in a subdirectory, as
example try right clicking on 'src' directory of qgit project.
Thanks
Marco
^ permalink raw reply
* Re: [QGit] Can't compile under windows (MSVC2008)
From: Abdelrazak Younes @ 2008-10-07 11:55 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <48EB4ADF.8010908@lyx.org>
On 07/10/2008 13:41, Abdelrazak Younes wrote:
> On 07/10/2008 13:14, Marco Costalba wrote:
>> 2008/9/23 Abdelrazak Younes<younes@lyx.org>:
>>> Hello,
>>>
>>> I tried to follow README_WIN.txt:
>>>
>>> C:\devel\qgit\qgit4>qmake qgit.pro
>>>
>>> The Makefile (attached to this mail) seems to be correctly generated
>>> in the
>>> same directory (C:\devel\qgit\qgit4).
>>>
>>> Then, under MSVC2008 Express, I get this error:
>>>
>>> 1>------ Début de la génération : Projet : qgit, Configuration :
>>> Debug Win32
>>> ------
>>> 1>Actions de projet Makefile en cours
>>> 1>Microsoft (R) Program Maintenance Utility Version 9.00.21022.08
>>> 1>Copyright (C) Microsoft Corporation. Tous droits rÚservÚs.
>>> 1> cd src\&& "C:\Program Files\Microsoft Visual Studio
>>> 9.0\VC\bin\nmake.exe" debug
>>> 1>Microsoft (R) Program Maintenance Utility Version 9.00.21022.08
>>> 1>Copyright (C) Microsoft Corporation. Tous droits rÚservÚs.
>>> 1>NMAKE : fatal error U1073: incapable d'obtenir 'src\\Makefile'
>>> 1>Stop.
>>> 1>NMAKE : fatal error U1077: 'cd'á: code retour '0x2'
>>> 1>Stop.
>>> 1>Project : error PRJ0019: Un outil a retourné un code d'erreur à
>>> partir de
>>> "Actions de projet Makefile en cours"
>>> 1>Le journal de génération a été enregistré à l'emplacement
>>> "file://c:\devel\qgit\qgit4\Debug\BuildLog.htm"
>>> 1>qgit - 3 erreur(s), 0 avertissement(s)
>>> ========== Génération : 0 a réussi, 1 a échoué, 0 mis à jour, 0 a
>>> été ignoré
>>> ==========
>>>
>>> Idea someone?
>>>
>>
>> have you tried to setup MSVC for custom build ?
>
> Sorry, I don't follow you.
>
>> and pass proper
>> comamnd line with nmake ?
>
> In the NMAKE field of the project properties, there is 'nmake /f
> Makefile debug', is that what you mean?
OK, by removing '/f Makefile' I manage to compile qgit from within
Visual Studio. I also managed to launch it in debug mode by selecting
the executable in ../bin/qgit.exe. When launched this way (F5), qgit
opens up with the qgit repository but the user name and email are still
not filled in, I'll try to debug that now.
Abdel.
^ permalink raw reply
* Re: [QGit bug] git user settings not retrieved when launched for Windows explorer
From: Abdelrazak Younes @ 2008-10-07 11:42 UTC (permalink / raw)
To: Marco Costalba; +Cc: Git Mailing List
In-Reply-To: <e5bfff550810070416y4db5a37t7302c2a0562f1527@mail.gmail.com>
On 07/10/2008 13:16, Marco Costalba wrote:
> On Tue, Oct 7, 2008 at 9:33 AM, Abdelrazak Younes<younes@lyx.org> wrote:
>
>> Dear Marco,
>>
>>
>> By the way, these two edit boxes are not editable on Windows, is that on
>> purpose? If yes, maybe we could let the user change them is 'Local config'
>> is selected and call the appropriate git function?
>>
>>
>
> I know this limitation. I was just too lazy to implement edit
> myself...it would be a nice patch to have tough ;-)
>
I am not sure I'll find the time to learn enough about git internals to
do that kind of stuff. Maybe later.
Abdel.
^ permalink raw reply
* Re: [QGit] Can't compile under windows (MSVC2008)
From: Abdelrazak Younes @ 2008-10-07 11:41 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <e5bfff550810070414u283f5ccav33712ca1c6212bde@mail.gmail.com>
On 07/10/2008 13:14, Marco Costalba wrote:
> 2008/9/23 Abdelrazak Younes<younes@lyx.org>:
>
>> Hello,
>>
>> I tried to follow README_WIN.txt:
>>
>> C:\devel\qgit\qgit4>qmake qgit.pro
>>
>> The Makefile (attached to this mail) seems to be correctly generated in the
>> same directory (C:\devel\qgit\qgit4).
>>
>> Then, under MSVC2008 Express, I get this error:
>>
>> 1>------ Début de la génération : Projet : qgit, Configuration : Debug Win32
>> ------
>> 1>Actions de projet Makefile en cours
>> 1>Microsoft (R) Program Maintenance Utility Version 9.00.21022.08
>> 1>Copyright (C) Microsoft Corporation. Tous droits rÚservÚs.
>> 1> cd src\&& "C:\Program Files\Microsoft Visual Studio
>> 9.0\VC\bin\nmake.exe" debug
>> 1>Microsoft (R) Program Maintenance Utility Version 9.00.21022.08
>> 1>Copyright (C) Microsoft Corporation. Tous droits rÚservÚs.
>> 1>NMAKE : fatal error U1073: incapable d'obtenir 'src\\Makefile'
>> 1>Stop.
>> 1>NMAKE : fatal error U1077: 'cd'á: code retour '0x2'
>> 1>Stop.
>> 1>Project : error PRJ0019: Un outil a retourné un code d'erreur à partir de
>> "Actions de projet Makefile en cours"
>> 1>Le journal de génération a été enregistré à l'emplacement
>> "file://c:\devel\qgit\qgit4\Debug\BuildLog.htm"
>> 1>qgit - 3 erreur(s), 0 avertissement(s)
>> ========== Génération : 0 a réussi, 1 a échoué, 0 mis à jour, 0 a été ignoré
>> ==========
>>
>> Idea someone?
>>
>>
>
> have you tried to setup MSVC for custom build ?
Sorry, I don't follow you.
> and pass proper
> comamnd line with nmake ?
>
In the NMAKE field of the project properties, there is 'nmake /f
Makefile debug', is that what you mean?
Abdel.
^ permalink raw reply
* Re: [QGit bug] git user settings not retrieved when launched for Windows explorer
From: Abdelrazak Younes @ 2008-10-07 11:36 UTC (permalink / raw)
To: Marco Costalba; +Cc: Git Mailing List
In-Reply-To: <e5bfff550810070410t1097ace4pf401821292fd7565@mail.gmail.com>
On 07/10/2008 13:10, Marco Costalba wrote:
> On Tue, Oct 7, 2008 at 9:33 AM, Abdelrazak Younes<younes@lyx.org> wrote:
>
>> Dear Marco,
>>
>> When I double click on qgit.exe, the user name and email are not shown in
>> the user settings (for any of the 3 combo values). But if I run qgit from
>> the commandline at the mysysgit bash prompt, the boxes are properly filled.
>> I would like to debug it but, as I reported last week, the MSVC project
>> doesn't work for me.
>>
>>
>
> Sound like a problem of startup directory: on the command line you
> start from the right directory...when you double click on which repo
> qgit is open ?
>
None of course. But when I open a repository manually I would expect
that this is properly filled in.
And if I launch qgit with the context menu (right clicking a directory
in the Explorer), qgit never managed to open the repository.
Abdel.
^ permalink raw reply
* Re: [QGit bug] git user settings not retrieved when launched for Windows explorer
From: Marco Costalba @ 2008-10-07 11:16 UTC (permalink / raw)
To: Abdelrazak Younes; +Cc: Git Mailing List
In-Reply-To: <48EB10C8.4070009@lyx.org>
On Tue, Oct 7, 2008 at 9:33 AM, Abdelrazak Younes <younes@lyx.org> wrote:
> Dear Marco,
>
>
> By the way, these two edit boxes are not editable on Windows, is that on
> purpose? If yes, maybe we could let the user change them is 'Local config'
> is selected and call the appropriate git function?
>
I know this limitation. I was just too lazy to implement edit
myself...it would be a nice patch to have tough ;-)
Thanks
Marco
^ permalink raw reply
* Re: [QGit] Can't compile under windows (MSVC2008)
From: Marco Costalba @ 2008-10-07 11:14 UTC (permalink / raw)
To: Abdelrazak Younes; +Cc: git
In-Reply-To: <gbak2u$v9b$1@ger.gmane.org>
2008/9/23 Abdelrazak Younes <younes@lyx.org>:
> Hello,
>
> I tried to follow README_WIN.txt:
>
> C:\devel\qgit\qgit4>qmake qgit.pro
>
> The Makefile (attached to this mail) seems to be correctly generated in the
> same directory (C:\devel\qgit\qgit4).
>
> Then, under MSVC2008 Express, I get this error:
>
> 1>------ Début de la génération : Projet : qgit, Configuration : Debug Win32
> ------
> 1>Actions de projet Makefile en cours
> 1>Microsoft (R) Program Maintenance Utility Version 9.00.21022.08
> 1>Copyright (C) Microsoft Corporation. Tous droits rÚservÚs.
> 1> cd src\ && "C:\Program Files\Microsoft Visual Studio
> 9.0\VC\bin\nmake.exe" debug
> 1>Microsoft (R) Program Maintenance Utility Version 9.00.21022.08
> 1>Copyright (C) Microsoft Corporation. Tous droits rÚservÚs.
> 1>NMAKE : fatal error U1073: incapable d'obtenir 'src\\Makefile'
> 1>Stop.
> 1>NMAKE : fatal error U1077: 'cd'á: code retour '0x2'
> 1>Stop.
> 1>Project : error PRJ0019: Un outil a retourné un code d'erreur à partir de
> "Actions de projet Makefile en cours"
> 1>Le journal de génération a été enregistré à l'emplacement
> "file://c:\devel\qgit\qgit4\Debug\BuildLog.htm"
> 1>qgit - 3 erreur(s), 0 avertissement(s)
> ========== Génération : 0 a réussi, 1 a échoué, 0 mis à jour, 0 a été ignoré
> ==========
>
> Idea someone?
>
have you tried to setup MSVC for custom build ? and pass proper
comamnd line with nmake ?
Marco
^ permalink raw reply
* Re: [QGit bug] git user settings not retrieved when launched for Windows explorer
From: Marco Costalba @ 2008-10-07 11:10 UTC (permalink / raw)
To: Abdelrazak Younes; +Cc: Git Mailing List
In-Reply-To: <48EB10C8.4070009@lyx.org>
On Tue, Oct 7, 2008 at 9:33 AM, Abdelrazak Younes <younes@lyx.org> wrote:
> Dear Marco,
>
> When I double click on qgit.exe, the user name and email are not shown in
> the user settings (for any of the 3 combo values). But if I run qgit from
> the commandline at the mysysgit bash prompt, the boxes are properly filled.
> I would like to debug it but, as I reported last week, the MSVC project
> doesn't work for me.
>
Sound like a problem of startup directory: on the command line you
start from the right directory...when you double click on which repo
qgit is open ?
Marco
^ permalink raw reply
* Different svn-id URLs in history
From: Knut Eldhuset @ 2008-10-07 10:58 UTC (permalink / raw)
To: git
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
If i checkout the first version, I get a working copy that has the
folder "some_folder" in it. If I checkout the latter version, I get a
working copy with the contents of the folder "src". Why is this? I
thought I always was supposed to get a wc with the whole tree.
Regards,
Knut Eldhuset
^ permalink raw reply
* Re: [PATCH] gitweb: refactor input parameters parse/validation
From: Jakub Narebski @ 2008-10-07 10:57 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Shawn O. Pearce, Matthias Lederhofer
In-Reply-To: <1223054356-17643-1-git-send-email-giuseppe.bilotta@gmail.com>
On Fri, 3 Oct 2008, Giuseppe Bilotta wrote:
> 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 (e.g. command-line support).
Looks good, beside double validation of parameters taken from path_info
(once in evaluate_path_info(), and once when setting 'action' variables).
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
> ---
>
> As recommended by Jakub, I reworked the input parameter collection refactoring
> into a separate patch preluding to rather than intermixed with the PATH_INFO
> enhancement work.
Thanks.
> gitweb/gitweb.perl | 304 +++++++++++++++++++++++++++++-----------------------
> 1 files changed, 171 insertions(+), 133 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 83f810a..329f789 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$,,;
> }
I think we could have left it as it was, i.e. have $path_info be
a local variable. Unless there is something I don't see.
[...]
> +# input parameters are stored with the long parameter name as key, so we need
> +# the name -> CGI key mapping here. This will also be used in the href
> +# subroutine to convert parameters to their CGI equivalent.
Actually href() subroutine would be called many times, while parsing of
input params happens only once; that is why it is longname => shortname
hash, and not the reverse (shortname => longname). Also it does not
result in loss of performance as we parse all input params anyway.
This explanation might be obvious, or could be put in comment
(increasing comment to code count ;-))
> +my @cgi_param_mapping = (
> +my %cgi_param_mapping = @cgi_param_mapping;
> +my %actions = (
Perhaps %allowed_options should also be there, to have everything about
input params in single place... or perhaps not...
> +# 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)];
I would personally use "[ $cgi->param($symbol) ]" instead for better
(IMVHO) visibility, but this is just a matter of taste.
> + } else {
> + $input_params{$name} = $cgi->param($symbol);
> + }
> +}
Nice. I guess that you have checked that you caught all
$cgi->param(...) calls, and there aren't any beside those above...
Now we don't have mdiff, following code movement; tool which was at
beginnings of content movement detection in early days of git-blame.
Therefore I have moved the original code, to easier check the changes
(separating them from code movement).
> -# 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();
> +# now read PATH_INFO and update the parameter list for missing parameters
> +sub evaluate_path_info {
> + return if defined $input_params{'project'};
I was 'my $path_info = $ENV{"PATH_INFO"};' there, when $path_info
wasn't global variable. Any advantages to having it global?
(This is just a minor thing, not worth resending patch over, I think).
> + return if !$path_info;
> + $path_info =~ s,^/+,,;
> + return if !$path_info;
> +
Nice adding lines to separate parts of code.
> + # find which part of PATH_INFO is project
> + my $project = $path_info;
Hmmm... now $project is local (lexically) here.
> + $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).
> + 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/*,,;
Hmmm... I wonder if it is good idea. It was done in commit 645927c
(gitweb: fix warnings in PATH_INFO code and add export_ok/strict_export)
by Matthias Lederhofer, but I don't see why we do not remove project
from path_info if action is set. But this is belongs probably to
independent code cleanup (if it is needed), so don't worry about that.
Perhaps it would be good to add empty line here before beginning of
'hash' and 'hash_base:file_name' handling.
> + 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
Additionally git_get_type(<extended sha1>) is additional call to git
(additional fork) currently; that might change with gitweb caching code,
which uses permanent connection to 'git cat-file --batch/--batch-check'
for that.
> + $pathname =~ s,^/+,,;
> + if (!$pathname || substr($pathname, -1) eq "/") {
> + $input_params{'action'} = "tree";
> + $pathname =~ s,/$,,;
> + } else {
> + $input_params{'action'} = "blob_plain";
> + }
> + $input_params{'hash_base'} ||= validate_refname($refname);
> + $input_params{'file_name'} ||= validate_pathname($pathname);
> + } elsif (defined $refname) {
> + # we got "project.git/branch"
> + $input_params{'action'} = "shortlog";
> + $input_params{'hash'} ||= validate_refname($refname);
> + }
> +}
Nice defensive programming with '||=' here for setting %input_params.
[After examining code further]. But I think you do double validation;
see comment below.
> +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");
> }
> }
Hmm... don't you do double validation now? Once in evaluate_path_info,
and once copying to global variables like $action?
Very nice moving param validation for 'a'/'action' parameter to
validate_action() subroutine.
> # 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");
> }
> }
Nice using validate_project() here.
> -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 param was not set.
Thanks for catching that.
> +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");
> }
> }
> @@ -470,23 +587,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]/) {
Nice, almost trivial change.
> @@ -604,35 +646,12 @@ sub href (%) {
[...]
> 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};
> }
> }
> }
Nice cleanup.
> @@ -672,6 +691,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;
> + }
> +}
Nice.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: files missing after converting a cvs repository to git
From: Michael Haggerty @ 2008-10-07 10:46 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <gcfcrg$ubc$1@ger.gmane.org>
Jakub Narebski wrote:
> Andreas Ericsson wrote:
>
>> cvs2svn is apparently quite good at getting even the weirdest history
>> right. Perhaps you can try that and then running "git svn" on the
>> resulting svn repo?
>
> cvs2svn has git output now (I think it is actually fast-import output)
Correct. See http://cvs2svn.tigris.org/cvs2git.html for more info. I
suggest using the trunk version of cvs2svn for conversions to git.
Please note, however, that cvs2svn can only handle one-time conversions
(i.e., not tracking a live CVS repository incrementally).
Michael
^ permalink raw reply
* Re: files missing after converting a cvs repository to git
From: Jakub Narebski @ 2008-10-07 10:15 UTC (permalink / raw)
To: git
In-Reply-To: <48EAFCEF.8030907@op5.se>
Andreas Ericsson wrote:
> cvs2svn is apparently quite good at getting even the weirdest history
> right. Perhaps you can try that and then running "git svn" on the
> resulting svn repo?
cvs2svn has git output now (I think it is actually fast-import output)
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH RFC] rebase--interactive: if preserving merges, use first-parent to limit what is shown.
From: Avi Kivity @ 2008-10-07 9:57 UTC (permalink / raw)
To: Stephen Haberman; +Cc: git
In-Reply-To: <20081006212021.04ba9214.stephen@exigencecorp.com>
Stephen Haberman wrote:
> However, t3404 makes a good point that if the right hand of the merge
> has parents that are going to get rebased, the right hand side does
> need to be included/shown/rewritten.
>
>
But, won't those commits get linearized? Won't git rebase pick the
commits into the left-hand side of the merge instead of into the right
hand side?
If git rebase is to handle nonlinear history, it needs much more
expressive commands; not only saying which commit to pick, but also what
the commit's parents shall be.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [msysGit] Re: [FYI][PATCH] Customizing the WinGit installer
From: Petr Baudis @ 2008-10-07 9:28 UTC (permalink / raw)
To: Linus Torvalds
Cc: Dmitry Potapov, Johannes Schindelin, Jakub Narebski, msysgit, git
In-Reply-To: <alpine.LFD.2.00.0810061909260.3208@nehalem.linux-foundation.org>
On Mon, Oct 06, 2008 at 07:10:37PM -0700, Linus Torvalds wrote:
> On Tue, 7 Oct 2008, Dmitry Potapov wrote:
> >
> > It looks like you have changed your opinion since what you wrote half
> > a year ago.
>
> Back then, nobody had really complained and sent in a patch to make it
> optional.
>
> That changes things. Once some user actually complains, and sends in a
> fix to make the whole dialog optional, I don't see why anybody would ever
> argue against such a patch being accepted.
Note that as mentioned in the original mail, my patch was not meant
for application upstream, just as an example for others who would like
to customize the Git installer for a particular environment. We wanted
to make Git installation/usage as simple as possible, reducing any
unnecessary steps we could - and this was an easy one.
I don't think the idea of showing GPL during installation makes
a lot of sense on its own, but I don't care much either and clicking
through licences and EULAs in wizards is a fact of life on Windows,
sadly. At least it doesn't require you to scroll down through the
licence as IIRC OpenOffice or GIMP or a similar beast did.
--
Petr "Pasky" Baudis
People who take cold baths never have rheumatism, but they have
cold baths.
^ permalink raw reply
* Re: [msysGit] [FYI][PATCH] Customizing the WinGit installer
From: Heikki Orsila @ 2008-10-07 7:46 UTC (permalink / raw)
To: Dmitry Potapov
Cc: Linus Torvalds, Johannes Schindelin, Jakub Narebski, Petr Baudis,
msysgit, git
In-Reply-To: <20081007030824.GW21650@dpotapov.dyndns.org>
On Tue, Oct 07, 2008 at 07:08:24AM +0400, Dmitry Potapov wrote:
> On Mon, Oct 06, 2008 at 07:10:37PM -0700, Linus Torvalds wrote:
> >
> > That changes things. Once some user actually complains, and sends in a
> > fix to make the whole dialog optional, I don't see why anybody would ever
> > argue against such a patch being accepted.
>
> First, he did not complain. He did not even mention that in the commit
> message.
What does that matter? People are complaining now.
> He mentioning some other things like removing release notes,
> but not the license. Second, I would expect that any change that goes
> against the previous achieved agreement may deserve some discussion,
> and not blindly accepted just because the user sent a patch.
Are you thinking this is some kind of decision by committee
organization? NO. Patches are picked up by maintainers. Anyone can
comment on the patches as they are published.
> Okay, I
> don't really care whether the installer shows the license or not...
Then why argue about it? I care very much.
--
Heikki Orsila
heikki.orsila@iki.fi
http://www.iki.fi/shd
^ 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