* Re: [PATCH] Fix update-index --refresh for submodules if stat(2) returns st_size 0
From: Alex Riesen @ 2008-07-22 16:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vbq0qnxyi.fsf@gitster.siamese.dyndns.org>
Junio C Hamano, Tue, Jul 22, 2008 10:07:49 +0200:
> I however have to wonder if you also need to touch the end of
> ce_match_stat_basic() that checks for zero sized cache entry.
I frankly don't know.
^ permalink raw reply
* [PATCH] In perforce, RCS keywords are case-sensitive
From: Daniel Barkalow @ 2008-07-22 16:48 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
At least, this is true in 2007.2, according to the documentation.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
---
A line of perl with the variable $file in a string followed by a different
variable not in the string, for example, doesn't get mangled by p4 and may
therefore appear in a p4 depot.
I don't know if the "old-style keyword expansion" is case-sensitive,
though, so I'm leaving that alone.
contrib/fast-import/git-p4 | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index d8de9f6..1ee612e 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -902,7 +902,7 @@ class P4Sync(Command):
if stat['type'] in ('text+ko', 'unicode+ko', 'binary+ko'):
text = re.sub(r'(?i)\$(Id|Header):[^$]*\$',r'$\1$', text)
elif stat['type'] in ('text+k', 'ktext', 'kxtext', 'unicode+k', 'binary+k'):
- text = re.sub(r'(?i)\$(Id|Header|Author|Date|DateTime|Change|File|Revision):[^$]*\$',r'$\1$', text)
+ text = re.sub(r'\$(Id|Header|Author|Date|DateTime|Change|File|Revision):[^$]*\$',r'$\1$', text)
contents[stat['depotFile']] = text
--
1.5.6.rc2.26.g8c37.dirty
^ permalink raw reply related
* Re: post-receive-hook emailer
From: Vincent Kergonna @ 2008-07-22 16:45 UTC (permalink / raw)
To: Ask Bjørn Hansen; +Cc: git
In-Reply-To: <00AEED4D-BD34-4584-B303-32C5F587EF0F@develooper.com>
> Hi everyone,
>
Hi,
> Anyway - anyone have a mailer that sends diffs and such? :-) Or
> should I just write a wrapper around format-patch and send-email?
> (To handle branches well it gets slightly complicated, quick - or
> maybe I just haven't understood how the post-receive hook works).
Below is a script I use to send diffs for each commit pushed to a
repository. This script should be called from the 'update' hook.
--
Vincent
#!/usr/bin/perl
#
# Tool to send git commit notifications
#
# Copyright 2005 Alexandre Julliard
#
# This program is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License as
# published by the Free Software Foundation; either version 2 of
# the License, or (at your option) any later version.
#
#
# This script is meant to be called from .git/hooks/update.
#
# Usage: git-notify [options] [--] refname old-sha1 new-sha1
#
# -c name Send CIA notifications under specified project name
# -m addr Send mail notifications to specified address
# -n max Set max number of individual mails to send
# -r name Set the git repository name
# -s bytes Set the maximum diff size in bytes (-1 for no limit)
# -u url Set the URL to the gitweb browser
# -x branch Exclude changes to the specified branch from reports
#
use strict;
use open ':utf8';
use Encode 'encode';
use Cwd 'realpath';
binmode STDIN, ':utf8';
binmode STDOUT, ':utf8';
# some parameters you may want to change
# base URL of the gitweb repository browser (can be set with the -u option)
my $gitweb_url = "";
# set this to something that takes "-s"
my $mailer = "/usr/bin/mail";
# default repository name (can be changed with the -r option)
my $repos_name = "";
# Repository owner
my $repos_owner = "";
# max size of diffs in bytes (can be changed with the -s option)
my $max_diff_size = 2500000;
# address for mail notices (can be set with -m option)
my $commitlist_address;
# project name for CIA notices (can be set with -c option)
my $cia_project_name;
# CIA notification address
my $cia_address = "cia\@cia.navi.cx";
# max number of individual notices before falling back to a single global
notice (can be set with -n option)
my $max_individual_notices = 100;
# debug mode
my $debug = 0;
# branches to exclude
my @exclude_list = ();
sub usage()
{
print "Usage: $0 [options] [--] refname old-sha1 new-sha1\n";
print " -c name Send CIA notifications under specified project
name\n";
print " -m addr Send mail notifications to specified address\n";
print " -n max Set max number of individual mails to send\n";
print " -r name Set the git repository name\n";
print " -s bytes Set the maximum diff size in bytes (-1 for no
limit)\n";
print " -u url Set the URL to the gitweb browser\n";
print " -x branch Exclude changes to the specified branch from
reports\n";
print " -o owner Set repository owner (used as a filter on commits)\n";
exit 1;
}
sub xml_escape($)
{
my $str = shift;
$str =~ s/&/&/g;
$str =~ s/</</g;
$str =~ s/>/>/g;
my @chars = unpack "U*", $str;
$str = join "", map { ($_ > 127) ? sprintf "&#%u;", $_ : chr($_); }
@chars;
return $str;
}
# format an integer date + timezone as string
# algorithm taken from git's date.c
sub format_date($$)
{
my ($time,$tz) = @_;
if ($tz < 0)
{
my $minutes = (-$tz / 100) * 60 + (-$tz % 100);
$time -= $minutes * 60;
}
else
{
my $minutes = ($tz / 100) * 60 + ($tz % 100);
$time += $minutes * 60;
}
return gmtime($time) . sprintf " %+05d", $tz;
}
# parse command line options
sub parse_options()
{
while (@ARGV && $ARGV[0] =~ /^-/)
{
my $arg = shift @ARGV;
if ($arg eq '--') { last; }
elsif ($arg eq '-c') { $cia_project_name = shift @ARGV; }
elsif ($arg eq '-m') { $commitlist_address = shift @ARGV; }
elsif ($arg eq '-n') { $max_individual_notices = shift @ARGV; }
elsif ($arg eq '-r') { $repos_name = shift @ARGV; }
elsif ($arg eq '-s') { $max_diff_size = shift @ARGV; }
elsif ($arg eq '-u') { $gitweb_url = shift @ARGV; }
elsif ($arg eq '-x') { push @exclude_list, "^" . shift @ARGV; }
elsif ($arg eq '-o') { $repos_owner = shift @ARGV; }
elsif ($arg eq '-d') { $debug++; }
else { usage(); }
}
if (@ARGV && $#ARGV != 2) { usage(); }
}
# send an email notification
sub mail_notification($$$@)
{
my ($name, $subject, $content_type, @text) = @_;
$subject = encode("MIME-Q",$subject);
if ($debug)
{
print "---------------------\n";
print "To: $name\n";
print "Subject: $subject\n";
print "Content-Type: $content_type\n";
print "\n", join("\n", @text), "\n";
}
else
{
my $pid = open MAIL, "|-";
return unless defined $pid;
if (!$pid)
{
exec $mailer, "-s", $subject, "-a", "Content-Type:
$content_type", $name or die "Cannot exec $mailer";
}
print MAIL join("\n", @text), "\n";
close MAIL;
}
}
# get the default repository name
sub get_repos_name()
{
my $dir = `git rev-parse --git-dir`;
chomp $dir;
my $repos = realpath($dir);
$repos =~ s/(.*?)((\.git\/)?\.git)$/\1/;
$repos =~ s/(.*)\/([^\/]+)\/?$/\2/;
return $repos;
}
# extract the information from a commit or tag object and return a hash
containing the various fields
sub get_object_info($)
{
my $obj = shift;
my %info = ();
my @log = ();
my $do_log = 0;
open TYPE, "-|" or exec "git", "cat-file", "-t", $obj or die "cannot
run git-cat-file";
my $type = <TYPE>;
chomp $type;
close TYPE;
open OBJ, "-|" or exec "git", "cat-file", $type, $obj or die "cannot
run git-cat-file";
while (<OBJ>)
{
chomp;
if ($do_log)
{
last if /^-----BEGIN PGP SIGNATURE-----/;
push @log, $_;
}
elsif (/^(author|committer|tagger) ((.*)(<.*>)) (\d+) ([+-]\d+)$/)
{
$info{$1} = $2;
$info{$1 . "_name"} = $3;
$info{$1 . "_email"} = $4;
$info{$1 . "_date"} = $5;
$info{$1 . "_tz"} = $6;
}
elsif (/^tag (.*)$/)
{
$info{"tag"} = $1;
}
elsif (/^$/) { $do_log = 1; }
}
close OBJ;
$info{"type"} = $type;
$info{"log"} = \@log;
return %info;
}
# send a commit notice to a mailing list
sub send_commit_notice($$)
{
my ($ref,$obj) = @_;
my %info = get_object_info($obj);
my @notice = ();
my $subject;
return if $info{"log"} eq "^(m|M)erge.*";
if ($info{"author"} =~ "$repos_owner") {
if ($info{"type"} eq "tag")
{
push @notice,
"Module: $repos_name",
"Branch: $ref",
"Tag: $obj",
#"URL: $gitweb_url/?a=tag;h=$obj",
"",
"Tagger: " . $info{"tagger"},
"Date: " . format_date($info{"tagger_date"},$info{"tagger_tz"}),
"",
join "\n", @{$info{"log"}};
$subject = "[CommitDiff] Tag " . $info{"tag"} . " : " .
$info{"tagger_name"} . ": " . ${$info{"log"}}[0];
}
else
{
push @notice,
"Module: $repos_name",
"Branch: $ref",
"Commit: $obj",
"Parent: $info()",
"URL: $gitweb_url/?a=commit;h=$obj",
"Author: " . $info{"author"},
"AuthorDate: " . format_date($info{"author_date"},$info{"author_tz"}),
"",
join "\n", @{$info{"log"}},
"",
"---",
"";
open STAT, "-|" or exec "git", "diff-tree", "--stat", "-M",
"--no-commit-id", $obj or die "cannot exec git-diff-tree";
push @notice, join("", <STAT>);
close STAT;
open DIFF, "-|" or exec "git", "diff-tree", "-p", "-M",
"--no-commit-id", $obj or die "cannot exec git-diff-tree";
my $diff = join( "", <DIFF> );
close DIFF;
if (($max_diff_size == -1) || (length($diff) < $max_diff_size))
{
push @notice, $diff;
}
else
{
push @notice, "Diff: $gitweb_url/?a=commitdiff;h=$obj",
}
$subject = "[CommitDiff] " . ${$info{"log"}}[0];
}
mail_notification($commitlist_address, $subject, "text/plain;
charset=UTF-8", @notice);
}
}
# send a commit notice to the CIA server
sub send_cia_notice($$)
{
my ($ref,$commit) = @_;
my %info = get_object_info($commit);
my @cia_text = ();
return if $info{"type"} ne "commit";
push @cia_text,
"<message>",
" <generator>",
" <name>git-notify script for CIA</name>",
" </generator>",
" <source>",
" <project>" . xml_escape($cia_project_name) . "</project>",
" <module>" . xml_escape($repos_name) . "</module>",
" <branch>" . xml_escape($ref). "</branch>",
" </source>",
" <body>",
" <commit>",
" <revision>" . substr($commit,0,10) . "</revision>",
" <author>" . xml_escape($info{"author"}) . "</author>",
" <log>" . xml_escape(join "\n", @{$info{"log"}}) . "</log>",
" <files>";
open COMMIT, "-|" or exec "git", "diff-tree", "--name-status", "-r",
"-M", $commit or die "cannot run git-diff-tree";
while (<COMMIT>)
{
chomp;
if (/^([AMD])\t(.*)$/)
{
my ($action, $file) = ($1, $2);
my %actions = ( "A" => "add", "M" => "modify", "D" => "remove" );
next unless defined $actions{$action};
push @cia_text, " <file action=\"$actions{$action}\">"
. xml_escape($file) . "</file>";
}
elsif (/^R\d+\t(.*)\t(.*)$/)
{
my ($old, $new) = ($1, $2);
push @cia_text, " <file action=\"rename\" to=\"" .
xml_escape($new) . "\">" . xml_escape($old) . "</file>";
}
}
close COMMIT;
push @cia_text,
" </files>",
" <url>" . xml_escape("$gitweb_url/?a=commit;h=$commit") .
"</url>",
" </commit>",
" </body>",
" <timestamp>" . $info{"author_date"} . "</timestamp>",
"</message>";
mail_notification($cia_address, "DeliverXML", "text/xml", @cia_text);
}
# send a global commit notice when there are too many commits for
individual mails
sub send_global_notice($$$)
{
my ($ref, $old_sha1, $new_sha1) = @_;
my @notice = ();
open LIST, "-|" or exec "git", "rev-list", "--pretty", "^$old_sha1",
"$new_sha1", @exclude_list or die "cannot exec git-rev-list";
while (<LIST>)
{
chomp;
s/^commit /URL: $gitweb_url\/?a=commit;h=/;
push @notice, $_;
}
close LIST;
mail_notification($commitlist_address, "New commits on branch $ref",
"text/plain; charset=UTF-8", @notice);
}
# send all the notices
sub send_all_notices($$$)
{
my ($ref, $old_sha1, $new_sha1) = @_;
$ref =~ s/^refs\/heads\///;
if ($old_sha1 eq '0' x 40) # new ref
{
send_commit_notice( $ref, $new_sha1 ) if $commitlist_address;
return;
}
my @commits = ();
open LIST, "-|" or exec "git", "rev-list", "^$old_sha1", "$new_sha1",
@exclude_list or die "cannot exec git-rev-list";
while (<LIST>)
{
chomp;
die "invalid commit $_" unless /^[0-9a-f]{40}$/;
unshift @commits, $_;
}
close LIST;
if (@commits > $max_individual_notices)
{
send_global_notice( $ref, $old_sha1, $new_sha1 ) if
$commitlist_address;
return;
}
foreach my $commit (@commits)
{
send_commit_notice( $ref, $commit ) if $commitlist_address;
send_cia_notice( $ref, $commit ) if $cia_project_name;
}
}
$repos_name = get_repos_name();
parse_options();
# append repository path to URL
$gitweb_url .= "/$repos_name.git";
if (@ARGV)
{
send_all_notices( $ARGV[0], $ARGV[1], $ARGV[2] );
}
else # read them from stdin
{
while (<>)
{
chomp;
if (/^([0-9a-f]{40}) ([0-9a-f]{40}) (.*)$/) { send_all_notices(
$3, $1, $2 ); }
}
}
exit 0;
^ permalink raw reply
* Re: Computing the number of patches in linux-next tree
From: Johannes Schindelin @ 2008-07-22 16:28 UTC (permalink / raw)
To: Tony Luck; +Cc: Git Mailing List
In-Reply-To: <12c511ca0807220919q4db6ee1fr33dc70fe35c58efe@mail.gmail.com>
Hi,
On Tue, 22 Jul 2008, Tony Luck wrote:
> git tag | grep next- | sort | while read tag
This should not be necessary... AFAICT "git tag" sorts its output already.
> What does the "git-where-did-this-tag-branch-from-linus" command look like?
git merge-base --all <branch1> <branch2>
Be warned: there might be multiple merge bases.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] bring description of git diff --cc up to date
From: Jonathan Nieder @ 2008-07-22 16:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, David Greaves
Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@uchicago.edu> writes:
>
>> + This flag implies the '-c' option and makes the patch output
>> + even more compact by omitting uninteresting hunks. A hunk is
>> + considered interesting only if either (a) it shows changes from
>> + all parents or (b) in an Octopus merge, it shows different changes
>> + from at least three different parents.
>
> I am not sure where that "at lesta three different parents" comes from.
> It might be that what the logic does can be expressed that way, but that
> was not the guiding principle why the code does what it currently does.
Yes, exactly - this is what I meant in saying "my proposed text
does not suggest very strongly what --cc is intended to do". I
haven't found any wording yet that both makes it clear what --cc
actually does and follows a thought process suggesting why.
Just to make sure I understand, here is what I think --cc does:
- In a two-parent merge, it is exactly as Linus has been
describing it. A hunk is interesting if and only if
it shows changes from both parents.
- In a many-parent merge, the criterion is more stringent.
As in the two-parent merge case, the hunk must show no
changes from at least one of the parents, meaning that
one of several alternatives for that portion of code
was chosen by the code integrator (without mixing and
matching or adding additional changes); but further, there
must have been only two alternatives for that portion of
code to choose between. If there were three distinct
alternatives, no matter what the code integrator does, the
hunk will show up (because that is so rare and deserves
attention).
Is that correct?
Thanks for the reading matter. If it stimulates anyone reading
into coming up with a better description, they should please let
me know :)
^ permalink raw reply
* Computing the number of patches in linux-next tree
From: Tony Luck @ 2008-07-22 16:19 UTC (permalink / raw)
To: Git Mailing List
I tried to produce a graph of the pending avalanche of patches
sitting in the linux-next tree and came up with this:
git tag | grep next- | sort | while read tag
do
c=$(git-rev-list --no-merges $tag ^linus | wc -l)
echo ${tag##next-} $c
done
Where "linus" is a branch that tracks Linus' tree. But this gets the
wrong count
for old tags because maintainers who use the topic-branch method have
exactly the same commits in linux-next as eventually end up in Linus ... so
once Linus pulls these trees, the historical counts change.
What I really need at this point is the commit from Linus tree that Stephen
uses as the basis for each next-* tag. I.e. change the loop body to
base=`git-where-did-this-tag-branch-from-linus $tag`
c=$(git-rev-list --no-merges $tag ^$base | wc -l)
Is this the right way to do this?
What does the "git-where-did-this-tag-branch-from-linus" command look like?
-Tony
^ permalink raw reply
* Re: Git Documentation
From: Johannes Schindelin @ 2008-07-22 16:07 UTC (permalink / raw)
To: Jay Soffian; +Cc: Johan Herland, david, Scott Chacon, git
In-Reply-To: <76718490807220847i298f256bm4c3f85bfde079ee2@mail.gmail.com>
Hi,
On Tue, 22 Jul 2008, Jay Soffian wrote:
> On Tue, Jul 22, 2008 at 7:40 AM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> > Most people hate to know the internals. They buy the car, and never
> > want to look inside the motor compartment. They buy wine, and never
> > want to know how it is made. They buy an iPod and never want to know
> > who assembles it, and how, and in what environment.
>
> I agree with this. And I like the top-down approach. Nonetheless, I
> think there are a few git concepts that are important to understand.
> Specifically, I don't think you can use git without understanding the
> index.
I do not see that the index is an internal. I see that the term "index"
is. So I think about not even bothering to mention it in my first two Git
lessons.
And you would be surprised to learn that I personally know a few people
who use Git happily _without_ knowing any internals. Now guess why: was
it because I explained a few easy-to-grasp commands, or because I made it
pretty complicated but thorough? Exactly.
Ciao,
Dscho
^ permalink raw reply
* Re: Git Documentation
From: Jay Soffian @ 2008-07-22 15:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Johan Herland, david, Scott Chacon, git
In-Reply-To: <alpine.DEB.1.00.0807221335560.3391@eeepc-johanness>
On Tue, Jul 22, 2008 at 7:40 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Most people hate to know the internals. They buy the car, and never want
> to look inside the motor compartment. They buy wine, and never want to
> know how it is made. They buy an iPod and never want to know who
> assembles it, and how, and in what environment.
I agree with this. And I like the top-down approach. Nonetheless, I
think there are a few git concepts that are important to understand.
Specifically, I don't think you can use git without understanding
the index.
Unfortunately, git isn't quite as good about abstractions yet as
some of the items you make analogies to. And even car's leak:
"And you can't drive as fast when it's raining, even though your
car has windshield wipers and headlights and a roof and a heater,
all of which protect you from caring about the fact that it's
raining (they abstract away the weather), but lo, you have to
worry about hydroplaning (or aquaplaning in England) and
sometimes the rain is so strong you can't see very far ahead so
you go slower in the rain, because the weather can never be
completely abstracted away, because of the law of leaky
abstractions."
http://www.joelonsoftware.com/articles/LeakyAbstractions.html
:-)
j.
^ permalink raw reply
* Re: Git Documentation
From: Scott Chacon @ 2008-07-22 14:46 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.DEB.1.00.0807221335560.3391@eeepc-johanness>
Thanks all for your input - I like the idea of the two-track thing and
I'll probably use a lot of what you've laid out to help structure the
site. I have personally tried to do a quick under the covers overview
beforehand because I have found that it helps, but I know many of you
work with new converts a lot too, so thanks again for your feedback.
As this gets going, I'll post here with updates from time to time to
make sure not too many of you feel it's going too far off track or I'm
not making incredible mistakes anywhere.
Thanks,
Scott
On Tue, Jul 22, 2008 at 4:40 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Tue, 22 Jul 2008, Johan Herland wrote:
>
>> Many Git users will not be VCS geeks like us; they will be "regular"
>> people that use Git because it's useful for them (or because they're
>> forced to use Git at $dayjob).
>
> Exactly. But it seems a concept hard to understand to some people. It
> also seems that VCS geeks like scripting, and assume everybody else does,
> too. Not so.
>
> Most people hate to know the internals. They buy the car, and never want
> to look inside the motor compartment. They buy wine, and never want to
> know how it is made. They buy an iPod and never want to know who
> assembles it, and how, and in what environment.
>
> You cannot teach those people to be more interested/interesting by showing
> them how things work internally. But you can give Git a bad reputation in
> the process.
>
> This, amongst other reasons, was why a company I worked at had a policy to
> never _ever_ have presentations or tutorials by technical staff. Never.
>
> Ciao,
> Dscho
>
>
^ permalink raw reply
* Re: git status in clean working dir
From: David Bremner @ 2008-07-22 14:10 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20080722060643.GA25023@sigill.intra.peff.net>
>>>>> "Jeff" == Jeff King <peff@peff.net> writes:
Jeff> We already do that (see pager.c:53). The original poster
Jeff> still had a problem, but I don't know if it was for actual
Jeff> usage or simply a toy
Jeff> $ git status
Jeff> $ echo $?
Jeff> $ echo "why don't exit codes work in status?" | mail git@vger
Well, I wanted to know if git status was the right tool to detect a
working directory with no changes to commit. So I tried it in the
shell, and it failed. I then read the man page. For me, it would be
fine to document the current behaviour (i.e. in practice "git status
-a > /dev/null" would be what I would use in scripts anyway). To be
honest the current behaviour was not something I would have guessed.
Thanks to all for paying attention to my complaint,
David
^ permalink raw reply
* Re: problem using jgit
From: Marek Zawirski @ 2008-07-22 11:51 UTC (permalink / raw)
To: Stephen Bannasch; +Cc: git, Robin Rosenberg, Shawn O. Pearce
In-Reply-To: <p0624080dc4aa78c93ffe@[192.168.1.106]>
Stephen Bannasch wrote:
> At 2:35 PM +0200 7/21/08, Marek Zawirski wrote:
>
>> Marek Zawirski wrote:
>>
>>> Stephen Bannasch wrote:
>>>
>>>> I've setup a simple test class that integrates jgit to clone a git repository. However I'm getting a NullPointerError when RevWalk.parseAny ends up producing a null object id.
>>>>
>>>> The code and the stack trace for the error are here:
>>>>
>>>> http://pastie.org/237711
>>>>
>>>> This problem occurs using the jgit from the master branch from this repo:
>>>>
>>>> git://repo.or.cz/egit.git
>>>>
>>> Hello Stephen,
>>>
>>> I think you've experienced error caused by the same bug as me, during my latest fetch/push GUI works few days ago.
>>> Your code looks fine, probably it's actually bug in jgit. I think it's some regression. Thanks for reporting.
>>>
>> It's caused by 14a630c3: Cached modification times for symbolic refs too
>> Changes introduced by this patch made Repository#getAllRefs() including Ref objects with null ObjectId in case of unresolvable (invalid?) HEAD symbolic ref, and null Ref for HEAD when it doesn't exist. Previous behavior was just not including such refs in result.
>>
>> Fix for null Ref is just a matter of simple filtering out null Ref object for HEAD, if it doesn't exist (just is it considered to be legal state of repository when HEAD doesn't exist?).
>>
>> To fix null ObjectId issue, we have to either change all clients of this method or revert method to previous behavior. Now it's just unspecified in javadoc.
>> Robin, Shawn, what do you think? If we want to have unresolvable refs included, IMO it may be sensible to provide argument includeUnresolbable for Repository#getAllRefs() to let clients avoid burden of filtering them out when they don't need them (most cases, perhaps).
>> I can prepare fix for it (rather easy one) as you are unavailable now, let me now what's your opinion.
>>
>
> Thanks for looking at this problem Marek.
>
> If you get a change working for jgit that might not be available in a branch on git://repo.or.cz/egit.gi will you send a patch.
>
> I am looking forward to continuing my tests using jgit from Java and JRuby.
>
You can find temporary workaround for that in "workaround" branch at
git://repo.or.cz/egit/zawir.git
It's rather not a final solution (disables unresolvable HEADs), but I
hope it let you continue using jgit for a while, as it does for me ;)
^ permalink raw reply
* Re: Git Documentation
From: Johannes Schindelin @ 2008-07-22 11:40 UTC (permalink / raw)
To: Johan Herland; +Cc: david, Scott Chacon, git
In-Reply-To: <200807221121.22520.johan@herland.net>
Hi,
On Tue, 22 Jul 2008, Johan Herland wrote:
> Many Git users will not be VCS geeks like us; they will be "regular"
> people that use Git because it's useful for them (or because they're
> forced to use Git at $dayjob).
Exactly. But it seems a concept hard to understand to some people. It
also seems that VCS geeks like scripting, and assume everybody else does,
too. Not so.
Most people hate to know the internals. They buy the car, and never want
to look inside the motor compartment. They buy wine, and never want to
know how it is made. They buy an iPod and never want to know who
assembles it, and how, and in what environment.
You cannot teach those people to be more interested/interesting by showing
them how things work internally. But you can give Git a bad reputation in
the process.
This, amongst other reasons, was why a company I worked at had a policy to
never _ever_ have presentations or tutorials by technical staff. Never.
Ciao,
Dscho
^ permalink raw reply
* Re: git status in clean working dir
From: Johannes Schindelin @ 2008-07-22 11:24 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git, David Bremner
In-Reply-To: <20080722045223.GC20787@sigill.intra.peff.net>
Hi,
On Tue, 22 Jul 2008, Jeff King wrote:
> On Tue, Jul 22, 2008 at 12:44:00AM -0400, Jeff King wrote:
>
> > We could also swap the parent/child relationship, and have the pager
> > as child. But I assume that it is done the way we have it because
> > otherwise the shell gets confused about when the command ends (i.e.,
> > we want it to run until pager completion). I didn't test, though.
>
> Hmm, it looks like the MINGW32 codepath already _does_ spawn in that
> order, but has a "wait_for_child" atexit handler. I wonder if there is a
> reason all platforms can't use that trick (though the mingw approach
> uses run_command, which makes it harder to do the "wait for input before
> starting less" trick).
I recently suggested exactly that already, to catch SIGSEGVs in the paged
process, amongst other things.
Ciao,
Dscho
^ permalink raw reply
* Re: How to find the first commit belonging to any branch
From: Kristian Amlie @ 2008-07-22 11:18 UTC (permalink / raw)
To: git
In-Reply-To: <7vej5mmfp9.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Kristian Amlie <kristian.amlie@trolltech.com> writes:
>
>> I have a question about git: I have one commit sha1, and I would like
>> to know the nearest commit that appears in *any* other branch. The
>> sha1 that I have does not belong to any branch.
>>
>> The obvious thing to do would be to make a for loop and iterate over
>> existing branches while calling git merge-base, but I'm wondering if
>> there's a more clever method.
>
> If the $commit does not belong to any branch, then:
>
> $ git rev-list --bounardy $commit^0 --not --branches | sed -ne 's/^-//p'
>
> would give you boundary commits of the above traversal, which says:
>
> Traverse from $commit following the parents, but stop at anything that
> is reachable from any breanch.
>
> which means that the ones that are output are the candidates that are on
> some branch.
>
> So pipe that to name-rev like this, perhaps (untested)?
>
> $ git rev-list --bounardy $commit^0 --not --branches |
> sed -ne 's/^-//p' |
> git name-rev --stdin
>
>
Thanks! That did the trick!
Kristian
^ permalink raw reply
* Re: [PATCH for master] Rename path_list to string_list
From: Johannes Schindelin @ 2008-07-22 11:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3am2sldy.fsf@gitster.siamese.dyndns.org>
Hi,
On Mon, 21 Jul 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > @@ -64,9 +65,10 @@ Functions
> >
> > `string_list_clear`::
> >
> > - Free a string_list. The `path` pointer of the items will be freed in case
> > - the `strdup_strings` member of the string_list is set. The second parameter
> > - controls if the `util` pointer of the items should be freed or not.
> > + Free a string_list. The `path` pointer of the items will be freed in
> > + case the `strdup_strings` member of the string_list is set. The second
> > + parameter controls if the `util` pointer of the items should be freed
> > + or not.
>
> Missed 's/path/string/' here?
Good catch. I clearly forgot to grep for "path" in all the files that I
touched. I did that now, but only looked at comments (in the hope that
the compiler would have caught the other ones).
-- snipsnap --
[PATCH] Fix two leftovers from path_list->string_list
In the documentation, where you cannot get compile errors for using the
wrong member name, there were two mentions of 'path' left.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Documentation/technical/api-string-list.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/technical/api-string-list.txt b/Documentation/technical/api-string-list.txt
index 92b3ecd..293bb15 100644
--- a/Documentation/technical/api-string-list.txt
+++ b/Documentation/technical/api-string-list.txt
@@ -41,7 +41,7 @@ memset(&list, 0, sizeof(struct string_list));
string_list_append("foo", &list);
string_list_append("bar", &list);
for (i = 0; i < list.nr; i++)
- printf("%s\n", list.items[i].path)
+ printf("%s\n", list.items[i].string)
----
NOTE: It is more efficient to build an unsorted list and sort it
@@ -113,7 +113,7 @@ Data structures
* `struct string_list_item`
-Represents an item of the list. The `path` member is a pointer to the
+Represents an item of the list. The `string` member is a pointer to the
string, and you may use the `util` member for any purpose, if you want.
* `struct string_list`
--
1.5.6.2.516.g22071
^ permalink raw reply related
* Re: post-receive-hook emailer
From: Abhijit Menon-Sen @ 2008-07-22 10:40 UTC (permalink / raw)
To: Ask Bjørn Hansen; +Cc: git
In-Reply-To: <00AEED4D-BD34-4584-B303-32C5F587EF0F@develooper.com>
Hi Ask.
At 2008-07-22 02:34:35 -0700, ask@develooper.com wrote:
>
> Anyway - anyone have a mailer that sends diffs and such? :-)
Not quite what you want, but I wrote the attached post-receive hook/hack
to send change notifications by Jabber. "hooks.notify.recipients" should
contain a list of jabber IDs; and you can change the "git log" line, for
example by adding "-p --stat" or something, to change what gets sent.
It should be trivial to change the last twenty-odd lines to send email
instead.
-- ams
#!/usr/bin/perl
# Abhijit Menon-Sen <ams@oryx.com>
use Net::Jabber;
my $dir;
chomp( $dir = qx(git rev-parse --git-dir 2>/dev/null) );
die "GIT_DIR not defined.\n" unless $dir;
$ENV{GIT_DIR} = $dir;
my $r;
chomp( $r = qx(git config hooks.notify.recipients) );
my @recipients = split /,\s*/, $r;
my @changes;
while ( <> ) {
chomp;
my ( $old, $new, $ref ) = split / /;
$ref =~ s!refs/heads/!!;
next unless $ref eq "some/branch";
my $s = qx(git log --no-merges --reverse --find-copies-harder --raw -r $old..$new);
$s =~ s/^:.*?\t/\t/gsm;
push @changes, $s;
}
exit unless @changes;
exit unless @recipients;
my $client = new Net::Jabber::Client ();
$client->Connect(
hostname => 'example.com',
) or die "Cannot connect to jabber server: $!.\n";
my @r = $client->AuthSend(
username => 'git',
password => 'some-password',
resource => 'git'
);
die "Cannot authenticate (@r).\n" if $r[0] ne "ok";
foreach my $c (@changes) {
for my $r (@recipients) {
my $msg = new Net::Jabber::Message ();
$msg->SetMessage(
to => $r,
subject => 'Changes pushed to x:y.git/some/branch',
body => $c
);
$client->Send( $msg );
}
}
$client->Disconnect();
^ permalink raw reply
* Re: [PATCH] mailinfo: better parse email adresses containg parentheses
From: Philippe Bruhat (BooK) @ 2008-07-22 10:24 UTC (permalink / raw)
To: git
In-Reply-To: <7v63qyr4kk.fsf@gitster.siamese.dyndns.org>
On Mon, Jul 21, 2008 at 08:16:43PM -0700, Junio C Hamano wrote:
> >
> > Signed-off-by: Philippe Bruhat (BooK) <book@cpan.org>
>
> Hmm, tests?
>
> By the way, that second form parses like this:
>
> mailbox =
> name-addr =
> display-name angle-addr = "User Name (me) <user@host>"
>
> display-name =
> phrase = "User Name"
>
> angle-addr = CFWS "<" addr-spec ">" = "(me) <user@host>"
>
> So strictly speaking, shouldn't we be stripping the whole (me) as garbage?
> It is not even part of the display-name but is a whitespace equivalent
> comment.
Well, I use this:
"Philippe Bruhat (BooK)" <book@cpan.org>
as my From: line, and I would like to be able to use it so in git.
As git knows the difference between user name and user email, it should
be able to keep the information separate all the way.
Which makes me think that since it seems that rebase goes through a
patch-file step, the problem with my username may actually lie with
creating the patch file (no quotes around a user name containing parens)
rather than with parsing the patch From: line.
--
Philippe Bruhat (BooK)
Everyone's life seems easier from the outside.
(Moral from Groo The Wanderer #45 (Epic))
^ permalink raw reply
* Re: Git Documentation
From: Pedro Melo @ 2008-07-22 10:15 UTC (permalink / raw)
To: Scott Chacon; +Cc: git
In-Reply-To: <d411cc4a0807212035v68c2ed95m93b77c1e61cfec9e@mail.gmail.com>
Hi,
On Jul 22, 2008, at 4:35 AM, Scott Chacon wrote:
> I'm starting a project to host a really nice, user-friendly, easy to
> use Git learning materials website for Git newbies to get new users
> started and make it as easy to learn as possible. I'll be redoing or
> editing some of my screencasts from gitcasts.com and starting an open
> book at github and putting it all in one place for new users to get
> started easily. Anyone will be free to submit changes, additions,
> etc.
>
> If anyone has any tips on how they think git should be taught, issues
> they are asked a lot, problems newbies tend to have, something they
> wish there were a screencast for or was better documented, etc -
> please do contact me so I can incorporate it. I would contribute to
> git itself, but my C-foo is seriously wanting, so if by teaching
> people properly I can free up some time for you guys, I would love to
> do so.
>
> Please let me know if you have any pointers or think anything should
> really be better documented for end-users. I plan to do a lot of
> graphics, screencasts and whatever else makes it as simple as
> possible.
A section on usual workflows and setups would be most useful. Some
like a pull/push workflow, others a email based workflow.
As for learning git stuff, I usually point new users to your stuff :).
I also point them to Tommi Virtanen "Git for Computer Scientists":http://eagain.net/articles/git-for-computer-scientists/
. It was that article that made it all "click" for me regarding git.
Best regards,
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: melo@simplicidade.org
Use XMPP!
^ permalink raw reply
* [PATCH v2] parse-options: fix segmentation fault when a required value is missing
From: Olivier Marin @ 2008-07-22 10:11 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Junio C Hamano, git
In-Reply-To: <20080721190709.GD2718@artemis.madism.org>
From: Olivier Marin <dkr@freesurf.fr>
p->argc represent the number of arguments that have not been parsed yet,
_including_ the one we are currently parsing. If it is not greater than
one then there is no more argument.
Signed-off-by: Olivier Marin <dkr@freesurf.fr>
Acked-by: Pierre Habouzit <madcoder@debian.org>
---
The same, not whitespace damaged! Sorry for the noise.
parse-options.c | 2 +-
t/t0040-parse-options.sh | 7 +++++++
2 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/parse-options.c b/parse-options.c
index 987b015..71a7acf 100644
--- a/parse-options.c
+++ b/parse-options.c
@@ -22,7 +22,7 @@ static int get_arg(struct parse_opt_ctx_t *p, const struct option *opt,
p->opt = NULL;
} else if (p->argc == 1 && (opt->flags & PARSE_OPT_LASTARG_DEFAULT)) {
*arg = (const char *)opt->defval;
- } else if (p->argc) {
+ } else if (p->argc > 1) {
p->argc--;
*arg = *++p->argv;
} else
diff --git a/t/t0040-parse-options.sh b/t/t0040-parse-options.sh
index 6309aed..03dbe00 100755
--- a/t/t0040-parse-options.sh
+++ b/t/t0040-parse-options.sh
@@ -78,6 +78,13 @@ test_expect_success 'long options' '
test_cmp expect output
'
+test_expect_success 'missing required value' '
+ test-parse-options -s;
+ test $? = 129 &&
+ test-parse-options --string;
+ test $? = 129
+'
+
cat > expect << EOF
boolean: 1
integer: 13
--
1.6.0.rc0.136.g55999
^ permalink raw reply related
* post-receive-hook emailer
From: Ask Bjørn Hansen @ 2008-07-22 9:34 UTC (permalink / raw)
To: git
Hi everyone,
Anyone know what is used to send the http://marc.info/?l=git-commits-head
mails?
The post-receive contrib hook in the repository isn't working for us -
we want diffs and such in our mails. I started working on patching
the script in contrib; but it's not really clear to me if the current
state of that script is as it should be and I just have a different
use case.
Anyway - anyone have a mailer that sends diffs and such? :-) Or
should I just write a wrapper around format-patch and send-email?
(To handle branches well it gets slightly complicated, quick - or
maybe I just haven't understood how the post-receive hook works).
- ask
--
http://develooper.com/ - http://askask.com/
^ permalink raw reply
* Re: git status in clean working dir
From: Jeff King @ 2008-07-22 9:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Mike Hommey, git, David Bremner
In-Reply-To: <7viquymg5k.fsf@gitster.siamese.dyndns.org>
On Tue, Jul 22, 2008 at 02:17:43AM -0700, Junio C Hamano wrote:
> Another slight worry I have is if the now-parent git process does the
> right thing when the user kills the pager without viewing the output to
> the end. git itself will get stuck with write() while the user is
> reading, and then notice that the pipe does not have any more reader when
> the pager is killed. This fact itself won't change by swapping the
> parent-child relationship, but would we get a sensible behaviour after
> that, or have we been ignoring what happens afterwards only because our
> exit status has been hidden behind the pager? Running "git log" and
> killing it by "q" (my pager is "less") makes it exit with 141.
Hmm, good point. Though previously in this case, we were getting
whatever code the pager provided. Which means nobody probably cared that
much. Though I suppose that people who use "$?" in their prompt might
see scariness.
> I shouldn't worry, if everything is written correctly in the other parts
> of the system, this swap should not have much ill effect.
I am a little unhappy about the git process hanging around, but I don't
know if it is worth making a meta-process just to manage the pager.
Also, I think people with a pager that has spaces in in it will now need
to quote it (e.g., PAGER="/path with space/less" used to work, but now
is passed to the shell). Arguably, this brings it in line with other
spawned programs, like EDITOR, but it is a difference, and we are in
release freeze. That could be fixed with some magic in run_command.
(Note that it has always been run by the shell under Windows, so again,
this is making things more consistent).
> By the way [2/2] was not signed-off. Just forgotten?
Yes, forgotten. If you are planning on applying, please forge (and
squash the portability fix).
-Peff
^ permalink raw reply
* Re: How to find the first commit belonging to any branch
From: Junio C Hamano @ 2008-07-22 9:27 UTC (permalink / raw)
To: Kristian Amlie; +Cc: git
In-Reply-To: <4885A39F.5080209@trolltech.com>
Kristian Amlie <kristian.amlie@trolltech.com> writes:
> I have a question about git: I have one commit sha1, and I would like
> to know the nearest commit that appears in *any* other branch. The
> sha1 that I have does not belong to any branch.
>
> The obvious thing to do would be to make a for loop and iterate over
> existing branches while calling git merge-base, but I'm wondering if
> there's a more clever method.
If the $commit does not belong to any branch, then:
$ git rev-list --bounardy $commit^0 --not --branches | sed -ne 's/^-//p'
would give you boundary commits of the above traversal, which says:
Traverse from $commit following the parents, but stop at anything that
is reachable from any breanch.
which means that the ones that are output are the candidates that are on
some branch.
So pipe that to name-rev like this, perhaps (untested)?
$ git rev-list --bounardy $commit^0 --not --branches |
sed -ne 's/^-//p' |
git name-rev --stdin
^ permalink raw reply
* Re: Git Documentation
From: Johan Herland @ 2008-07-22 9:21 UTC (permalink / raw)
To: david; +Cc: Scott Chacon, git
In-Reply-To: <alpine.DEB.1.10.0807220035110.1125@asgard.lang.hm>
On Tuesday 22 July 2008, david@lang.hm wrote:
> On Tue, 22 Jul 2008, Johan Herland wrote:
> > It seems there are primarily two ways to teach Git:
> >
> > 1. Top-down: Start with simple use cases and commands. Teach people a
> > minimal, but necessary set of porcelain commands to get them started.
> > Stay _far_ away from plumbing commands and most of the command options.
> >
> > 2. Bottom-up: Start with how Git structures the data. Talk about blobs,
> > trees, commits, refs, how everything is connected, and how various Git
> > commands query and manipulate this structure. This _may_ involve a fair
> > amount of plumbing commands, especially when discovering how the more
> > complicated high-level commands manipulate the structure.
> >
> > Some people seem to prefer the first approach, other people prefer the
> > other approach. Both paths lead to enlightenment ;). In many cases a
> > bit of both may be useful. HOWEVER, I think it is _very_ important to
> > keep in mind that these are two _different_ approaches, and the
> > contexts in which they are taught should be kept separate. I would
> > almost suggest splitting your website down the middle and make the
> > difference between top-down and bottom-up immediately visible with,
> > say, a different background color, or something else that immediately
> > tells the user what "track" they are following...
>
> possibly a combination of the two?
>
> under the covers the git data-structures are pretty simple and explaining
> them (and the minimal tools to manipulate them) isn't that bad.
Not sure. In both cases one will need _some_ kind of model to work with, but
I think that for the top-down approach, it will suffice with a very
simple/simplified model along the lines of:
- A commit contains the state of some repo at some point in time (plus some
metadata)
- A commit points to its direct parents (zero or more). A collection of
commits make up a DAG, representing the history of a project.
- Refs point to select commits. Tags are static, branches are dynamic, etc.
Specifically, for the top-down approach I do NOT think it is necessary to
teach:
- blobs and trees
- plumbing tools
> what gets ugly is when you then try to use the plumbing to do the
> non-trivial things.
Certainly. We should only use plumbing tools in the bottom-up approach, and
even then we should only use them when it _simplifies_ or otherwise nicely
_illustrates_ the concepts being taught.
> so how about an optional 'under the covers' primer, covering just the
> trivial plumbing, then the high-level minimal introduction with a link on
> each of the commands as they are introduced (so that a person can dig
> into deeper detail if they want to, possibly including 'up until version
> X this command was implemented by the following script'), followed by
> links to sample work-flows and a full dive into the plumbing (because at
> this point the person should know enough to get by, now they need
> reference material and examples more then a tutorial).
Nope. A primer (i.e. a document to be read before the "real" teaching
starts) should not cover more than the simplest/simplified model (see
above).
Of course, the courses should reference manual pages and more in-depth
documentation wherever it makes sense, but we should make sure to note that
such knowledge is not _required_ to follow the course.
> ideally this would let people dive as deep as they are comfortable with,
> or skim the explanation for the functionality
>
> I think one reason the 'plumbing first' approach gets a bad rap is that
> it's so easy to get caught up into how clever you can get with the
> plumbing. it's like teaching someone programming by spending a day
> introducing them to concepts and language syntax, and then giving them
> the entries in the obfuscated C contests as examples of how someone can
> use them to get work done, but skipping any mention of libc or other
> standard libraries.
I see your point, but I still don't think teaching plumbing have any value
in and of itself (unless you need to specifically learn plumbing to write
porcelain code/scripts, in which case you'd better already know how to
navigate the existing manual pages and other documentation).
For newbies, I think plumbing should only be taught/mentioned when it
simplifies or illustrates a concept in the bottom-up approach.
> on the other hand, teaching only porcelain is like teaching them <insert
> high-level *th generation buzzword language> without teaching any concept
> of what they computer is doing under the covers, they can work, and even
> get useful work done, but they will be limited on how effective they can
> be.
I don't agree that teaching only porcelain will not give them any concept of
what their computer does "under the covers". I think we can teach porcelain
with reference to the simplified object model, and still achieve a
(simplified, but still rewarding) understanding of what happens at an
object level.
When I use Git myself, I normally only think in terms of the simplified
model, and I have no problem getting things done without paying attention
to the full object model (blobs, trees, etc) or the plumbing tools that are
implicitly involved in the process.
> you can't be a great programmer until you can understand both levels, the
> under-the-covers 'plumbing' and the high level libraries of the
> 'porcelain', trying to ignore either will limit you.
Agreed. But we shouldn't need every Git user to be a great programmer. At
least I hope not. Otherwise, there will be few Git users, indeed... ;)
Many Git users will not be VCS geeks like us; they will be "regular" people
that use Git because it's useful for them (or because they're forced to use
Git at $dayjob). They will not be interested in how Git manages their data,
and how a complex Git operation can be split into simple plumbing
components. We should not require them to learn such details in order to
become good Git users. Instead we should teach them Git using porcelain
commands with reference to the simplified object model. They should learn
how to use Git in a simple, yet still rewarding manner.
...and _that_ is how we achieve world domination ;)
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: git status in clean working dir
From: Junio C Hamano @ 2008-07-22 9:17 UTC (permalink / raw)
To: Jeff King; +Cc: Mike Hommey, git, David Bremner
In-Reply-To: <20080722071009.GA3610@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, Jul 22, 2008 at 02:46:04AM -0400, Jeff King wrote:
>
>> I am tempted by the "order switching" I mentioned, but that would entail
>> the git process waiting to clean the pager, during which time it may be
>> consuming memory. But maybe that isn't worth worrying about.
>
> It feels very wrong proposing this during release freeze, but here is
> the "pager is child of git" implementation.
Another slight worry I have is if the now-parent git process does the
right thing when the user kills the pager without viewing the output to
the end. git itself will get stuck with write() while the user is
reading, and then notice that the pipe does not have any more reader when
the pager is killed. This fact itself won't change by swapping the
parent-child relationship, but would we get a sensible behaviour after
that, or have we been ignoring what happens afterwards only because our
exit status has been hidden behind the pager? Running "git log" and
killing it by "q" (my pager is "less") makes it exit with 141.
I shouldn't worry, if everything is written correctly in the other parts
of the system, this swap should not have much ill effect.
By the way [2/2] was not signed-off. Just forgotten?
^ permalink raw reply
* Re: Error: "You have some suspicious patch lines"
From: Jakub Narebski @ 2008-07-22 9:13 UTC (permalink / raw)
To: Ben Aurel; +Cc: git
In-Reply-To: <4885895C.5050108@gmail.com>
Ben Aurel <ben.aurel@gmail.com> writes:
> I working on mac os x 10.5.4 (intel) with git version 1.5.5.3 and I
> always get this message for most of my perl scripts and also for
> "Makefile.pre" files:
>
> ----------- Message ---------------
> * You have some suspicious patch lines:
> *
> * In src/scripts/trunk/3rdparty/file_sanity.pl
> * trailing whitespace (line 52)
> ...
> ------------------------------------------
> The question now is: Is it really necessary to edit the git script
> everytime? Is there a urgent reason why git refuses to commit because
> of "suspicious" lines? Is it really necessary?
.git/hooks/pre-commit is example hook which helps to keep Coding Style,
and prevents from accidentally comitting nonresolved file-level merge
conflict (file with conflict markers).
If you want to skip running this hook once (or once upon a time), you
can use '-n'/'--no-verify' option to "git commit". Or you can turn this
example hook off, either by removing execute permission from it, by
removing it alltogether (you can still find it in templates, usually at
/usr/share/git-core/templates/hooks/pre-commit), or rename it adding for
example '.sample' or '.nonactive' suffix.
This hook should not be turned on by default, but if your filesystem is
executing bit challenged it could be turned on at repository creation
time unintentionally. Newer version of git use '.sample' suffix (for
example pre-commit.sample) instead of relying on not always reliable
execute bit being unset.
HTH
--
Jakub Narebski
Poland
ShadeHawk on #git
^ 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