* 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
* 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: [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 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
* [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: 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
* 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: [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: 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 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: [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: 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
* [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: [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
* 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: 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
* [PATCH] Clarify that "git log x.c y.h" lists commits that touch either file
From: Abhijit Menon-Sen @ 2008-07-26 16:50 UTC (permalink / raw)
To: git; +Cc: gitster
Signed-off-by: Abhijit Menon-Sen <ams@toroid.org>
---
Documentation/git-log.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
index 5a58d5b..05cbac5 100644
--- a/Documentation/git-log.txt
+++ b/Documentation/git-log.txt
@@ -58,7 +58,7 @@ include::diff-options.txt[]
its size is not included.
<paths>...::
- Show only commits that affect the specified paths.
+ Show only commits that affect any of the specified paths.
include::rev-list-options.txt[]
--
1.6.0.rc0.43.g2aa74
^ permalink raw reply related
* Re: [PATCH] rev-parse: Add support for the ^! and ^@ syntax
From: Björn Steinbrink @ 2008-07-26 16:54 UTC (permalink / raw)
To: git; +Cc: Christian Couder, Junio C Hamano
In-Reply-To: <20080726163756.GA25103@atjola.homenet>
On 2008.07.26 18:37:56 +0200, Björn Steinbrink wrote:
> 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>
> ---
Ah crap, forgot to say that I wrote this because I wanted gitk to
support the ^! syntax and that uses rev-parse to parse its revision
arguments. My use-case with gitk is to quickly verify a bunch of grafts
I used to fixup the history in a git-svn repo.
Björn
^ permalink raw reply
* Re: [PATCH 7/7] builtin-merge: avoid non-strategy git-merge commands in error message
From: Johannes Schindelin @ 2008-07-26 17:01 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20080726160022.GM32057@genesis.frugalware.org>
Hi,
On Sat, 26 Jul 2008, Miklos Vajna wrote:
> 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.
What I meant is: if you change the strcmp to strncmp because one of the
both strings is not supposed to be NUL terminated, you still want to make
sure that one is not a strict prefix of the other.
Ciao,
Dscho
^ permalink raw reply
* Re: git sequencer prototype
From: Sverre Rabbelier @ 2008-07-26 17:01 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Stephan Beyer, git, Christian Couder, Daniel Barkalow
In-Reply-To: <alpine.DEB.1.00.0807261617010.26810@eeepc-johanness>
On Sat, Jul 26, 2008 at 16:19, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Why is it no issue for the builtin? Is it so much different from the
> prototype?
Because it's blazing fast :P.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: git-scm.com
From: Junio C Hamano @ 2008-07-26 17:10 UTC (permalink / raw)
To: Scott Chacon; +Cc: git
In-Reply-To: <d411cc4a0807251759m1d83d7c4w4724806b19f7c02a@mail.gmail.com>
"Scott Chacon" <schacon@gmail.com> writes:
> On Fri, Jul 25, 2008 at 4:47 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> ...
>> I find a tabular list like this list easier to read if it were sorted like
>> this:
>>
>> A D G
>> B E H
>> C F
>> ...
>
> I fixed the things you mentioned here, except for the list ordering,
> only because I kinda think you big contributors should be at the top
> there,...
If you are going to list 30 or so top contributors in 8 rows times 4
columns, because visually the columns are much more distinct than the
rows, it makes the result look more sorted. This is the same reasoning
hwo "git help --all" was fixed with 112d0ba (Make "git help" sort git
commands in columns, 2005-12-18).
By the way, I think this shows another issue with the "rest of us" list in
the lower half.
I have a mild suspicion that sorting that list in alphabetical order may
actually make it much better. It all depends on the purpose of that list,
though.
The purpose of the list would most likely not to find somebody with high
activity to contact for help (you would use the top list that is sorted by
the commit count for that kind of thing). It would primarily be to give
credit to everybody, and perhaps so that people on the contributor list
can point at their own name and say "I helped them", or find somebody else
they happen to know in the list.
When a contributor used to have 8 commits and then adds 2 commits, that
would move the name in the list by a dozen places or so with the current
set of contributors. It would be much easier to locate one's own name
among a huge list if the names are alphabetically sorted, not by commit
count. When more people start to contribute, your name does not move so
drastically. If you are Adam, you are likely to find yourself near the
beginning of the list, if you are Scott, you are likely to find yourself
near one fourth from the end of the list.
And for the "giving credit" purpose, I do not think truncating the list at
5 commits or less threshold, as suggested earlier and already done, makes
much sense, either.
^ permalink raw reply
* [PATCH] builtin-merge: avoid non-strategy git-merge commands in error message
From: Miklos Vajna @ 2008-07-26 17:12 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807261900180.26810@eeepc-johanness>
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>
---
On Sat, Jul 26, 2008 at 07:01:16PM +0200, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > 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.
>
> What I meant is: if you change the strcmp to strncmp because one of
> the
> both strings is not supposed to be NUL terminated, you still want to
> make
> sure that one is not a strict prefix of the other.
Aah, I forgot about all_strategy[j].name is NUL terminated.
Updated patch below.
builtin-merge.c | 15 ++++++++++++++-
1 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/builtin-merge.c b/builtin-merge.c
index cdbc692..29826b1 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -88,8 +88,21 @@ 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;
+ struct cmdname *ent = main_cmds.names[i];
+ for (j = 0; j < ARRAY_SIZE(all_strategy); j++)
+ if (!strncmp(ent->name, all_strategy[j].name, ent->len)
+ && !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] Set up argv0_path correctly, even when argv[0] is just the basename
From: Junio C Hamano @ 2008-07-26 17:31 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Steffen Prohaska, Johannes Sixt, git
In-Reply-To: <alpine.DEB.1.00.0807261613120.26810@eeepc-johanness>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> When the program 'git' is in the PATH, the argv[0] is set to the basename.
While it may be true, I do not think it matters that we cannot get the
full path _UNLESS_ we are doing the relative "../" business.
> However, argv0_path needs the full path, so add a function to discover the
> program by traversing the PATH manually.
I think unconditionally requiring argv0_path to be set is the root cause
of the bug. Unless we do not fix _that_, we will have to make a needless
call to lookup_program_in_path() even when nobody needs that information,
which is unacceptable.
^ permalink raw reply
* Re: [PATCH] Set up argv0_path correctly, even when argv[0] is just the basename
From: Johannes Schindelin @ 2008-07-26 17:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Steffen Prohaska, Johannes Sixt, git
In-Reply-To: <7vod4kft7d.fsf@gitster.siamese.dyndns.org>
Hi,
On Sat, 26 Jul 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > However, argv0_path needs the full path, so add a function to discover
> > the program by traversing the PATH manually.
>
> I think unconditionally requiring argv0_path to be set is the root cause
> of the bug. Unless we do not fix _that_, we will have to make a
> needless call to lookup_program_in_path() even when nobody needs that
> information, which is unacceptable.
Fair enough. How about having a function called from system_path() which
has a flag so it is run only once, and then calls lookup_program_in_path()
provided that argv0_path contains no slashes _and_ exec_path is relative?
Ciao,
Dscho
^ permalink raw reply
* Re: Mailing lists, was Re: [RFC] Git User's Survey 2008
From: Shawn O. Pearce @ 2008-07-26 17:51 UTC (permalink / raw)
To: Jakub Narebski
Cc: Jing Xue, git, Junio C Hamano, Johannes Schindelin,
Marek Zawirski
In-Reply-To: <m38wvovbh2.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> wrote:
> Jing Xue <jingxue@digizenstudio.com> writes:
> >
> > 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.
What Java based build tools would you like to see Git support in?
(choose zero or more, multiple choice)
Ant, Maven, Hudson, JIRA, other
> 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....
There is an implementation in Ruby, but I'm not sure what its
state is.
--
Shawn.
^ 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