* Re: What's cooking in git/spearce.git (Oct 2008, #01; Mon, 06)
From: Shawn O. Pearce @ 2008-10-07 14:50 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20081006210303.GA30812@coredump.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> On Mon, Oct 06, 2008 at 09:59:43AM -0700, Shawn O. Pearce wrote:
>
> > * jk/diff-convfilter (Sun Oct 5 17:43:45 2008 -0400) 4 commits
> > - diff: add filter for converting binary to text
> > - diff: introduce diff.<driver>.binary
> > - diff: unify external diff and funcname parsing code
> > - t4012: use test_cmp instead of cmp
> >
> > A general cleanup on how diff drivers are implemented. Its still
> > missing documentation updates and tests but doesn't break anything
> > current as far as I can tell. It needs more review before it can
> > be slated for 'next'.
>
> I should note, too, that this is in direct competition with Matthieu
> Moy's "Implementation of a textconv filter for easy custom diff" posted
> about a week ago. So if you are reviewing this series, please review
> both and decide which you think is more sensible.
To be clear, Jeff's series is in pu because it seems reasonable on
the surface and applied cleanly to my master branch. Matthieu's
branch didn't apply cleanly, and I didn't really have the time to
figure out why and hand fix it.
So my carrying of Jeff's series and not Matthieu's is not an
endorsement one way or the other. It was simply a matter of trying
to help the topic get exposure with the least amount of effort on
my part.
--
Shawn.
^ permalink raw reply
* Re: GitTogether topics status (4th of October)
From: Shawn O. Pearce @ 2008-10-07 14:46 UTC (permalink / raw)
To: Jeff King
Cc: Christian Couder, git, Junio C Hamano, Scott Chacon, Sam Vilain,
Petr Baudis
In-Reply-To: <20081007031509.GA6031@coredump.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> I just added two proposed half-hour meetings, both of which I intend to
> be a few minutes of me talking followed by group discussion. The topics
> are:
>
> 1. Helping new developers join the git community
Oh, this is a good idea. Yesterday I myself had trouble with
a new contributor not being familiar with the patching process.
Partly also my fault of still being a green maintainer. ;-)
> 2. What needs refactoring?
>
> I occasionally run up against parts of the code that just make my
> eyes bleed everytime I touch them. I think we've made significant
> progress in maintanability and bug-avoidance with things like the
> strbuf library, refactoring of remote and transport handling, etc.
> What areas might still benefit from such refactoring?
Also a good idea. I imagine Junio may have some interest in this.
I certainly do. Some of the code is just bloodly aweful to work
with. I guess those are the parts that make your eyes bleed.
--
Shawn.
^ permalink raw reply
* Re: Git pager woes
From: Matthieu Moy @ 2008-10-07 14:30 UTC (permalink / raw)
To: J.R. Mauro; +Cc: git
In-Reply-To: <3aaafc130810070643m352ea2ufa1069dc149f0d9e@mail.gmail.com>
"J.R. Mauro" <jrm8005@gmail.com> writes:
> Git doesn't set special options to it's pager command if the LESS
> environment variable is set.
Yes, this is by design: if you customized less, git obeys the
configuration you've set. Otherwise, it takes a default wich is more
appropriate to git that what "less" does without $LESS set.
That policy isn't perfect, but I think any other would be worse: I
wouldn'l like git to change my configuration if I did set $LESS
myself, and I also prefer git's default to LESS default when it comes
to paging git commands (but I like less's default for other uses, for
example, I like the man page to disapear when I close it).
--
Matthieu
^ permalink raw reply
* Re: [PATCH] gitweb: refactor input parameters parse/validation
From: Jakub Narebski @ 2008-10-07 14:39 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Shawn O. Pearce
In-Reply-To: <cb7bb73a0810070542v4c8a9820x4d91ea20597ddf01@mail.gmail.com>
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...
>>> + $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.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: GitTogether topics status (4th of October)
From: Shawn O. Pearce @ 2008-10-07 14:38 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Jeff King, Christian Couder, git, Junio C Hamano, Scott Chacon,
Sam Vilain, Petr Baudis
In-Reply-To: <alpine.LFD.2.00.0810062343000.3045@xanadu.home>
Nicolas Pitre <nico@cam.org> wrote:
> On Mon, 6 Oct 2008, Jeff King wrote:
>
> > 2. What needs refactoring?
> >
> > I occasionally run up against parts of the code that just make my
> > eyes bleed everytime I touch them. I think we've made significant
> > progress in maintanability and bug-avoidance with things like the
> > strbuf library, refactoring of remote and transport handling, etc.
> > What areas might still benefit from such refactoring?
>
> Tree object walking and commit object parsing. This is what's holding
> pack v4 performances back. But I think that Shawn will cover this
> already (I won't be there but I sent my thoughts about this to him).
Yup. A huge part of the pack v4 talk is going to be the parsing
code. Maybe 10 minutes of it will give the high level overview
of how pack v4 is organized, to explain why the parsing code is
a problem. :)
--
Shawn.
^ permalink raw reply
* Re: [PATCH RFC] rebase--interactive: if preserving merges, use first-parent to limit what is shown.
From: Shawn O. Pearce @ 2008-10-07 14:38 UTC (permalink / raw)
To: Stephen Haberman; +Cc: Avi Kivity, git
In-Reply-To: <20081007013654.274e5cf6.stephen@exigencecorp.com>
Stephen Haberman <stephen@exigencecorp.com> wrote:
> However, lest I burn my "PATCH v2" opportunity, I'm holding off on
> posting the updated patch. It works and passes tests but I'm sure I'll
> tinker with it some more over the next few days. It will also likely
> conflict with my pu sh/maint-rebase3 patch, so I don't know whether to
> base it on top of that one or not (guessing not).
When a patch series is in `pu` it can be rebased/replaced/amended
at any time. That's why I parked it there. The pu branch rewinds
and is rebuilt on a daily basis. Any commits not yet merged into
maint, master or next are automatically rebased onto the latest
maint or master branch and get merged into that day's pu.
So don't hold back on posting patches. Folks expect to see
patches on this list; talking is less productive than posting code.
Showing code that purports to solve a problem, or that at least
displays a problem concretely is worthy of discussion.
And don't worry about replacing what is currently in pu. Its easily
done by the maintainer. However don't expect daily updates to a
topic in pu. Junio (and I) just don't have the bandwidth to keep
replacing patches every day.
--
Shawn.
^ permalink raw reply
* [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
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