* Re: Official Git Homepage change? Re: git-scm.com
From: Thomas Adam @ 2008-07-26 16:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, Johannes Schindelin, Scott Chacon, git
In-Reply-To: <7v8wvok3f6.fsf@gitster.siamese.dyndns.org>
2008/7/26 Junio C Hamano <gitster@pobox.com>:
> Where does this observation lead us in this "Official" git homepage
> discussion? Perhaps the conclusion would be that there does not have to
> be any _single_ official home? I dunno.
I would disagree. If there is already a sporadic mess of GIT-related
information, not having somewhere "official" to collate and track
development changes in documentation, etc., could be very confusing
indeed. There is no guarantee these so-called "dark-matter" people
would ever get around to updating anything they're currently writing
which would be disasterous.
-- Thomas Adam
^ permalink raw reply
* Re: Mailing lists, was Re: [RFC] Git User's Survey 2008
From: Jakub Narebski @ 2008-07-26 16:47 UTC (permalink / raw)
To: Jing Xue
Cc: git, Shawn O. Pearce, Junio C Hamano, Johannes Schindelin,
Marek Zawirski
In-Reply-To: <20080726155138.GB20695@jabba.hq.digizenstudio.com>
Jing Xue <jingxue@digizenstudio.com> writes:
> On Fri, Jul 25, 2008 at 04:57:07PM -0500, Shawn O. Pearce wrote:
> > Jakub Narebski <jnareb@gmail.com> wrote:
> > >
> > > What question about egit/jgit would you like to have in the survey?
> >
> > I'm not certain what else I would want to ask that is egit/jgit
> > specific.
>
> Just a thought - how about a question polling whether people would be
> interested in build tool wrappers around jgit - ant tasks, maven
> plugins, etc.?
True, there are a lot of tools written in Java, which have or could
have support for Git: Ant tasks, Maven plugins, Hudson rules
(continuous integration), JIRA (bug/issue tracker). Some of them
perhaps could use jgit, although if I understand correctly jgit is not
yet full implementation of Git: it is enough for egit, for local clone
of repository.
I don't have any idea how to formulate such question. I think however
that "hijacking" Git User's Survey to ask a bunch of jgit/egit
questions would be a good idea. (By the way I have though about
asking for feature requests for gitweb...)
I wonder if similar tools like mentioned above, but for the Ruby camp,
like Capistrano, Merb, Gitosis, whatever use git directly, or do they
use Ruby interface (and which interface). I don't think there is
implementation of Git in Ruby... hmmmm....
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [SCRIPT] git-upstream: prints the tracking chain starting at the named ref
From: Petr Baudis @ 2008-07-26 16:39 UTC (permalink / raw)
To: Scott Collins; +Cc: git
In-Reply-To: <26F09105-BFA2-4FA2-86AA-B9E6F9DE3762@slashdot.org>
Hi,
On Sat, Jul 26, 2008 at 10:44:29AM -0400, Scott Collins wrote:
> Here's a script I've sort of `grown' over the past few weeks.
>
> I use it to quickly see where a tracking branch stands with respect to
> upstream refs _without_ actually fetching or even switching to the tracking
> branch. This may not be useful for everyones' work-flows; but I find it
> handy. I'm posting because it may be of use to others (and feedback, if
> any, can only improve it).
I wonder why is it a problem to fetch first in your workflow? If there
is nothing for a fetch, git-upstream is going to be as fast as git fetch
&& git branch, if there is something for a fetch, you probably want to
fetch anyway if you're running this script.
Note that in very recent Git trees, git branch -v will show some
tracking information, however it could use quite some improvement (print
something even if the branch equals the remote branch, print the
ahead/behind combination in case the branch does not fast-forward) -
maybe it might be more effective to enhance that instead?
--
Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name. -- Ken Thompson and Dennis M. Ritchie
^ permalink raw reply
* [PATCH] rev-parse: Add support for the ^! and ^@ syntax
From: Björn Steinbrink @ 2008-07-26 16:37 UTC (permalink / raw)
To: git; +Cc: Christian Couder, Junio C Hamano
Those shorthands are explained in the rev-parse documentation but were not
actually supported by rev-parse itself.
Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
---
builtin-rev-parse.c | 32 ++++++++++++++++++++++++++++++++
t/t6101-rev-parse-parents.sh | 2 ++
2 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/builtin-rev-parse.c b/builtin-rev-parse.c
index aa71f4a..9aa049e 100644
--- a/builtin-rev-parse.c
+++ b/builtin-rev-parse.c
@@ -241,6 +241,36 @@ static int try_difference(const char *arg)
return 0;
}
+static int try_parent_shorthands(const char *arg)
+{
+ char *dotdot;
+ unsigned char sha1[20];
+ struct commit *commit;
+ struct commit_list *parents;
+ int parents_only;
+
+ if ((dotdot = strstr(arg, "^!")))
+ parents_only = 0;
+ else if ((dotdot = strstr(arg, "^@")))
+ parents_only = 1;
+
+ if (!dotdot || dotdot[2])
+ return 0;
+
+ *dotdot = 0;
+ if (get_sha1(arg, sha1))
+ return 0;
+
+ if (!parents_only)
+ show_rev(NORMAL, sha1, arg);
+ commit = lookup_commit_reference(sha1);
+ for (parents = commit->parents; parents; parents = parents->next)
+ show_rev(parents_only ? NORMAL : REVERSED,
+ parents->item->object.sha1, arg);
+
+ return 1;
+}
+
static int parseopt_dump(const struct option *o, const char *arg, int unset)
{
struct strbuf *parsed = o->value;
@@ -573,6 +603,8 @@ int cmd_rev_parse(int argc, const char **argv, const char *prefix)
/* Not a flag argument */
if (try_difference(arg))
continue;
+ if (try_parent_shorthands(arg))
+ continue;
name = arg;
type = NORMAL;
if (*arg == '^') {
diff --git a/t/t6101-rev-parse-parents.sh b/t/t6101-rev-parse-parents.sh
index efc8313..919552a 100755
--- a/t/t6101-rev-parse-parents.sh
+++ b/t/t6101-rev-parse-parents.sh
@@ -28,6 +28,8 @@ test_expect_success 'final^1^2 != final^1^1' "test $(git rev-parse final^1^2) !=
test_expect_success 'final^1^3 not valid' "if git rev-parse --verify final^1^3; then false; else :; fi"
test_expect_success '--verify start2^1' 'test_must_fail git rev-parse --verify start2^1'
test_expect_success '--verify start2^0' 'git rev-parse --verify start2^0'
+test_expect_success 'final^1^@ = final^1^1 final^1^2' "test \"$(git rev-parse final^1^@)\" = \"$(git rev-parse final^1^1 final^1^2)\""
+test_expect_success 'final^1^! = final^1 ^final^1^1 ^final^1^2' "test \"$(git rev-parse final^1^\!)\" = \"$(git rev-parse final^1 ^final^1^1 ^final^1^2)\""
test_expect_success 'repack for next test' 'git repack -a -d'
test_expect_success 'short SHA-1 works' '
--
1.6.0.rc0.79.gb0320.dirty
^ permalink raw reply related
* Re: Official Git Homepage change? Re: git-scm.com
From: Junio C Hamano @ 2008-07-26 16:37 UTC (permalink / raw)
To: Petr Baudis; +Cc: Johannes Schindelin, Scott Chacon, git
In-Reply-To: <20080726144040.GZ32184@machine.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> I don't know if this should have any immediate effect on how we
> develop Git etc., but I think it is good to be aware of the fact that
> silently, huge amount of "dark mass" Git projects is accumulating and
> that Git is making headways in areas many of us were little aware of.
The developer community and "dark matter" community are totally separate
entities that do not interact with each other very much, and they will go
their separate ways? I think it is inevitable for any project once it
becomes popular enough.
Where does this observation lead us in this "Official" git homepage
discussion? Perhaps the conclusion would be that there does not have to
be any _single_ official home? I dunno.
^ permalink raw reply
* Re: [PATCH] Modify mingw_main() workaround to avoid link errors
From: Steffen Prohaska @ 2008-07-26 16:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Johannes Sixt, git, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0807261515290.26810@eeepc-johanness>
On Jul 26, 2008, at 3:17 PM, Johannes Schindelin wrote:
> On Sat, 26 Jul 2008, Steffen Prohaska wrote:
>
>> -#define main(c,v) main(int argc, const char **argv) \
>> +#define main(c,v) dummy_decl_mingw_main(); \
>
> What is this dummy_*() statement supposed to do?
Avoid compile errors. The original statement is
int main( ...
But we want
static int mingw_main( ...
So we need to first get rid of the original int, before
we can start the static decl. We get rid by completing
the original int with the dummy_decl_mingw_main(); to a
full function decl.
Steffen
^ permalink raw reply
* Re: [PATCH 7/7] builtin-merge: avoid non-strategy git-merge commands in error message
From: Miklos Vajna @ 2008-07-26 16:00 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807261737260.26810@eeepc-johanness>
[-- Attachment #1: Type: text/plain, Size: 725 bytes --]
On Sat, Jul 26, 2008 at 05:38:55PM +0200, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > - if (!strcmp(main_cmds.names[i]->name, all_strategy[j].name))
> > + if (!strncmp(ent->name, all_strategy[j].name, ent->len))
>
> Oops... that is not what I meant. You'd have to check if
> !all_strategy[j].name[ent->len], too...
Hmm. So let's say ent->name is "ours.exe", ent->len is set to 4.
Then !strncmp(ent->name, all_strategy[j].name, ent->len) will be true,
and the command will not be added to the exclude list.
However, if I check for !all_strategy[j].name[ent->len], that will be
false, so 'ours' will be excluded from the available strategy list.
Have I missed something?
Thanks.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Mailing lists, was Re: [RFC] Git User's Survey 2008
From: Jing Xue @ 2008-07-26 15:51 UTC (permalink / raw)
To: git
In-Reply-To: <20080725215707.GC23202@spearce.org>
On Fri, Jul 25, 2008 at 04:57:07PM -0500, Shawn O. Pearce wrote:
> Jakub Narebski <jnareb@gmail.com> wrote:
> > What question about egit/jgit would you like to have in the survey?
>
> I'm not certain what else I would want to ask that is egit/jgit
> specific.
Just a thought - how about a question polling whether people would be
interested in build tool wrappers around jgit - ant tasks, maven
plugins, etc.?
Cheers.
--
Jing Xue
^ permalink raw reply
* Re: [PATCH] Set up argv0_path correctly, even when argv[0] is just the basename
From: Rene Herman @ 2008-07-26 15:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Steffen Prohaska, Johannes Sixt, git, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0807261732500.26810@eeepc-johanness>
On 26-07-08 17:35, Johannes Schindelin wrote:
> And it is totally bogus to think about the complicated issues when
> the "weakest link of the chain" is much easier to exploit.
/me tips hat and unsubscribes again.
Rene.
^ permalink raw reply
* Re: git-scm.com
From: Wincent Colaiuta @ 2008-07-26 15:48 UTC (permalink / raw)
To: Scott Chacon; +Cc: david, Petr Baudis, Patrick Aljord, git list
In-Reply-To: <d411cc4a0807252230v76670d3cp2205e40826acc6e2@mail.gmail.com>
El 26/7/2008, a las 7:30, Scott Chacon escribió:
> However, that being said, it's going to be difficult to have Github
> projects not dominate the list a bit. The fact is that it hosts far,
> far more projects than any other single hosting service. Just in
> fully public projects, the current stats (from the website pages) are
> something like this:
>
> kernel.org : 475
> repo.or.cz : 1,553
> gitorious : 780
> github : 10,560
>
> It hosts far more than that if you include private projects, too. So,
> if we want to choose totally randomly, it's going to be at least a 5:1
> ratio between github projects and all other public hosting providers.
I think those numbers are pretty meaningless seeing as GitHub
encourages people to publish "forks" of other projects. Rails, for
example, has about 270 forks at the time of writing. If I scan the
list of popular projects I see fork counts like 129, 105, 78 and 78
(again). Are all the forks counted in that figure of 10,560 that you
count? How many "real" projects are hosted there?
I'd like to see the "official" Git homepage as distanced as possible
from GitHub. They've taken Git (free as in speech, free as in beer)
and built a closed-source commercial product on top of it -- curiously
for something which you can do for free yourself anyway -- and as far
as I can tell from observing this mailing list and watching the
commits going into git.git, haven't ever contributed _anything_ back
to the community. At least within the niche that is the Ruby/Rails
community, GitHub has basically done a hijack job and managed to
become synonymous with Git, supplanting it, and it's a trend that I
wouldn't like to see continue.
Just my personal opinion, but GitHub doesn't provoke any warm fuzzy
feelings here. Quite the contrary. I actively dislike it.
Cheers,
Wincent
^ permalink raw reply
* Re: Official Git Homepage change? Re: git-scm.com
From: Jakub Narebski @ 2008-07-26 15:39 UTC (permalink / raw)
To: Scott Chacon; +Cc: git
In-Reply-To: <d411cc4a0807260832g21fc9a66yd5ccc370699993fd@mail.gmail.com>
On Sat, 26 July 2008, Scott Chacon wrote:
> On Sat, Jul 26, 2008 at 8:21 AM, Jakub Narebski <jnareb@gmail.com> wrote:
>> Rene Herman <rene.herman@keyaccess.nl> writes:
>>> On 26-07-08 09:27, Scott Chacon wrote:
>>>
>>>> Perhaps it would be useful to split the mailing list into
>>>> core/contrib and support lists? [...]
>>>
>>> A git-user list would be welcomed at least by me. [...]
>>
>> Well, there _is_ separate Git Users Group at Google Groups
>> http://groups.google.com/group/git-users
>> nntp://news.gmane.org/gmane.comp.version-control.git.user
It is mentioned at http://git.or.cz/gitwiki/GitCommunity at the end
of the wiki page.
> Perhaps I should link to that on git-scm as well / instead?
"As well" I can agree with. "Instead" I'm against that.
Git mailing list doesn't require subscription, and allow sending
emails using Usenet/news reader from GMane NNTP interface/gateway.
Not so with Google Group.
--
Jakub Narebski
Poland
^ permalink raw reply
* [SCRIPT] git-upstream: prints the tracking chain starting at the named ref
From: Scott Collins @ 2008-07-26 14:44 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1132 bytes --]
Howdy, all.
Here's a script I've sort of `grown' over the past few weeks.
I use it to quickly see where a tracking branch stands with respect to
upstream refs _without_ actually fetching or even switching to the
tracking branch. This may not be useful for everyones' work-flows;
but I find it handy. I'm posting because it may be of use to others
(and feedback, if any, can only improve it).
Example:
$ git upstream -v --abbrev master
ce567d1... master* is behind 'origin/master' by 17 commits, and can
be fast-forwarded.
186458b... origin/master
186458b... master@origin, git://git.kernel.org/pub/scm/git/git.git
For more info, try: git upstream -v -h
It's a perl script and uses Git.pm. Tries to fit into git standard
practices. Supports colors (defaults to color like git branch),
configs. It has a few rough edges, but it's very usable. The tiny
pause before printing a remote tracking branch is ls-remote. I hope
the name doesn't conflict with anything.
I apologize for attaching rather than inserting in-line; but this is a
complete file, not a patch and I also don't trust my mailer :-(
[-- Attachment #2: git-upstream --]
[-- Type: application/octet-stream, Size: 13559 bytes --]
#!/usr/bin/perl
use warnings;
use strict;
use lib (split(/:/, $ENV{GITPERLLIB} || "/usr/local/lib/perl5/site_perl"));
use Git;
my $R = Git->repository();
use AppConfig;
my $A = AppConfig->new({ ERROR => \&usage });
sub version {
my ($dont_exit) = @_;
print "Version 1.0";
unless ( $dont_exit ) {
print "\n";
exit 1;
}
}
sub license {
my ($dont_exit) = @_;
version('don\'t exit!');
print <<END_LICENSE;
, Copyright (c) 26 July 2008 by Scott Collins.
Licensed under the GPL v2 or, at your discretion, a later version of the GPL.
END_LICENSE
exit 1 unless $dont_exit;
}
sub usage {
my ($m1, $m2) = @_;
my $error = $m2 || $m1;
print $error . "\n\n" if $error;
print <<END_USAGE;
Usage:
git upstream ([options] [ref])*
Options:
--help | -h you're soaking in it!
hint: try '--verbose --help'
--verbose | -v print extra information (defaults: abbrev=40, full-names, bold-refs)
--no-verbose ...or not (defaults: abbrev=7, no-full-names, no-bold-refs)
--abbrev[=<n>] number of digits to show in commit ids; 0<=n<=40
0 defers to verbose setting; defaults to 7 if no
value is supplied
--bold-refs | -b distinguish refs from descriptive text
--no-bold-refs ...or not
--color turn color output on
--no-color ...or off
END_USAGE
exit 1 if $error || !$A->verbose();
print <<END_DESCRIPTION;
Description:
Starting at the supplied refs, or else HEAD, prints the tracking chains
(i.e., the ref itself, then the upstream ref it tracks, then the
upstream ref _that_ ref tracks, and so on) from which you can quickly
see if updates are needed or available (without fetching or even
switching to that branch). For refs in your local repo, --verbose will
tell you how far ahead, behind, or diverged.
Configuration:
upstream.verbose boolean (defaults to false)
upstream.boldrefs 'never', 'auto' (the default), or 'always'
'auto' makes refs bold in verbose mode to
distinguish them from descriptive text, but
leaves them plain in non-verbose mode
upstream.fullnames 'never', 'auto' (the default), or 'always'
'auto' prints fully-qualified refnames in
verbose mode, simplified names otherwise
upstream.abbrev integer (defaults to 0, which implies 40 when
--verbose, 7 otherwise)
color.upstream boolean (defaults to color.ui)
color.upstream.<slot> Uses the same color slots and values as git
branch ('current', 'local', 'remote', 'plain'),
and defaults to color.branch.<slot> if not
supplied.
END_DESCRIPTION
$A->color(1);
$A->boldrefs('auto');
setup_output();
my $color = $A->_ref_color();
print <<END_EX1;
Examples:
\$ git upstream -v --abbrev
ce567d1... $color->{current}master$color->{reset}* is behind 'origin/master' by 17 commits, and can be fast-forwarded.
186458b... $color->{remote}origin/master$color->{reset}
186458b... $color->{plain}master\@origin$color->{reset}, git://git.kernel.org/pub/scm/git/git.git
END_EX1
$A->verbose(0);
setup_output();
print <<END_EX2;
\$ git upstream master
ce567d1... $color->{current}master$color->{reset}*
186458b... $color->{remote}origin/master$color->{reset}
186458b... $color->{plain}master\@origin$color->{reset}
END_EX2
$A->verbose(0);
$A->boldrefs('never');
setup_output();
print <<END_EX3;
\$ git upstream --no-bold-refs --verbose origin/master
186458b... $color->{remote}origin/master$color->{reset}
186458b... $color->{plain}master\@origin$color->{reset}, git://git.kernel.org/pub/scm/git/git.git
END_EX3
exit 1;
}
sub get_commit_id {
chomp(my $hash = $R->command_oneline('rev-parse', @_));
return $hash;
}
sub get_fully_qualified_refname {
my ($refname) = @_;
chomp($refname = $R->command_oneline('rev-parse', '--symbolic-full-name', $refname)) if $refname;
return $refname;
}
sub get_simple_refname {
my ($refname) = @_;
$refname =~ s{^((refs/)?(heads|remotes)/|refs/(?=tags/))}{};
return $refname;
}
sub get_ref_kind {
my ($refname) = @_;
$refname = get_fully_qualified_refname($refname) if $refname !~ m{^refs/};
$refname =~ m{^refs/(heads|tags|remotes)/};
return $1 || 'error';
}
my $prev_is_verbose = -1;
my $prev_abbrev = -1;
my $prev_when_bold = '';
my $prev_is_color = -1;
sub setup_output {
my $next_is_verbose = $A->verbose();
my $next_abbrev = $A->abbrev();
my $next_when_bold = $A->boldrefs();
my $next_is_color = $A->color();
my $changed_verbose = ($next_is_verbose != $prev_is_verbose);
my $changed_abbrev = $changed_verbose || ($next_abbrev != $prev_abbrev);
my $changed_bold = $changed_verbose || ($next_when_bold ne $prev_when_bold);
my $changed_color = ($next_is_color ne $prev_is_color);
($prev_is_verbose, $prev_abbrev, $prev_when_bold, $prev_is_color) =
($next_is_verbose, $next_abbrev, $next_when_bold, $next_is_color);
if ( $changed_abbrev ) {
my $abbrev_from_config = $R->config_int('upstream.abbrev');
my $abbrev_from_commandline = $next_abbrev;
if ( $abbrev_from_commandline > 0 ) {
$next_abbrev = $abbrev_from_commandline;
} elsif ( $abbrev_from_commandline == 0 ) {
$next_abbrev = 7;
} elsif ( $abbrev_from_config ) {
$next_abbrev = $abbrev_from_config;
} elsif ( $next_is_verbose ) {
$next_abbrev = 40;
} else {
$next_abbrev = 7;
}
$A->abbrev($next_abbrev);
}
if ( $changed_color || $changed_bold ) {
my $ref_color = $A->_ref_color();
my %default = (
'current' => 'green',
'remote' => 'red',
);
my $get_color = $next_is_color
? sub { my ($slot) = @_;
return $R->get_color("color.upstream.$slot", '')
|| $R->get_color("color.branch.$slot", $default{$slot} || '')
|| ''; }
: sub { return ''; };
my $bold = '';
if ( $next_when_bold eq 'always' || ($next_when_bold eq 'auto' && $next_is_verbose) ) {
$bold = $R->get_color('', 'bold');
}
foreach my $slot ('current', 'local', 'remote', 'plain') {
$ref_color->{$slot} = $get_color->($slot) . $bold;
}
$ref_color->{'reset'} = ($next_is_color || $next_is_verbose)
? $R->get_color('', 'reset')
: '';
}
}
sub print_ref {
my ($ref_info) = @_;
return if !$ref_info->{category} || $ref_info->{category} eq 'error';
my $hash = $ref_info->{commit_id};
my $width = $A->abbrev();
$hash =~ s(^(.{$width}).*$)($1);
print $hash . ($width<40 ? '... ' : ' ');
my $ref_color = $A->_ref_color();
my $label = $ref_info->{label};
my $when_fullnames = $A->fullnames();
if ( $ref_info->{category} ne 'url' && ($when_fullnames eq 'always' || ($when_fullnames eq 'auto' && $A->verbose())) ) {
$label = get_fully_qualified_refname($label);
}
print $ref_color->{$ref_info->{slot}} . $label . $ref_color->{'reset'};
print '*' if $ref_info->{slot} eq 'current';
print $ref_info->{description} if $A->verbose() && $ref_info->{description};
print "\n";
}
sub bad_ref {
my ($refname) = @_;
my %ref = (
category => 'error',
label => $refname || '',
);
return \%ref;
}
# Given the ref you're on now, returns details of the ref it tracks, if any.
sub details_from_refname {
my ($refname) = @_;
return bad_ref() if ! $refname;
my $short_refname = get_simple_refname($refname);
my %ref_info = (
category => get_ref_kind($refname),
slot => 'plain',
local_refname => $refname,
label => $refname,
commit_id => get_commit_id($refname),
);
if ( $ref_info{category} eq 'heads' ) {
$ref_info{slot} = $A->_current_branch() =~ /\b$refname$/ ? 'current' : 'local';
# You gave me a branch; config tells what it tracks, if anything.
my $remote_refname = get_fully_qualified_refname($R->config("branch.$short_refname.merge"));
if ( $remote_refname ) {
my $remote_name = $R->config("branch.$short_refname.remote");
$remote_refname =~ s{^refs/heads}{refs/remotes/$remote_name} if $remote_name ne '.';
$ref_info{remote_name} = $remote_name;
$ref_info{local_refname} = $refname;
$ref_info{remote_refname} = $remote_refname;
if ( $A->verbose() ) {
my @revs = $R->command('rev-list', '--left-right', $refname . '...' . $remote_refname);
my ($ours, $theirs) = (0, 0);
foreach my $elem (@revs) {
++$ours if $elem =~ /^</;
++$theirs if $elem =~ /^>/;
}
$ref_info{ours} = $ours if $ours;
$ref_info{theirs} = $theirs if $theirs;
my $description = '';
my $tracked = get_simple_refname($remote_refname);
if ( $ref_info{ours} && $ref_info{theirs} ) {
$description = " has diverged from '$tracked'. They have, respectively, $ref_info{ours} and $ref_info{theirs} additional commits.";
} elsif ( $ref_info{ours} ) {
$description = " is ahead of '$tracked' by $ref_info{ours} commit" . ($ref_info{ours}==1 ? "" : "s") . ".";
} elsif ( $ref_info{theirs} ) {
$description = " is behind '$tracked' by $ref_info{theirs} commit" . ($ref_info{theirs}==1 ? "" : "s") . ", and can be fast-forwarded.";
}
$ref_info{description} = $description;
}
} else {
$ref_info{description} = " is not a tracking branch.";
}
} elsif ( $ref_info{category} eq 'remotes' ) {
$ref_info{slot} = 'remote';
$short_refname =~ m{^([^/]+)/(.*)$};
$ref_info{remote_name} = $1;
$ref_info{local_refname} = "refs/remotes/$short_refname";
$ref_info{remote_refname} = $2;
my $hash = $R->command_oneline('ls-remote', $1, $2) || '';
$hash =~ s/^(.{40}).*$/$1/;
$ref_info{remote_commit_id} = $hash;
$ref_info{description} = " is behind $ref_info{remote_name}, and can (probably) be fast-forwarded." if $ref_info{commit_id} ne $hash;
}
return \%ref_info;
}
sub details_of_tracked_ref {
my ($ref_info) = @_;
return bad_ref() if ! $ref_info;
my $tracked_ref_info = bad_ref($ref_info->{tracked_ref} || '');
my $remote_refname = $ref_info->{remote_refname};
if ( $ref_info->{category} eq 'remotes' ) {
my $remote_name = $ref_info->{remote_name};
my %info = (
category => 'url',
slot => 'plain',
remote_refname => $remote_refname,
label => "$remote_refname\@$remote_name",
description => ", " . $R->config("remote.$remote_name.url"),
remote_name => $remote_name,
commit_id => $ref_info->{remote_commit_id},
#url => $R->config("remote.$remote_name.url"),
);
$tracked_ref_info = \%info;
} elsif ( $remote_refname ) {
$tracked_ref_info = details_from_refname(get_simple_refname($remote_refname));
}
return $tracked_ref_info;
}
# Decide if $refname identifies a unique local ref that could track something.
# Print $refname, the ref it tracks, the ref that tracks, and so on
sub print_ref_chain {
my ($refname) = @_;
$refname = $A->_current_branch() if !$refname || $refname eq 'HEAD';
die "You are not on a branch.\n" if $refname eq 'HEAD';
my @resolved_names =
grep { /\b$refname$/ }
map { $1 if /'(.+)'/ }
$R->command('for-each-ref', "--format='%(refname)'", 'refs');
my @matching_branches = grep { m(^refs/heads/) } @resolved_names;
my @matching_tags = grep { m(^refs/tags/) } @resolved_names;
my @matching_remotes = grep { m(^refs/remotes/) } @resolved_names;
my $matches = @matching_branches + @matching_tags;
die "The refname '" . $refname . "' is ambiguous.\n"
if $matches>1 || !$matches && @matching_remotes>1;
die "The refname '" . $refname . "' was not found in this repository.\n"
if !$matches && !@matching_remotes;
# As far as I can tell, $refname is a reasonable ref to explore.
setup_output();
my $ref_info = details_from_refname($refname);
while ( $ref_info->{category} ne 'error' ) {
print_ref($ref_info);
last if $ref_info->{category} eq 'url' || ! $ref_info->{remote_refname};
$ref_info = details_of_tracked_ref($ref_info);
}
}
sub set_tristate_from_bool {
my ($state, $name, $value) = @_;
$state->set($name, $value=~/^1$/ ? 'always' : 'never') if $value=~/^0|1$/;
}
sub main {
# command-line actions
$A->define("help|h", { ACTION => sub { usage(); } });
$A->define("version|V", { ACTION => sub { version(); } });
$A->define("license", { ACTION => sub { license(); } });
# command-line options
$A->define("verbose|v!", { DEFAULT => $R->config_bool("upstream.verbose") || 0 });
$A->define("abbrev:i", { DEFAULT => -1, VALIDATE => sub { my ($n, $v) = @_; return 0<=$v && $v<=40; } });
$A->define("color!", { DEFAULT => $R->get_colorbool('color.upstream') });
$A->define("boldrefs|bold-refs|bold|b!", { ACTION => \&set_tristate_from_bool });
$A->define("fullnames|full-names|full!", { ACTION => \&set_tristate_from_bool });
$A->boldrefs($R->config('upstream.boldrefs') || 'auto');
$A->fullnames($R->config('upstream.fullnames') || 'auto');
# application settings that I don't want to see on the command-line
$A->define("_ref_color=s%");
$A->define("_current_branch=s");
$A->_current_branch(get_fully_qualified_refname('HEAD'));
my $refs_processed = 0;
do {
# execute this loop once for each supplied ref, or just once if none (even if no option arguments)
# investigate (and shift-off) any remaining option arguments
$A->getopt(qw{require_order}); # stops at the first non-option
setup_output(); # configure for current color, verbose, abbrev
my $refname;
if ( @ARGV ) {
# we stopped because the next argument _isn't_ an option
$refname = shift @ARGV; # so it must be a ref
} elsif ( ! $refs_processed ) {
# we stopped because we're out of arguments, and we never hit a ref
$refname = get_simple_refname($A->_current_branch()); # so let's use the current branch
}
if ( $refname ) {
print "\n" if $refs_processed++; # blank line between chains
print_ref_chain($refname);
}
} while ( @ARGV ); # if there is anything left on the command-line, do another loop
}
main();
[-- Attachment #3: Type: text/plain, Size: 76 bytes --]
hopefully someone else finds this useful :-)
_____________
Scott Collins
^ permalink raw reply
* Re: [PATCH 7/7] builtin-merge: avoid non-strategy git-merge commands in error message
From: Johannes Schindelin @ 2008-07-26 15:38 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20080726152502.GL32057@genesis.frugalware.org>
Hi,
On Sat, 26 Jul 2008, Miklos Vajna wrote:
> On Sat, Jul 26, 2008 at 05:08:11PM +0200, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > + memset(¬_strategies, 0, sizeof(struct cmdnames));
> > > + for (i = 0; i < main_cmds.cnt; i++) {
> >
> > Looking through all the discovered git commands? Cute... But does
> > that not exclude the commands that are in PATH, starting with
> > git-merge-, even if they are custom strategies?
>
> main_cmds contains only commands in /usr/libexec/git-core, while I guess
> custom strategies are elsewhere in PATH, which commands are in
> other_cmds, not in main_cmds.
Thanks.
> - if (!strcmp(main_cmds.names[i]->name, all_strategy[j].name))
> + if (!strncmp(ent->name, all_strategy[j].name, ent->len))
Oops... that is not what I meant. You'd have to check if
!all_strategy[j].name[ent->len], too...
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Git User's Survey 2008
From: Jakub Narebski @ 2008-07-26 15:34 UTC (permalink / raw)
To: Stephan Beyer; +Cc: Robin Rosenberg, Johannes Schindelin, git
In-Reply-To: <200807241152.29465.jnareb@gmail.com>
On Thu, 24 July 2008, Jakub Narębski wrote:
> On Thu, 24 July 2008, Stephan Beyer wrote:
>> Jakub Narebski wrote:
>>> Dnia środa 23. lipca 2008 16:54, Robin Rosenberg napisał
>>>> onsdagen den 23 juli 2008 15.18.40 skrev Johannes Schindelin:
>>>>> On Wed, 23 Jul 2008, Jakub Narebski wrote:
>>>>>> On Wed, 23 Jul 2008, Johannes Schindelin wrote:
>>>>>>> On Wed, 23 Jul 2008, Jakub Narebski wrote:
>>>>>>>
>>>>>>>> 04. Which programming languages you are proficient with?
>>>>>>>> (The choices include programming languages used by git)
>>>>>>>> (zero or more: multiple choice)
>>>>>>>> - C, shell, Perl, Python, Tcl/Tk
>>>>>>>> + (should we include other languages, like C++, Java, PHP,
>>>>>>>> Ruby,...?)
>> [...]
>
> If we want to provide larger number of programming languages to
> chose from (with "other" as fallback), we could take for example
> top 10 from the TIOBE index, or similar sites:
> http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html (for July 2008)
> http://lui.arbingersys.com/index.html (Language Usage Indicators, Jul 10, 2008)
>
> This would bring 'Visual Basic', and perhaps 'Assembly' and 'Lisp'
> to the list of choices.
Perhaps also consider GitHub's list of most popular languages
http://github.com/blog/99-popular-languages
(as mentioned in Petr 'Pasky' Baudis somewhere in git-scm.com thread)
to take into account git popularity among web developers.
This would add 'ERB' (or is it just subset of 'Ruby' as eRuby
implementation?), and 'Common Lisp' (if 'Common Lisp', then
probably also 'Scheme'/'Guile').
There is always free-form 'other'...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] Set up argv0_path correctly, even when argv[0] is just the basename
From: Johannes Schindelin @ 2008-07-26 15:35 UTC (permalink / raw)
To: Rene Herman; +Cc: Steffen Prohaska, Johannes Sixt, git, Junio C Hamano
In-Reply-To: <488B409D.40709@keyaccess.nl>
Hi,
On Sat, 26 Jul 2008, Rene Herman wrote:
> Adding to the PATH is generally not disallowed by user level security.
> Replacing the GIT binary generally is.
Prepending to the PATH is generally not disallowed either. And that's
just as good as replacing the Git binary.
This issue is totally independent of Git. And it is totally bogus to
think about the complicated issues when the "weakest link of the chain" is
much easier to exploit.
Hth,
Dscho
^ permalink raw reply
* Re: Official Git Homepage change? Re: git-scm.com
From: Scott Chacon @ 2008-07-26 15:32 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3d4l0vfgk.fsf@localhost.localdomain>
On Sat, Jul 26, 2008 at 8:21 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> Rene Herman <rene.herman@keyaccess.nl> writes:
>
>> On 26-07-08 09:27, Scott Chacon wrote:
>>
>> > Perhaps it would be useful to split the mailing list into
>> > core/contrib and support lists? I would be happy to help out
>> > answering questions - a lot of them come directly to me anyhow
>> > because of the gitcasts site and such.
>>
>> A git-user list would be welcomed at least by me. It remains to be
>> seen how useful it would be (and stay) as often the user lists for a
>> project dwinddle a bit but I've subcribed and unsubscribed to this
>> list a number of times now since unless I've a specific question to
>> ask, the list is too busy too just sit around on; I end up deleting
>> all list mail unread every night anyway, so I just unsubcribe again.
>>
>> Maybe a less busy and less implementation focused list could help "me
>> and mine" gradually pick up new tips and tricks. Depends ofcourse on
>> willingness of some of the more proficient to be involved in that list
>> as well...
>
> Well, there _is_ separate Git Users Group at Google Groups
> http://groups.google.com/group/git-users
> nntp://news.gmane.org/gmane.comp.version-control.git.user
>
> --
> Jakub Narebski
> Poland
> ShadeHawk on #git
>
Perhaps I should link to that on git-scm as well / instead?
Scott
^ permalink raw reply
* [PATCH 7/7] builtin-merge: avoid non-strategy git-merge commands in error message
From: Miklos Vajna @ 2008-07-26 15:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <20080726152502.GL32057@genesis.frugalware.org>
If an invalid strategy is supplied, like -s foobar, then git-merge
listed all git-merge-* commands. This is not perfect, since for example
git-merge-index is not a valid strategy.
These are now removed from the output by scanning the list of main
commands; if the git-merge-foo command is listed in the all_strategy
list, then it's shown, otherwise excluded. This does not exclude
commands somewhere else in the PATH, where custom strategies are
expected.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
I just realized I can resend the last patch as the others are unchanged,
so here it is.
builtin-merge.c | 14 +++++++++++++-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/builtin-merge.c b/builtin-merge.c
index cdbc692..b0d1de5 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -88,8 +88,20 @@ static struct strategy *get_strategy(const char *name)
return &all_strategy[i];
if (!is_git_command(name, "git-merge-")) {
+ struct cmdnames not_strategies;
+
+ memset(¬_strategies, 0, sizeof(struct cmdnames));
+ for (i = 0; i < main_cmds.cnt; i++) {
+ int j, found = 0;
+ char *ent = main_cmds.names[i];
+ for (j = 0; j < ARRAY_SIZE(all_strategy); j++)
+ if (!strncmp(ent->name, all_strategy[j].name, ent->len))
+ found = 1;
+ if (!found)
+ add_cmdname(¬_strategies, ent->name, ent->len);
+ }
fprintf(stderr, "Could not find merge strategy '%s'.\n\n", name);
- list_commands("git-merge-", "strategies");
+ list_commands("git-merge-", "strategies", ¬_strategies);
exit(1);
}
--
1.6.0.rc0.14.g95f8.dirty
^ permalink raw reply related
* Re: [PATCH 7/7] builtin-merge: avoid non-strategy git-merge commands in error message
From: Miklos Vajna @ 2008-07-26 15:25 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807261701520.26810@eeepc-johanness>
[-- Attachment #1: Type: text/plain, Size: 2890 bytes --]
On Sat, Jul 26, 2008 at 05:08:11PM +0200, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > + memset(¬_strategies, 0, sizeof(struct cmdnames));
> > + for (i = 0; i < main_cmds.cnt; i++) {
>
> Looking through all the discovered git commands? Cute... But does that
> not exclude the commands that are in PATH, starting with git-merge-, even
> if they are custom strategies?
main_cmds contains only commands in /usr/libexec/git-core, while I guess
custom strategies are elsewhere in PATH, which commands are in
other_cmds, not in main_cmds.
Sample output at me:
$ git merge -s theirss c2
HEAD is now at 1f5e3cc c1
Could not find merge strategy 'theirss'.
available strategies in '/usr/libexec/git-core/'
--------------------------------------------------
octopus ours recursive resolve subtree
strategies available from elsewhere on your $PATH
---------------------------------------------------
theirs
and I have git-merge-theirs in ~/bin (which is in PATH).
>
> > + int j, found = 0;
> > + for (j = 0; j < ARRAY_SIZE(all_strategy); j++)
> > + if (!strcmp(main_cmds.names[i]->name, all_strategy[j].name))
> > + found = 1;
> > + if (!found)
> > + add_cmdname(¬_strategies, main_cmds.names[i]->name, strlen(main_cmds.names[i]->name));
>
> Better have a local variable "name" instead of writing out
> "main_cmds.names[i]->name" all the time...
Fixed.
> Oh, and you assume that the names are NUL-terminated (which I assume is
> not the case in general, as the len member is the only thing that makes
> struct cmdnames different from struct string_list.
I think the purpose of it is different, but the argument is still valie.
That len member is to be able to have ->name contain "foo.exe" while
having len at 3, so that git help -a will avoid the .exe suffixes.
Changed.
(I do not want to resend a full series yet, but I pushed out an amended
patch to repo.or.cz in the 'merge-custom' branch.)
diff --git a/builtin-merge.c b/builtin-merge.c
index 4084e07..b0d1de5 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -93,11 +93,12 @@ static struct strategy *get_strategy(const char *name)
memset(¬_strategies, 0, sizeof(struct cmdnames));
for (i = 0; i < main_cmds.cnt; i++) {
int j, found = 0;
+ char *ent = main_cmds.names[i];
for (j = 0; j < ARRAY_SIZE(all_strategy); j++)
- if (!strcmp(main_cmds.names[i]->name, all_strategy[j].name))
+ if (!strncmp(ent->name, all_strategy[j].name, ent->len))
found = 1;
if (!found)
- add_cmdname(¬_strategies, main_cmds.names[i]->name, strlen(main_cmds.names[i]->name));
+ add_cmdname(¬_strategies, ent->name, ent->len);
}
fprintf(stderr, "Could not find merge strategy '%s'.\n\n", name);
list_commands("git-merge-", "strategies", ¬_strategies);
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply related
* Re: Official Git Homepage change? Re: git-scm.com
From: Jakub Narebski @ 2008-07-26 15:21 UTC (permalink / raw)
To: Rene Herman; +Cc: Scott Chacon, Junio C Hamano, Petr Baudis, git
In-Reply-To: <488B394F.9000300@keyaccess.nl>
Rene Herman <rene.herman@keyaccess.nl> writes:
> On 26-07-08 09:27, Scott Chacon wrote:
>
> > Perhaps it would be useful to split the mailing list into
> > core/contrib and support lists? I would be happy to help out
> > answering questions - a lot of them come directly to me anyhow
> > because of the gitcasts site and such.
>
> A git-user list would be welcomed at least by me. It remains to be
> seen how useful it would be (and stay) as often the user lists for a
> project dwinddle a bit but I've subcribed and unsubscribed to this
> list a number of times now since unless I've a specific question to
> ask, the list is too busy too just sit around on; I end up deleting
> all list mail unread every night anyway, so I just unsubcribe again.
>
> Maybe a less busy and less implementation focused list could help "me
> and mine" gradually pick up new tips and tricks. Depends ofcourse on
> willingness of some of the more proficient to be involved in that list
> as well...
Well, there _is_ separate Git Users Group at Google Groups
http://groups.google.com/group/git-users
nntp://news.gmane.org/gmane.comp.version-control.git.user
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Set up argv0_path correctly, even when argv[0] is just the basename
From: Rene Herman @ 2008-07-26 15:19 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Steffen Prohaska, Johannes Sixt, git, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0807261709090.26810@eeepc-johanness>
On 26-07-08 17:10, Johannes Schindelin wrote:
> Hi,
>
> On Sat, 26 Jul 2008, Rene Herman wrote:
>
>> On 26-07-08 16:14, Johannes Schindelin wrote:
>>
>>> When the program 'git' is in the PATH, the argv[0] is set to the
>>> basename. However, argv0_path needs the full path, so add a function
>>> to discover the program by traversing the PATH manually.
>> While not having read the context for this, this ofcourse sounds like a huge
>> gaping race-condition. If applicable here (as said, did not read context) you
>> generally want to make sure that there's no window that a path could be
>> replaced -- while perhaps not here, that's often the kind of thing that
>> security attacks end up abusing.
>
> Yeah, and that's why you would carefully time your attack just in between
> the command invocation and the discovery of argv[0] in the PATH.
>
> Rather than replacing the 'git' program with an infected version right
> away.
Adding to the PATH is generally not disallowed by user level security.
Replacing the GIT binary generally is.
Sure maybe it's not much of a problem here; as said, I didn't read the
context and am not a GIT person. Just commented on a git-user list when
this was the next message on the list. Though a heads-up might still be
in order. If it wasn't useful -- so be it, but even making a command do
something different than a user expected can have serious implications,
for example in this case for the tree they are working on.
Rene.
^ permalink raw reply
* Re: Official Git Homepage change? Re: git-scm.com
From: Petr Baudis @ 2008-07-26 15:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Scott Chacon, git
In-Reply-To: <7vtzedktmi.fsf@gitster.siamese.dyndns.org>
On Sat, Jul 26, 2008 at 12:11:01AM -0700, Junio C Hamano wrote:
> The people who design the new features and write code should have easy
> access to the issues the users of all levels have with the software and
> the documentation (and what they find useful as well). What I am most
> afraid of is that both "We do not bother the coders" and "We are too busy
> to answer every newbie question" mentalities would lead to a fractured
> community.
The community is already fractured! I think we actually have very tiny
fraction of the user base on the mailing list - the traffic is simply
too massive. After all we chose _our_ convenience over _users'_
convenience in making this tradeoff. Also, as I mentioned in the other
mail, it's not obvious to me whether major part of our community would
be willing to participate in any mailing list at all.
(Note that I don't want to imply that this would be inherently a Bad
Thing. Some feedback still bubbles through and we have ways like Jakub's
Git User Survey as well. Maybe the user community is by now simply too
big to make the direct cross-pollination with developers feasible.)
There was a proposal some time ago for making a web forum for Git; maybe
we were too dismissive to the suggestion. I wonder where *do* these 100k
of registered GitHubbers get their Git support now? :-)
--
Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name. -- Ken Thompson and Dennis M. Ritchie
^ permalink raw reply
* Re: [PATCH] Set up argv0_path correctly, even when argv[0] is just the basename
From: Johannes Schindelin @ 2008-07-26 15:10 UTC (permalink / raw)
To: Rene Herman; +Cc: Steffen Prohaska, Johannes Sixt, git, Junio C Hamano
In-Reply-To: <488B3A97.6000606@keyaccess.nl>
Hi,
On Sat, 26 Jul 2008, Rene Herman wrote:
> On 26-07-08 16:14, Johannes Schindelin wrote:
>
> > When the program 'git' is in the PATH, the argv[0] is set to the
> > basename. However, argv0_path needs the full path, so add a function
> > to discover the program by traversing the PATH manually.
>
> While not having read the context for this, this ofcourse sounds like a huge
> gaping race-condition. If applicable here (as said, did not read context) you
> generally want to make sure that there's no window that a path could be
> replaced -- while perhaps not here, that's often the kind of thing that
> security attacks end up abusing.
Yeah, and that's why you would carefully time your attack just in between
the command invocation and the discovery of argv[0] in the PATH.
Rather than replacing the 'git' program with an infected version right
away.
Giggling,
Dscho
^ permalink raw reply
* Re: [EGIT PATCH] Support linked resources
From: Robin Rosenberg @ 2008-07-26 15:07 UTC (permalink / raw)
To: Richie Vos; +Cc: git
In-Reply-To: <5a27b7b0807232034t564e8d45l9f6e4bc6429cda60@mail.gmail.com>
torsdagen den 24 juli 2008 05.34.06 skrev Richie Vos:
> I have a project that outputs to a linked directory (for example the
> project is in /projects/foo and the project outputs to /projects/bar).
> This was causing egit to throw a bunch of "file is not in working
> path" errors whenever I rebuilt the project or otherwise interacted
> with that linked directory. I tracked it down to GitIndex's add/remove
> being called on these files even though these files are not part of
> the actual index.
>
> It seems like egit shouldn't be trying to interact with the index on
> these files, and after looking at it, I decided the best solution
> would be to realize in the RepositoryMapping that these files do not
> point to a repository.
I'd be inclined to prefer ignoring any non-plain resource, always. Linked
resources are either absolute or relative to a variable. Other than that
there is an analogy to symbolic links. Git manages the link, not its
content (unless handled elsewhere). The link in this case is in the
.project file and thus managed there.
EGit could still managed the resource, but not via the link, but rather at
the place it is located, iff that happens to be in a project managed by Egit.
-- robin
^ permalink raw reply
* Re: [PATCH 7/7] builtin-merge: avoid non-strategy git-merge commands in error message
From: Johannes Schindelin @ 2008-07-26 15:08 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <65a569c389352c5d0500b8c44c28e5572352e6ba.1217037178.git.vmiklos@frugalware.org>
Hi,
On Sat, 26 Jul 2008, Miklos Vajna wrote:
> + memset(¬_strategies, 0, sizeof(struct cmdnames));
> + for (i = 0; i < main_cmds.cnt; i++) {
Looking through all the discovered git commands? Cute... But does that
not exclude the commands that are in PATH, starting with git-merge-, even
if they are custom strategies?
> + int j, found = 0;
> + for (j = 0; j < ARRAY_SIZE(all_strategy); j++)
> + if (!strcmp(main_cmds.names[i]->name, all_strategy[j].name))
> + found = 1;
> + if (!found)
> + add_cmdname(¬_strategies, main_cmds.names[i]->name, strlen(main_cmds.names[i]->name));
Better have a local variable "name" instead of writing out
"main_cmds.names[i]->name" all the time...
Oh, and you assume that the names are NUL-terminated (which I assume is
not the case in general, as the len member is the only thing that makes
struct cmdnames different from struct string_list.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/7] builtin-help: change the current directory back in list_commands_in_dir()
From: Johannes Schindelin @ 2008-07-26 14:58 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <4f2b03391e3f85cf2224f97a2a7765d08707bd73.1217037178.git.vmiklos@frugalware.org>
Hi,
On Sat, 26 Jul 2008, Miklos Vajna wrote:
> That function used to do a chdir() without switching back to the
> original directory. That was not a problem till this function was used
> only inside builtin-help, but once other builtins use it as well, this
> is a problem, for example when the object database path is relative.
I had to work around that in my patch "git wrapper: DWIM mistyped
commands", too :-)
Ciao,
Dscho
^ 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