* Re: Git graph on GitHub
From: Jakub Narebski @ 2008-10-18 20:56 UTC (permalink / raw)
To: Tom Werner; +Cc: git
In-Reply-To: <530345950810150047v75bfbf9clebbb8a406b172c4c@mail.gmail.com>
"Tom Werner" <pubsub@rubyisawesome.com> writes:
> We've just pushed out an update to the Network Graph on GitHub this
> evening that finally allows us to draw very large repositories
> (including Git). We're mirroring the Git repo on the site and I
> thought it might be interesting for people to see this visualization.
> Enjoy!
>
> http://github.com/git/git/network
>
> Let me know if you have any ideas for improvements on the graph. I'm
> always looking for ways to enhance it.
First, I wonder a bit why did you choose horizontal layout of revision
graph, instead of displaying it vertically alongside log (log like
view) like graphical history viewers and other web interfaces offering
graphical log, e.g.
http://lwn.net/Articles/140350/ (gitk screenshoot)
http://repo.or.cz/git-browser/by-commit.html?r=alt-git.git
http://people.proekspert.ee/peeter/git/git.php?p=git-git.git
I guess it is because you can show complicated history better, and
because of the "network" feature which is simply not visible for
git.git repository. On the other hand in vertical view you can display
commit subject alongside graph.
Second, the "go to commit" on click doesn't work for me, but perhaps
that is just I have to update my ancient web browser (Mozilla 1.17.2
for Linux, with Shockwave Flash 9.0 r124). I would expect that after
clicking on commit I would get _whole_ commit message, not only commit
subject (first line / first paragraph of commit message). Or at least
have some option (keyboard shortcut?) to toggle viewing full commit
message. BTW. what does having commit sha-1 there give you? You
can't select it for copy'n'paste, can you?
Third, it is nice to have refs markers for branches, but I wonder why
I cannot see refs markers for _tags_ (so one can easily see what is in
released version, and what isn't). I also wonder why in commit
description box visible on mouseover you don't have refs markers there
(even if they are turned off for graph, for example for better
visibility because they obscure some line).
By the way, it might be not relevant because while (if I understand
correctly) graphs are ordered by commit date they are not aligned on
time axis, but the timeline of commits for given author on Ohloh looks
quite nice. (Unfortunately this part of Ohloh is not open source,
although AFAIK it is also in Ruby). Example:
https://www.ohloh.net/projects/git/contributors/1194000913727
(but it doesn't use Flash).
Thank you for your work on GitHub
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* git-svn url-encodes ~ when it should not
From: Björn Steinbrink @ 2008-10-18 21:39 UTC (permalink / raw)
To: Eric Wong; +Cc: git
Hi,
Jose Carlos Garcia Sogo reported on #git that a git-svn clone of this
svn repo fails for him:
https://sucs.org/~welshbyte/svn/backuptool/trunk
I can reproduce that here with:
git-svn version 1.6.0.2.541.g46dc1.dirty (svn 1.5.1)
The error message I get is:
Apache got a malformed URI: Unusable URI: it does not refer to this
repository at /usr/local/libexec/git-core/git-svn line 4057
strace revealed that git-svn url-encodes ~ while svn does not do that.
For svn we have:
write(5, "<S:update-report send-all=\"true\" xmlns:S=\"svn:\">
<S:src-path>https://sucs.org/~welshbyte/svn/backuptool/trunk</S:src-path>...
While git-svn shows:
write(7, "<S:update-report send-all=\"true\" xmlns:S=\"svn:\">
<S:src-path>https://sucs.org/%7Ewelshbyte/svn/backuptool/trunk</S:src-path>...
Björn
^ permalink raw reply
* Re: What is the pre-merge hook status?
From: Paolo Bonzini @ 2008-10-18 21:57 UTC (permalink / raw)
To: Alexander Gladysh; +Cc: git
In-Reply-To: <c6c947f60810172342n6843b173tb0019d0af706800d@mail.gmail.com>
Alexander Gladysh wrote:
> Hi, Paolo!
>
> What is the status of your pre-merge hook patch?
>
> http://article.gmane.org/gmane.comp.version-control.git/93888
>
> I think it can help me greatly with my repository management process.
I decided that it was a bad design for me at least, because the control
had better be implemented on the server (using an update hook). But I
can submit it if you need it for something.
Paolo
^ permalink raw reply
* Re: git-svn crashing perl
From: Alex Bennee @ 2008-10-18 22:00 UTC (permalink / raw)
To: Heinrich Nirschl; +Cc: git
In-Reply-To: <394ab6ec0810180905t5faca9cbnc7b73267a72deddc@mail.gmail.com>
On Sat, Oct 18, 2008 at 5:05 PM, Heinrich Nirschl
<heinrich.nirschl@gmail.com> wrote:
> On Sat, Oct 18, 2008 at 3:42 PM, Alex Bennee <kernel-hacker@bennee.com> wrote:
>> Hi,
>>
>> Doing a git-sv fetch --fetch-all is generating a SEGV in perl while I
>> try and update my repo. Although I can look at the backtrace in perl
>> it doesn't really tell me much. Any tips on how I can get more info?
>>
>
> This seems to be a problem of the subversion perl bindings. See for example:
> http://subversion.tigris.org/issues/show_bug.cgi?id=3007
>
Looks similar. libapr certainly seems to be breaking something:
Core was generated by `/usr/bin/perl
/home/alex/src/git.git/install/libexec/git-core/git-svn fetch --f'.
Program terminated with signal 11, Segmentation fault.
#0 0x00007fd0d813c370 in ?? ()
(gdb) bt
#0 0x00007fd0d813c370 in ?? ()
#1 0x00007fd0d9a52a5d in ?? () from /usr/lib/libapr-1.so.0
#2 0x00007fd0d9a53d9a in ?? () from /usr/lib/libapr-1.so.0
#3 0x00007fd0d9a54003 in ?? () from /usr/lib/libapr-1.so.0
#4 0x00007fd0d9a53d88 in ?? () from /usr/lib/libapr-1.so.0
#5 0x00007fd0d9a54003 in ?? () from /usr/lib/libapr-1.so.0
#6 0x00007fd0d9a540f3 in apr_pool_terminate () from /usr/lib/libapr-1.so.0
#7 0x00007fd0db1c6e83 in _wrap_apr_terminate () from
/usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux/auto/SVN/_Core/_Core.so
#8 0x000000000047dbab in Perl_pp_entersub ()
#9 0x00000000004677fa in Perl_runops_debug ()
#10 0x0000000000425ae8 in Perl_call_sv ()
#11 0x0000000000425faa in Perl_call_list ()
#12 0x000000000042a0e8 in perl_destruct ()
#13 0x0000000000422238 in main ()
--
Alex, homepage: http://www.bennee.com/~alex/
^ permalink raw reply
* Re: [PATCH] Git.pm: do not break inheritance
From: Christian Jaeger @ 2008-10-18 22:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Petr Baudis
In-Reply-To: <7vabd1aaqx.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> That's how you would write class methods, isn't it? IOW, your callers
> can say:
>
> my $self = new Git();
> $self->method(qw(a b c));
> Git::method(qw(a b c))
>
> and you can start your method like this:
>
> sub method {
> my ($self, @args) = _maybe_self(@_)
> ...
> }
>
> and use @args the same way for either form of the call in the
> implementation.
I see, a magic way to offer both an OO and procedural api. Well, partial
procedural api, since not all of the methods can work without the $self.
> Two obvious pitfalls are:
>
> - You cannot use $self if you set up your parameters with _maybe_self;
>
> - The second form of the call would call directly into Git::method, never
> your subclasses implementation, even if you write:
>
> use Git;
> package CJGit;
> our @ISA = qw(Git);
>
> sub method {
> ...
> }
>
>
(This is no problem iff people are calling procedures in object notation
if they actually have got an object at hands. I.e. if you've got some
code which does:
my $repo= Git->repository(...);
$repo->foo;
then all is fine, and I would think it would be weird if people called
Git::foo($repo, ... ) in such a case. Well for my purposes it's not a
problem anyway, since if a user wants to use the extensions, he needs to
actually do this:
my $repo= CJGit->repository(...);
and then it should be clear that one shouldn't call Git:: directly. The
problem will only be in cases where an extended object is being fed to
existing code which calls Git:: with objects in the hope that virtual
method calls are going to the extended class; well, let's fix those bad
call sites when they are being discovered... Maybe this warrants a
warning somewhere.)
>> sub _maybe_self {
>> - # This breaks inheritance. Oh well.
>> - ref $_[0] eq 'Git' ? @_ : (undef, @_);
>> + UNIVERSAL::isa($_[0], 'Git') ? @_ : (undef, @_);
>> }
>>
>> # Check if the command id is something reasonable.
>>
>
> The patch looks Ok, as long as you have a working UNIVERSAL::isa() in your
> version of Perl. My reading of perl561delta,pod says that Perl 5.6.1 and
> later should have a working implementation.
>
From http://perldoc.perl.org/perl561delta.html:
> UNIVERSAL::isa()
>
> A bug in the caching mechanism used by UNIVERSAL::isa() that affected
> base.pm has been fixed. The bug has existed since the 5.005 releases,
> but wasn't tickled by base.pm in those releases.
This looks like only a bug in some (corner?) cases; I've verified that
I've been using the isa() method *or* function since perl 5.005_03, and
haven't had issues with it. I can't easily verify though when I switched
from
#if (Scalar::Util::blessed($value) and $value->isa("Eile::Html")) {
to
if (UNIVERSAL::isa($value,"Eile::Html")) {
(because it was simpler to write, once I discovered that I could just
call the function directly instead of relying on method dispatch) but
that might not have made a difference.
Christian.
^ permalink raw reply
* Re: git-svn url-encodes ~ when it should not
From: Björn Steinbrink @ 2008-10-18 22:47 UTC (permalink / raw)
To: Eric Wong; +Cc: git, jsogo
In-Reply-To: <20081018213919.GC3107@atjola.homenet>
[Adding Jose to Cc:, didn't have his address earlier]
On 2008.10.18 23:39:19 +0200, Björn Steinbrink wrote:
> Hi,
>
> Jose Carlos Garcia Sogo reported on #git that a git-svn clone of this
> svn repo fails for him:
> https://sucs.org/~welshbyte/svn/backuptool/trunk
>
> I can reproduce that here with:
> git-svn version 1.6.0.2.541.g46dc1.dirty (svn 1.5.1)
>
> The error message I get is:
> Apache got a malformed URI: Unusable URI: it does not refer to this
> repository at /usr/local/libexec/git-core/git-svn line 4057
>
> strace revealed that git-svn url-encodes ~ while svn does not do that.
>
> For svn we have:
> write(5, "<S:update-report send-all=\"true\" xmlns:S=\"svn:\">
> <S:src-path>https://sucs.org/~welshbyte/svn/backuptool/trunk</S:src-path>...
>
> While git-svn shows:
> write(7, "<S:update-report send-all=\"true\" xmlns:S=\"svn:\">
> <S:src-path>https://sucs.org/%7Ewelshbyte/svn/backuptool/trunk</S:src-path>...
>
> Björn
^ permalink raw reply
* Re: [PATCH] feature request: git-mergetool --force
From: Charles Bailey @ 2008-10-18 23:16 UTC (permalink / raw)
To: Jeff King; +Cc: William Pursell, git
In-Reply-To: <20081018205443.GA29534@coredump.intra.peff.net>
Jeff King wrote:
> On Sat, Oct 18, 2008 at 07:44:47PM +0100, William Pursell wrote:
>
>>> Something like --no-prompt makes more sense to me, though probably
>>> something a little easier to type would be nice (or maybe alias "-n").
>> Actually, perhaps an "interactive=no" configuration setting,
>> which might imply trustExitCode = true.
>
> That sounds reasonable to me.
>
> -Peff
I've recently been using git mergetool quite a bit and I'm currently
cooking a couple of patches. The first, by coincidence, was a "-n"
option which disabled the hit-return-to-actually-do-anything prompt. I,
also, used the variable "NOPROMPT" to describe this behaviour.
The other change that I am working was more of an issue for me. When I
have a fair number of files to merge I sometimes want to skip a merge.
Perhaps it's a tricky one and I want do the easy wins first.
The current behaviour of mergetool is a little annoying for this as the
first 'failed' merge aborts the process and if you restart it will
always pick up from where it left off. If you want to do some of the
later files, you have to specify the full paths to mergetool which can
be a lot more typing.
The change I am implementing just continues after a failed merge (no git
add or anything, so the file stays unmerged) and allows you to merge
subsequent files. I think that this will work reasonably well allowing
you to do your merges in a number of passes, picking off the easy merges
first and doing the tricky ones later. You can also do a quick pass
through all the merges, not actually resolving everything just to see if
there are any show stoppers.
The only gotcha is that this may interact less well with a --no-prompt
option. With the prompt you can always abort the mergetool process with
a SIGINT at the prompt, even if mergetool now wants to offer you the
opportunity to merge subsequent files after aborting one particular file
merge. Without the prompt mergetool is going to spawn your merge tool
for every conflict even if you've changed your mind and want to abort.
Thoughts?
Charles.
^ permalink raw reply
* Re: [PATCHv6 1/5] gitweb: parse project/action/hash_base:filename PATH_INFO
From: Jakub Narebski @ 2008-10-18 22:41 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <1224188831-17767-2-git-send-email-giuseppe.bilotta@gmail.com>
On Thu, 16 Oct 2008, Giuseppe Bilotta wrote:
> This patch enables gitweb to parse URLs with more information embedded
> in PATH_INFO, reducing the need for CGI parameters. The typical gitweb
> path is now $project/$action/$hash_base:$file_name or
> $project/$action/$hash
>
> This is mostly backwards compatible with the old-style gitweb paths,
> $project/$branch[:$filename], except when it was used to access a branch
> whose name matches a gitweb action.
...in which case old code would access branch, and new code would treat
name as action. This shouldn't matter in practice, unless there are
branches named exactly as gitweb actions.
[But I think current commit description is enough. Just in case...]
>
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
I like it. For what it is worth:
Acked-by: Jakub Narebski <jnareb@gmail.com>
> ---
> gitweb/gitweb.perl | 37 +++++++++++++++++++++++++++++++------
> 1 files changed, 31 insertions(+), 6 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index c5254af..6d0dc26 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -534,23 +534,48 @@ sub evaluate_path_info {
> return if $input_params{'action'};
> $path_info =~ s,^\Q$project\E/*,,;
>
> + # next, check if we have an action
> + my $action = $path_info;
> + $action =~ s,/.*$,,;
> + if (exists $actions{$action}) {
> + $path_info =~ s,^$action/*,,;
> + $input_params{'action'} = $action;
> + }
> +
> + # list of actions that want hash_base instead of hash
...and can have no file_name ('f') parameter.
> + my @wants_base = (
> + 'tree',
> + 'history',
> + );
I like this solution. It makes path_info URL unambiguous: it is
<project>/log/<hash> (where <hash> is usually refname), and
<project>/tree/<hash_base> which is just shortcut for <project>/tree/<hash_base>:/
It means that the @wants_base list contains actions which require / use
$hash_base and $file_name, but $file_name might be not set, which denotes
top directory (root tree).
> +
> my ($refname, $pathname) = split(/:/, $path_info, 2);
> if (defined $pathname) {
> - # we got "project.git/branch:filename" or "project.git/branch:dir/"
> + # we got "branch:filename" or "branch:dir/"
> # we could use git_get_type(branch:pathname), but it needs $git_dir
Well, this comment was there... but actually I think we avoid
git_get_type("branch:pathname") because currently it is additional fork.
And with convention that filename part of path_info ends in '/' for
directories (quite sensible I think) it is not needed. Moreso after
next patch in series, when we state action explicitly, and the only
difference _might_ be for 'history' view (which is for directories
and for files both).
> $pathname =~ s,^/+,,;
> if (!$pathname || substr($pathname, -1) eq "/") {
> - $input_params{'action'} = "tree";
> + $input_params{'action'} ||= "tree";
> $pathname =~ s,/$,,;
> } else {
> - $input_params{'action'} = "blob_plain";
> + $input_params{'action'} ||= "blob_plain";
> }
> $input_params{'hash_base'} ||= $refname;
> $input_params{'file_name'} ||= $pathname;
> } elsif (defined $refname) {
> - # we got "project.git/branch"
> - $input_params{'action'} = "shortlog";
> - $input_params{'hash'} ||= $refname;
> + # we got "branch". in this case we have to choose if we have to
^ ^
|-|-- ??? (typo?)
> + # set hash or hash_base.
> + #
> + # Most of the actions without a pathname only want hash to be
> + # set, except for the ones specified in @wants_base that want
> + # hash_base instead. It should also be noted that hand-crafted
> + # links having 'history' as an action and no pathname or hash
> + # set will fail, but that happens regardless of PATH_INFO.
Ah, I see that the comment about what makes action to be put into
@wants_base is here.
> + $input_params{'action'} ||= "shortlog";
> + if (grep {$input_params{'action'} eq $_} @wants_base) {
Style: I would use here (but perhaps it is just me) for better
readibility
+ if (grep { $input_params{'action'} eq $_ } @wants_base) {
> + $input_params{'hash_base'} ||= $refname;
> + } else {
> + $input_params{'hash'} ||= $refname;
> + }
> }
> }
> evaluate_path_info();
> --
> 1.5.6.5
>
>
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCHv6 2/5] gitweb: generate project/action/hash URLs
From: Jakub Narebski @ 2008-10-18 23:14 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <1224188831-17767-3-git-send-email-giuseppe.bilotta@gmail.com>
On Thu, 16 Oct 2008, Giuseppe Bilotta wrote:
> When generating path info URLs, reduce the number of CGI parameters by
> embedding action and hash_parent:filename or hash in the path.
>
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Nice, well commented, and clean.
Acked-by: Jakub Narebski <jnareb@gmail.com>
> ---
> gitweb/gitweb.perl | 33 ++++++++++++++++++++++++++++++---
> 1 files changed, 30 insertions(+), 3 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 6d0dc26..5337d40 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -724,14 +724,41 @@ sub href (%) {
>
> my ($use_pathinfo) = gitweb_check_feature('pathinfo');
> if ($use_pathinfo) {
> - # use PATH_INFO for project name
> + # try to put as many parameters as possible in PATH_INFO:
> + # - project name
> + # - action
> + # - hash or hash_base:filename
> +
> + # When the script is the root DirectoryIndex for the domain,
> + # $href here would be something like http://gitweb.example.com/
> + # Thus, we strip any trailing / from $href, to spare us double
> + # slashes in the final URL
> + $href =~ s,/$,,;
I like having this comment here.
> +
> + # Then add the project name, if present
> $href .= "/".esc_url($params{'project'}) if defined $params{'project'};
> delete $params{'project'};
>
> - # Summary just uses the project path URL
> - if (defined $params{'action'} && $params{'action'} eq 'summary') {
> + # Summary just uses the project path URL, any other action is
> + # added to the URL
Which meant that we prefer http://base_url/project over http://base_url/project/summary
> + if (defined $params{'action'}) {
> + $href .= "/".esc_url($params{'action'}) unless $params{'action'} eq 'summary';
> delete $params{'action'};
> }
> +
> + # Finally, we put either hash_base:file_name or hash
> + if (defined $params{'hash_base'}) {
> + $href .= "/".esc_url($params{'hash_base'});
> + if (defined $params{'file_name'}) {
> + $href .= ":".esc_url($params{'file_name'});
> + delete $params{'file_name'};
> + }
> + delete $params{'hash'};
> + delete $params{'hash_base'};
> + } elsif (defined $params{'hash'}) {
> + $href .= "/".esc_url($params{'hash'});
> + delete $params{'hash'};
> + }
> }
>
> # now encode the parameters explicitly
> --
> 1.5.6.5
>
>
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCHv6 3/5] gitweb: use_pathinfo filenames start with /
From: Jakub Narebski @ 2008-10-18 23:26 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <1224188831-17767-4-git-send-email-giuseppe.bilotta@gmail.com>
On Thu, 16 Oct 2008, Giuseppe Bilotta wrote:
> When using path info, make filenames start with a / (right after the :
> that separates them from the hash base). This minimal change allows
> relative navigation to work properly when viewing HTML files in raw
> ('blob_plain') mode.
This means generating project/action/hash_base:/filename rather than
earlier project/action/hash_base:filename, isn't it?
For example for http://repo.or.cz/w/git.git/html:/git.html links leads
to correct HTML pages, while for http://repo.or.cz/w/git.git/html:git.html
they lead to empty gitweb page (no errors, so link checker would be
fooled).
>
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Acked-by: Jakub Narebski <jnareb@gmail.com>
> ---
> gitweb/gitweb.perl | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 5337d40..49730f3 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -727,7 +727,7 @@ sub href (%) {
> # try to put as many parameters as possible in PATH_INFO:
> # - project name
> # - action
> - # - hash or hash_base:filename
> + # - hash or hash_base:/filename
>
> # When the script is the root DirectoryIndex for the domain,
> # $href here would be something like http://gitweb.example.com/
> @@ -746,11 +746,11 @@ sub href (%) {
> delete $params{'action'};
> }
>
> - # Finally, we put either hash_base:file_name or hash
> + # Finally, we put either hash_base:/file_name or hash
> if (defined $params{'hash_base'}) {
> $href .= "/".esc_url($params{'hash_base'});
> if (defined $params{'file_name'}) {
> - $href .= ":".esc_url($params{'file_name'});
> + $href .= ":/".esc_url($params{'file_name'});
> delete $params{'file_name'};
> }
> delete $params{'hash'};
> --
> 1.5.6.5
>
>
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCHv6 3/5] gitweb: use_pathinfo filenames start with /
From: Giuseppe Bilotta @ 2008-10-18 23:57 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <200810190126.06697.jnareb@gmail.com>
On Sun, Oct 19, 2008 at 1:26 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Thu, 16 Oct 2008, Giuseppe Bilotta wrote:
>
>> When using path info, make filenames start with a / (right after the :
>> that separates them from the hash base). This minimal change allows
>> relative navigation to work properly when viewing HTML files in raw
>> ('blob_plain') mode.
>
> This means generating project/action/hash_base:/filename rather than
> earlier project/action/hash_base:filename, isn't it?
Exactly. We _accept_ paths with or without the /, but we always
generate paths with it.
> For example for http://repo.or.cz/w/git.git/html:/git.html links leads
> to correct HTML pages, while for http://repo.or.cz/w/git.git/html:git.html
> they lead to empty gitweb page (no errors, so link checker would be
> fooled).
An idea that could be taken into consideration, if the ability to
navigate web documents is deemed of primary importance, would be a
redirect from the no-slash URL (a hand-coded one, given that with this
patch we only generate slashed URLs) to the slashed URL. Not sure it's
worth the effort (and reparsing) though: it would obviously be MUCH
nicer if we could change the URL without having to actually reload the
document ...
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* [PATCH] -C/--chdir command line option
From: Maciej Pasternacki @ 2008-10-19 0:02 UTC (permalink / raw)
To: git
In my project cl-librarian, which is a layer built upon different
version control systems, I need to run git pull, but start it from
outside of work tree; however, pull needs to be in work tree (as in
getcwd()) in order to update said work tree. --git-dir and
--work-tree options don't work; I discussed it on #git yesterday,
and it turned out that this issue is nontrivial:
231701 <doener> hm, require_work_tree checks if you are _in_ the work tree,
and pull only switches to the work tree after the require_work_tree
call...
231710 <doener> looks like a chicken-egg-problem
231715 <shd> japhy`: spawning commands requires forking anyway, so do chdir in
forked process
231739 <doener> if you move the "cd_to_toplevel" call up in git-push, so that
it happens before require_work_tree, then it works
231747 <japhy`> shd: yup, that would be a workaround, but I tried to avoid
shell-quoting ;)
231749 <japhy`> doener: push?
231756 <doener> ehrm, pull
channel #git
231820 <doener> but I guess doing the cd_to_toplevel first might break somehow
if there is no working tree...
231843 <japhy`> Oh.
231922 <doener> I'd just ask on the list about that.
I don't like the idea of doing chdir() myself -- this would expose me to a
whole world of portability issues, and I don't feel like spending time to
figure out how to do a fork on windows ;) the best workaround that occured to
me was adding -C/--chdir option to main git binary, like one that Make accepts.
This fixed my problem, I paste the resulting patch below:
>From 4461cd1be99772c93a83bcdfe6e6a86e71abaa35 Mon Sep 17 00:00:00 2001
From: Maciej Pasternacki <maciej@pasternacki.net>
Date: Sun, 19 Oct 2008 01:33:49 +0200
Subject: [PATCH] Add command line option --chdir/-C to allow setting git process work directory.
Signed-off-by: Maciej Pasternacki <maciej@pasternacki.net>
---
Documentation/git.txt | 6 +++++-
git.c | 9 ++++++++-
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/Documentation/git.txt b/Documentation/git.txt
index df420ae..6676d68 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -12,7 +12,7 @@ SYNOPSIS
'git' [--version] [--exec-path[=GIT_EXEC_PATH]]
[-p|--paginate|--no-pager]
[--bare] [--git-dir=GIT_DIR] [--work-tree=GIT_WORK_TREE]
- [--help] COMMAND [ARGS]
+ [-C DIRECTORY|--chdir=DIRECTORY] [--help] COMMAND [ARGS]
DESCRIPTION
-----------
@@ -185,6 +185,10 @@ help ...`.
environment is not set, it is set to the current working
directory.
+-C <directory>::
+--chdir=<directory>::
+ Change working directory before doing anything.
+
FURTHER DOCUMENTATION
---------------------
diff --git a/git.c b/git.c
index 89feb0b..8c97671 100644
--- a/git.c
+++ b/git.c
@@ -115,7 +115,14 @@ static int handle_options(const char*** argv, int* argc, int* envchanged)
setenv(GIT_DIR_ENVIRONMENT, getcwd(git_dir, sizeof(git_dir)), 0);
if (envchanged)
*envchanged = 1;
- } else {
+ } else if (!strcmp(cmd, "-C") || !strcmp(cmd, "--chdir")) {
+ chdir((*argv)[1]);
+ (*argv)++;
+ (*argc)--;
+ handled++;
+ } else if (!prefixcmp(cmd,"--chdir=")) {
+ chdir(cmd+8);
+ } else {
fprintf(stderr, "Unknown option: %s\n", cmd);
usage(git_usage_string);
}
--
1.6.0.1
^ permalink raw reply related
* [PATCH] git-merge-recursive: honor merge.conflictstyle once again
From: Matt McCutchen @ 2008-10-19 0:40 UTC (permalink / raw)
To: git
This was originally implemented in c236bcd06138bcbc929b86ad1a513635bf4847b2
but was lost to a mismerge in 9ba929ed652f5ed7707f1c684999af4ad02c4925.
Signed-off-by: Matt McCutchen <matt@mattmccutchen.net>
---
merge-recursive.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index 245232a..7472d3e 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -1332,7 +1332,7 @@ static int merge_recursive_config(const char *var, const char *value, void *cb)
o->merge_rename_limit = git_config_int(var, value);
return 0;
}
- return git_default_config(var, value, cb);
+ return git_xmerge_config(var, value, cb);
}
void init_merge_options(struct merge_options *o)
--
1.6.0.2.545.g6cb4a
^ permalink raw reply related
* "git checkout: --track and --no-track require -b" check accidentally resurrected?
From: Matt McCutchen @ 2008-10-19 0:54 UTC (permalink / raw)
To: git
Merge commit 9ba929ed resurrected the following two-line check, which
was removed in the first parent and unchanged in the second:
if (!opts.new_branch && (opts.track != git_branch_track))
die("git checkout: --track and --no-track require -b");
Is this intentional? Does it make a difference?
(I noticed this while carefully examining 9ba929ed to find out why "git
merge" stopped honoring merge.conflictstyle. Ironically, I hit this bug
again during the examination.)
Matt
^ permalink raw reply
* Re: [PATCH] Documentation: diff-filter=T only tests for symlink changes
From: Nanako Shiraishi @ 2008-10-19 1:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Anders Melchiorsen, git
In-Reply-To: <87vdvq5lu4.fsf_-_@cup.kalibalik.dk>
Quoting Junio C Hamano <gitster@pobox.com>:
>
> Nanako Shiraishi <nanako3@lavabit.com> writes:
>
>> Quoting Anders Melchiorsen <mail@cup.kalibalik.dk>:
>>
>>> diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
>>> index 7788d4f..7604a13 100644
>>> --- a/Documentation/diff-options.txt
>>> +++ b/Documentation/diff-options.txt
>>> @@ -137,7 +137,7 @@ endif::git-format-patch[]
>>> --diff-filter=[ACDMRTUXB*]::
>>> Select only files that are Added (`A`), Copied (`C`),
>>> Deleted (`D`), Modified (`M`), Renamed (`R`), have their
>>> - type (mode) changed (`T`), are Unmerged (`U`), are
>>> + type (symlink/regular file) changed (`T`), are Unmerged (`U`), are
>>> Unknown (`X`), or have had their pairing Broken (`B`).
>>> Any combination of the filter characters may be used.
>>> When `*` (All-or-none) is added to the combination, all
>>> --
>>> 1.6.0.2.514.g23abd3
>>
>> Are symlinks and regular files the only kind of object you can see in
>> diff? What happens when a file or directory changes to a submodule?
>
> Oops. I've already applied Anders's patch, but you are right. A change
> from a blob to submodule also shows up as a typechange event.
>
> Perhaps we should just remove the parenthesised comment from there
> instead. I'll rewind and rebuild, as I haven't pushed the results out
> yet (lucky me).
I see that you pushed out this change already, and you changed your mind and described them all. I think the result reads better.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* [PATCH] config.txt: alphabetize configuration variable groups
From: Matt McCutchen @ 2008-10-19 1:42 UTC (permalink / raw)
To: git
Signed-off-by: Matt McCutchen <matt@mattmccutchen.net>
---
Documentation/config.txt | 96 +++++++++++++++++++++++-----------------------
1 files changed, 48 insertions(+), 48 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index da18a54..704d1bb 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -570,9 +570,6 @@ color.status.<slot>::
to red). The values of these variables may be specified as in
color.branch.<slot>.
-commit.template::
- Specify a file to use as the template for new commit messages.
-
color.ui::
When set to `always`, always use colors in all git commands which
are capable of colored output. When false (or `never`), never. When
@@ -580,6 +577,9 @@ color.ui::
terminal. When more specific variables of color.* are set, they always
take precedence over this setting. Defaults to false.
+commit.template::
+ Specify a file to use as the template for new commit messages.
+
diff.autorefreshindex::
When using 'git-diff' to compare with work tree
files, do not consider stat-only change as changed.
@@ -711,18 +711,6 @@ gc.rerereunresolved::
kept for this many days when 'git-rerere gc' is run.
The default is 15 days. See linkgit:git-rerere[1].
-rerere.autoupdate::
- When set to true, `git-rerere` updates the index with the
- resulting contents after it cleanly resolves conflicts using
- previously recorded resolution. Defaults to false.
-
-rerere.enabled::
- Activate recording of resolved conflicts, so that identical
- conflict hunks can be resolved automatically, should they
- be encountered again. linkgit:git-rerere[1] command is by
- default enabled if you create `rr-cache` directory under
- `$GIT_DIR`, but can be disabled by setting this option to false.
-
gitcvs.enabled::
Whether the CVS server interface is enabled for this repository.
See linkgit:git-cvsserver[1].
@@ -890,6 +878,10 @@ i18n.logOutputEncoding::
Character encoding the commit messages are converted to when
running 'git-log' and friends.
+imap::
+ The configuration variables in the 'imap' section are described
+ in linkgit:git-imap-send[1].
+
instaweb.browser::
Specify the program that will be used to browse your working
repository in gitweb. See linkgit:git-instaweb[1].
@@ -925,8 +917,6 @@ man.viewer::
Specify the programs that may be used to display help in the
'man' format. See linkgit:git-help[1].
-include::merge-config.txt[]
-
man.<tool>.cmd::
Specify the command to invoke the specified man viewer. The
specified command is evaluated in shell with the man page
@@ -936,6 +926,8 @@ man.<tool>.path::
Override the path for the given tool that may be used to
display help in the 'man' format. See linkgit:git-help[1].
+include::merge-config.txt[]
+
merge.conflictstyle::
Specify the style in which conflicted hunks are written out to
working tree files upon merge. The default is "merge", which
@@ -1052,6 +1044,28 @@ pull.octopus::
pull.twohead::
The default merge strategy to use when pulling a single branch.
+receive.fsckObjects::
+ If it is set to true, git-receive-pack will check all received
+ objects. It will abort in the case of a malformed object or a
+ broken link. The result of an abort are only dangling objects.
+ Defaults to false.
+
+receive.unpackLimit::
+ If the number of objects received in a push is below this
+ limit then the objects will be unpacked into loose object
+ files. However if the number of received objects equals or
+ exceeds this limit then the received pack will be stored as
+ a pack, after adding any missing delta bases. Storing the
+ pack from a push can make the push operation complete faster,
+ especially on slow filesystems. If not set, the value of
+ `transfer.unpackLimit` is used instead.
+
+receive.denyNonFastForwards::
+ If set to true, git-receive-pack will deny a ref update which is
+ not a fast forward. Use this to prevent such an update via a push,
+ even if that push is forced. This configuration variable is
+ set when initializing a shared repository.
+
remote.<name>.url::
The URL of a remote repository. See linkgit:git-fetch[1] or
linkgit:git-push[1].
@@ -1101,6 +1115,18 @@ repack.usedeltabaseoffset::
"false" and repack. Access from old git versions over the
native protocol are unaffected by this option.
+rerere.autoupdate::
+ When set to true, `git-rerere` updates the index with the
+ resulting contents after it cleanly resolves conflicts using
+ previously recorded resolution. Defaults to false.
+
+rerere.enabled::
+ Activate recording of resolved conflicts, so that identical
+ conflict hunks can be resolved automatically, should they
+ be encountered again. linkgit:git-rerere[1] command is by
+ default enabled if you create `rr-cache` directory under
+ `$GIT_DIR`, but can be disabled by setting this option to false.
+
showbranch.default::
The default set of branches for linkgit:git-show-branch[1].
See linkgit:git-show-branch[1].
@@ -1137,6 +1163,11 @@ tar.umask::
archiving user's umask will be used instead. See umask(2) and
linkgit:git-archive[1].
+transfer.unpackLimit::
+ When `fetch.unpackLimit` or `receive.unpackLimit` are
+ not set, the value of this variable is used instead.
+ The default value is 100.
+
url.<base>.insteadOf::
Any URL that starts with this value will be rewritten to
start, instead, with <base>. In cases where some site serves a
@@ -1165,37 +1196,6 @@ user.signingkey::
unchanged to gpg's --local-user parameter, so you may specify a key
using any method that gpg supports.
-imap::
- The configuration variables in the 'imap' section are described
- in linkgit:git-imap-send[1].
-
-receive.fsckObjects::
- If it is set to true, git-receive-pack will check all received
- objects. It will abort in the case of a malformed object or a
- broken link. The result of an abort are only dangling objects.
- Defaults to false.
-
-receive.unpackLimit::
- If the number of objects received in a push is below this
- limit then the objects will be unpacked into loose object
- files. However if the number of received objects equals or
- exceeds this limit then the received pack will be stored as
- a pack, after adding any missing delta bases. Storing the
- pack from a push can make the push operation complete faster,
- especially on slow filesystems. If not set, the value of
- `transfer.unpackLimit` is used instead.
-
-receive.denyNonFastForwards::
- If set to true, git-receive-pack will deny a ref update which is
- not a fast forward. Use this to prevent such an update via a push,
- even if that push is forced. This configuration variable is
- set when initializing a shared repository.
-
-transfer.unpackLimit::
- When `fetch.unpackLimit` or `receive.unpackLimit` are
- not set, the value of this variable is used instead.
- The default value is 100.
-
web.browser::
Specify a web browser that may be used by some commands.
Currently only linkgit:git-instaweb[1] and linkgit:git-help[1]
--
1.6.0.2.545.g6cb4a
^ permalink raw reply related
* [PATCH] Documentation: Clarify '--signoff' for git-commit
From: Abhijit Bhopatkar @ 2008-10-19 4:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfxmuec46.fsf@gitster.siamese.dyndns.org>
'--signoff' uses commiter name always to add the signoff line,
make it explicit in the documentation.
Signed-off-by: Abhijit Bhopatkar <bain@devslashzero.com>
---
Documentation/git-commit.txt | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index eb05b0f..713ab0a 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -94,7 +94,8 @@ OPTIONS
-s::
--signoff::
- Add Signed-off-by line at the end of the commit message.
+ Add Signed-off-by line by the commiter at the end of the commit
+ log message.
-n::
--no-verify::
--
1.5.6.3
^ permalink raw reply related
* [PATCH] git-format-patch(1)- add note about creating patch for single commit
From: Dan McGee @ 2008-10-19 4:54 UTC (permalink / raw)
To: git; +Cc: Dan McGee
Signed-off-by: Dan McGee <dpmcgee@gmail.com>
---
I thought this would be helpful because it took me the beter part of an hour
to find a solution instead of specifying C~1..C or other crazy things. The
current documentation just leaves you hanging when what you really want is
just one formatted patch.
If there any suggestions on better wording, feel free to resubmit or whatever-
I just felt like this should be documented somewhere.
Documentation/git-format-patch.txt | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index adb4ea7..8518c33 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -46,7 +46,9 @@ applies to that command line and you do not get "everything
since the beginning of the time". If you want to format
everything since project inception to one commit, say "git
format-patch \--root <commit>" to make it clear that it is the
-latter case.
+latter case. If you want to format only a single commit, say "git
+format-patch <commit>^!" (which excludes all parent revisions of the
+specified commit).
By default, each output file is numbered sequentially from 1, and uses the
first line of the commit message (massaged for pathname safety) as
--
1.6.0.2
^ permalink raw reply related
* Re: [PATCH] git-format-patch(1)- add note about creating patch for single commit
From: Junio C Hamano @ 2008-10-19 5:21 UTC (permalink / raw)
To: Dan McGee; +Cc: git
In-Reply-To: <1224392084-12956-1-git-send-email-dpmcgee@gmail.com>
Dan McGee <dpmcgee@gmail.com> writes:
> Signed-off-by: Dan McGee <dpmcgee@gmail.com>
> ---
>
> I thought this would be helpful because it took me the beter part of an hour
> to find a solution instead of specifying C~1..C or other crazy things. The
> current documentation just leaves you hanging when what you really want is
> just one formatted patch.
>
> If there any suggestions on better wording, feel free to resubmit or whatever-
> I just felt like this should be documented somewhere.
>
> Documentation/git-format-patch.txt | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
> index adb4ea7..8518c33 100644
> --- a/Documentation/git-format-patch.txt
> +++ b/Documentation/git-format-patch.txt
> @@ -46,7 +46,9 @@ applies to that command line and you do not get "everything
> since the beginning of the time". If you want to format
> everything since project inception to one commit, say "git
> format-patch \--root <commit>" to make it clear that it is the
> -latter case.
> +latter case. If you want to format only a single commit, say "git
> +format-patch <commit>^!" (which excludes all parent revisions of the
> +specified commit).
>
> By default, each output file is numbered sequentially from 1, and uses the
> first line of the commit message (massaged for pathname safety) as
Heh, a more natural way to say that is:
git format-patch -1 $that_one
That uses the first option described in the documentation:
-<n>::
Limits the number of patches to prepare.
^ permalink raw reply
* Re: [PATCH] git-format-patch(1)- add note about creating patch for single commit
From: Dan McGee @ 2008-10-19 5:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1vyd9n3d.fsf@gitster.siamese.dyndns.org>
On Sun, Oct 19, 2008 at 12:21 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Dan McGee <dpmcgee@gmail.com> writes:
>
>> Signed-off-by: Dan McGee <dpmcgee@gmail.com>
>> ---
>>
>> I thought this would be helpful because it took me the beter part of an hour
>> to find a solution instead of specifying C~1..C or other crazy things. The
>> current documentation just leaves you hanging when what you really want is
>> just one formatted patch.
>>
>> If there any suggestions on better wording, feel free to resubmit or whatever-
>> I just felt like this should be documented somewhere.
>>
>> Documentation/git-format-patch.txt | 4 +++-
>> 1 files changed, 3 insertions(+), 1 deletions(-)
>>
>> diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
>> index adb4ea7..8518c33 100644
>> --- a/Documentation/git-format-patch.txt
>> +++ b/Documentation/git-format-patch.txt
>> @@ -46,7 +46,9 @@ applies to that command line and you do not get "everything
>> since the beginning of the time". If you want to format
>> everything since project inception to one commit, say "git
>> format-patch \--root <commit>" to make it clear that it is the
>> -latter case.
>> +latter case. If you want to format only a single commit, say "git
>> +format-patch <commit>^!" (which excludes all parent revisions of the
>> +specified commit).
>>
>> By default, each output file is numbered sequentially from 1, and uses the
>> first line of the commit message (massaged for pathname safety) as
>
> Heh, a more natural way to say that is:
>
> git format-patch -1 $that_one
>
> That uses the first option described in the documentation:
>
> -<n>::
> Limits the number of patches to prepare.
Wow, had no idea about that option. :)
Given that I didn't even notice this option when I did go to the
manpage, what if my above change was instead reworked a bit:
>> +latter case. If you want to format only a single commit, say "git
>> +format-patch -1 <commit>" .
^ permalink raw reply
* Re: [PATCH] git-format-patch(1)- add note about creating patch for single commit
From: Junio C Hamano @ 2008-10-19 5:33 UTC (permalink / raw)
To: Dan McGee; +Cc: Junio C Hamano, git
In-Reply-To: <449c10960810182226t5e2ae1ay4b53656a7cac4606@mail.gmail.com>
"Dan McGee" <dpmcgee@gmail.com> writes:
> On Sun, Oct 19, 2008 at 12:21 AM, Junio C Hamano <gitster@pobox.com> wrote:
>
>> Heh, a more natural way to say that is:
>>
>> git format-patch -1 $that_one
>>
>> That uses the first option described in the documentation:
>>
>> -<n>::
>> Limits the number of patches to prepare.
>
> Wow, had no idea about that option. :)
>
> Given that I didn't even notice this option when I did go to the
> manpage, what if my above change was instead reworked a bit:
>>> +latter case. If you want to format only a single commit, say "git
>>> +format-patch -1 <commit>" .
I thought about it, but saw "formatting three commits" example in the
manpage, and stopped there ;-)
^ permalink raw reply
* Re: git-svn crashing perl
From: Heinrich Nirschl @ 2008-10-19 6:39 UTC (permalink / raw)
To: Alex Bennee; +Cc: git
In-Reply-To: <b2cdc9f30810181500u357ce6e2tb8bef4fd559e89d3@mail.gmail.com>
On Sun, Oct 19, 2008 at 12:00 AM, Alex Bennee <kernel-hacker@bennee.com> wrote:
> Looks similar. libapr certainly seems to be breaking something:
>
>
> Core was generated by `/usr/bin/perl
> /home/alex/src/git.git/install/libexec/git-core/git-svn fetch --f'.
> Program terminated with signal 11, Segmentation fault.
> #0 0x00007fd0d813c370 in ?? ()
> (gdb) bt
> #0 0x00007fd0d813c370 in ?? ()
> #1 0x00007fd0d9a52a5d in ?? () from /usr/lib/libapr-1.so.0
> #2 0x00007fd0d9a53d9a in ?? () from /usr/lib/libapr-1.so.0
> #3 0x00007fd0d9a54003 in ?? () from /usr/lib/libapr-1.so.0
> #4 0x00007fd0d9a53d88 in ?? () from /usr/lib/libapr-1.so.0
> #5 0x00007fd0d9a54003 in ?? () from /usr/lib/libapr-1.so.0
> #6 0x00007fd0d9a540f3 in apr_pool_terminate () from /usr/lib/libapr-1.so.0
> #7 0x00007fd0db1c6e83 in _wrap_apr_terminate () from
> /usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux/auto/SVN/_Core/_Core.so
> #8 0x000000000047dbab in Perl_pp_entersub ()
> #9 0x00000000004677fa in Perl_runops_debug ()
> #10 0x0000000000425ae8 in Perl_call_sv ()
> #11 0x0000000000425faa in Perl_call_list ()
> #12 0x000000000042a0e8 in perl_destruct ()
> #13 0x0000000000422238 in main ()
I found another bug report that seems to be related
http://bugs.gentoo.org/show_bug.cgi?id=223747
There is a workaround mentioned: disable runtime-module-search when
building subversion.
^ permalink raw reply
* Re: What is the pre-merge hook status?
From: Alexander Gladysh @ 2008-10-19 6:51 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: git
In-Reply-To: <48FA5BBB.8060406@gnu.org>
On Sun, Oct 19, 2008 at 1:57 AM, Paolo Bonzini <bonzini@gnu.org> wrote:
> > What is the status of your pre-merge hook patch?
> >
> > http://article.gmane.org/gmane.comp.version-control.git/93888
> >
> > I think it can help me greatly with my repository management process.
>
> I decided that it was a bad design for me at least, because the control
> had better be implemented on the server (using an update hook). But I
> can submit it if you need it for something.
Please do. I've found that things in newbie user repo may become way
too entangled before branch gets to server. My users need an
early-warning system.
Thanks,
Alexander.
^ permalink raw reply
* [PATCH/RFR&A] Do not rename read-only files during a push
From: Junio C Hamano @ 2008-10-19 7:07 UTC (permalink / raw)
To: Petr Baudis, Johannes Sixt, Shawn O. Pearce; +Cc: git
This is on the "merged to 'master' soon" list, but has a small amend by me
(namely, chmod of final pack is done only when we are writing the final
pack, i.e. reading from stdin) to fix breakages observed in tests. It
would be nice to get a final Ack before moving it to 'master'.
-- >8 --
From: Petr Baudis <pasky@suse.cz>
Win32 does not allow renaming read-only files (at least on a Samba
share), making push into a local directory to fail. Thus, defer
the chmod() call in index-pack.c:final() only after
move_temp_to_file() was called.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
index-pack.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/index-pack.c b/index-pack.c
index d3a4d31..aec11cb 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -790,7 +790,6 @@ static void final(const char *final_pack_name, const char *curr_pack_name,
err = close(output_fd);
if (err)
die("error while closing pack file: %s", strerror(errno));
- chmod(curr_pack_name, 0444);
}
if (keep_msg) {
@@ -824,8 +823,9 @@ static void final(const char *final_pack_name, const char *curr_pack_name,
if (move_temp_to_file(curr_pack_name, final_pack_name))
die("cannot store pack file");
}
+ if (from_stdin)
+ chmod(final_pack_name, 0444);
- chmod(curr_index_name, 0444);
if (final_index_name != curr_index_name) {
if (!final_index_name) {
snprintf(name, sizeof(name), "%s/pack/pack-%s.idx",
@@ -835,6 +835,7 @@ static void final(const char *final_pack_name, const char *curr_pack_name,
if (move_temp_to_file(curr_index_name, final_index_name))
die("cannot store index file");
}
+ chmod(final_index_name, 0444);
if (!from_stdin) {
printf("%s\n", sha1_to_hex(sha1));
--
1.6.0.2.767.g8f0e
^ permalink raw reply related
* [PATCH/RFR&A] Fix reading of cloud tags
From: Junio C Hamano @ 2008-10-19 7:06 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
This is in 'next' but it would be nice to get acked before advancing it to
master.
-- >8 --
The projectroot path could have SP in it, in which case iterating over
<$git_dir/ctags/*> does not correctly enumerate the cloud tags files at
all.
This can be observed by creating an empty t/trash directory and running
t9500 test. The $projectroot ends with "trash directory.t9500-gitweb-/"
and <$glob> would give "trash", which can be opened and reading from it
immediately yields undef, which in turn gives an undef value warning to
the standard error stream upon attempt to chomp it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
gitweb/gitweb.perl | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 1116800..41b6866 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1805,7 +1805,10 @@ sub git_get_project_ctags {
my $ctags = {};
$git_dir = "$projectroot/$path";
- foreach (<$git_dir/ctags/*>) {
+ unless (opendir D, "$git_dir/ctags") {
+ return $ctags;
+ }
+ foreach (grep { -f $_ } map { "$git_dir/ctags/$_" } readdir(D)) {
open CT, $_ or next;
my $val = <CT>;
chomp $val;
@@ -1813,6 +1816,7 @@ sub git_get_project_ctags {
my $ctag = $_; $ctag =~ s#.*/##;
$ctags->{$ctag} = $val;
}
+ closedir D;
$ctags;
}
--
1.6.0.2.767.g8f0e
^ permalink raw reply related
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