* Re: [PATCH 06/14] t9501-*.sh: Fix a test failure on Cygwin
From: Ramsay Jones @ 2010-12-16 19:25 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, GIT Mailing-list, marada
In-Reply-To: <201012142004.30322.jnareb@gmail.com>
Jakub Narebski wrote:
> Ramsay Jones wrote:
>> The first (setup) test attempts to create a file, using the
>> test_commit function, called 'i can has snapshot?'. On cygwin
>> (and MinGW) this fails with a "No such file or directory" error.
>> In order to fix the tests, we simply remove the '?' wildcard
>> from the name, since the purpose of these tests is not about
>> creating funny filenames.
>>
>> Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
>
> All right.
>
> Acked-by: Jakub Narebski <jnareb@gmail.com>
Thanks.
> BTW. if the test was about handling funny filenames (containing
> leading, embedded and trailing space, +&@=<>"' characters), what
> should we do instead?
Hmm... dunno; take a look at t3600-rm.sh and t4135-apply-weird-filenames.sh
for inspiration? ;-)
Just FYI the "illegal" pathname characters in windows include:
< > : " / \ | ? *
along with control chars from 0 - 31.
Also, you can't have any trailing spaces or periods.
ATB,
Ramsay Jones
^ permalink raw reply
* Re: [PATCH 3/3] gitweb: remove test when closing file descriptor
From: Sylvain Rabot @ 2010-12-16 22:37 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3pqu4lx6n.fsf@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 2599 bytes --]
On Thu, 2010-12-16 at 14:30 -0800, Jakub Narebski wrote:
> Sylvain Rabot <sylvain@abstraction.fr> writes:
>
> > it happens that closing file descriptor fails whereas
> > the blob is perfectly readable.
> >
> > Signed-off-by: Sylvain Rabot <sylvain@abstraction.fr>
> > ---
> > gitweb/gitweb.perl | 3 +--
> > 1 files changed, 1 insertions(+), 2 deletions(-)
> >
> > diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> > index 9398475..9a885b1 100755
> > --- a/gitweb/gitweb.perl
> > +++ b/gitweb/gitweb.perl
> > @@ -3450,8 +3450,7 @@ sub run_highlighter {
> > my ($fd, $highlight, $syntax) = @_;
> > return $fd unless ($highlight && defined $syntax);
> >
> > - close $fd
> > - or die_error(404, "Reading blob failed");
> > + close $fd;
>
> Actually what I think happens is the following. "close $fh" cannot
> usually fail, unless (`perldoc -f close`):
>
> If the file handle came from a piped open, "close" will additionally
> return false if one of the other system calls involved fails, or if the
> program exits with non-zero status. (If the only problem was that the
> program exited non-zero, $! will be set to 0.) Closing a pipe also waits
> for the process executing on the pipe to complete, in case you want to
> look at the output of the pipe afterwards, and implicitly puts the exit
> status value of that command into $?.
>
> Prematurely closing the read end of a pipe (i.e. before the process writ-
> ing to it at the other end has closed it) will result in a SIGPIPE being
> delivered to the writer. If the other end can't handle that, be sure to
> read all the data before closing the pipe.
>
> In this place we close read end of pipe after at most reading a few
> bytes (what -T test does), so what might happen is that writer got
> SIGPIPE and "failed". But we are not interested in this, so we can
> safely ignore return from 'close'.
>
> I think that some from above explanation should make it to commit
> message.
Thanks for explaining it, I did not have any idea why it was failing.
Can I use your explanation as commit message ?
>
> > open $fd, quote_command(git_cmd(), "cat-file", "blob", $hash)." | ".
> > quote_command($highlight_bin).
> > " --xhtml --fragment --syntax $syntax |"
>
> P.S. A better solution would be to redirect opened $fd to highlighter,
> instead of closing and reopening a pipe... but I'm not sure how it
> could be implemented.
I don't know either.
>
--
Sylvain Rabot <sylvain@abstraction.fr>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] gitweb: add extensions to highlight feature
From: Sylvain Rabot @ 2010-12-16 22:33 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3y68slxj9.fsf@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 2089 bytes --]
On Thu, 2010-12-16 at 14:22 -0800, Jakub Narebski wrote:
> Sylvain Rabot <sylvain@abstraction.fr> writes:
>
> > added: sql, php5, phps, bash, zsh, mk
> >
>
> There is one issue with this patch (see below), but otherwise I like
> it.
>
> > Signed-off-by: Sylvain Rabot <sylvain@abstraction.fr>
> > ---
> > gitweb/gitweb.perl | 7 ++++---
> > 1 files changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> > index d521c93..db18d06 100755
> > --- a/gitweb/gitweb.perl
> > +++ b/gitweb/gitweb.perl
> > @@ -250,13 +250,14 @@ our %highlight_ext = (
> > # main extensions, defining name of syntax;
> > # see files in /usr/share/highlight/langDefs/ directory
> > map { $_ => $_ }
> > - qw(py c cpp rb java css php sh pl js tex bib xml awk bat ini spec tcl),
> > + qw(py c cpp rb java css php pl js tex bib xml awk bat ini spec tcl sql),
>
> Why did you remove 'sh' => 'sh' mapping? Shouldn't it be
>
> - qw(py c cpp rb java css php sh pl js tex bib xml awk bat ini spec tcl),
> + qw(py c cpp rb java css php sh pl js tex bib xml awk bat ini spec tcl sql),
>
I removed it on purpose but should have not, I was thinking
the mapping made below would be enough but no, you're right.
> > # alternate extensions, see /etc/highlight/filetypes.conf
> > 'h' => 'c',
> > + map { $_ => 'sh' } qw(bash zsh),
>
> Good idea.
Does ksh, csh can be highlighted as sh too ?
>
> > map { $_ => 'cpp' } qw(cxx c++ cc),
> > - map { $_ => 'php' } qw(php3 php4),
> > + map { $_ => 'php' } qw(php3 php4 php5 phps),
>
> Good idea.
>
> > map { $_ => 'pl' } qw(perl pm), # perhaps also 'cgi'
> > - 'mak' => 'make',
> > + map { $_ => 'make'} qw(mak mk),
>
> Good idea.
>
> Sidenote: git itself uses *.mak extension. Is *.mk popular?
Don't know but mk is mapped to Makefiles in the gtksourceview lib so I
added it here.
>
> > map { $_ => 'xml' } qw(xhtml html htm),
> > );
> >
> > --
> > 1.7.3.2
> >
>
--
Sylvain Rabot <sylvain@abstraction.fr>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3] gitweb: remove test when closing file descriptor
From: Jakub Narebski @ 2010-12-16 22:30 UTC (permalink / raw)
To: Sylvain Rabot; +Cc: git, Jakub Narebski
In-Reply-To: <1292535801-7421-4-git-send-email-sylvain@abstraction.fr>
Sylvain Rabot <sylvain@abstraction.fr> writes:
> it happens that closing file descriptor fails whereas
> the blob is perfectly readable.
>
> Signed-off-by: Sylvain Rabot <sylvain@abstraction.fr>
> ---
> gitweb/gitweb.perl | 3 +--
> 1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 9398475..9a885b1 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -3450,8 +3450,7 @@ sub run_highlighter {
> my ($fd, $highlight, $syntax) = @_;
> return $fd unless ($highlight && defined $syntax);
>
> - close $fd
> - or die_error(404, "Reading blob failed");
> + close $fd;
Actually what I think happens is the following. "close $fh" cannot
usually fail, unless (`perldoc -f close`):
If the file handle came from a piped open, "close" will additionally
return false if one of the other system calls involved fails, or if the
program exits with non-zero status. (If the only problem was that the
program exited non-zero, $! will be set to 0.) Closing a pipe also waits
for the process executing on the pipe to complete, in case you want to
look at the output of the pipe afterwards, and implicitly puts the exit
status value of that command into $?.
Prematurely closing the read end of a pipe (i.e. before the process writ-
ing to it at the other end has closed it) will result in a SIGPIPE being
delivered to the writer. If the other end can't handle that, be sure to
read all the data before closing the pipe.
In this place we close read end of pipe after at most reading a few
bytes (what -T test does), so what might happen is that writer got
SIGPIPE and "failed". But we are not interested in this, so we can
safely ignore return from 'close'.
I think that some from above explanation should make it to commit
message.
> open $fd, quote_command(git_cmd(), "cat-file", "blob", $hash)." | ".
> quote_command($highlight_bin).
> " --xhtml --fragment --syntax $syntax |"
P.S. A better solution would be to redirect opened $fd to highlighter,
instead of closing and reopening a pipe... but I'm not sure how it
could be implemented.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 2/3] gitweb: decorate a bit more remotes
From: Jakub Narebski @ 2010-12-16 22:23 UTC (permalink / raw)
To: Sylvain Rabot; +Cc: git, Jakub Narebski
In-Reply-To: <1292535801-7421-3-git-send-email-sylvain@abstraction.fr>
Sylvain Rabot <sylvain@abstraction.fr> writes:
> Signed-off-by: Sylvain Rabot <sylvain@abstraction.fr>
> ---
> gitweb/gitweb.perl | 8 ++++----
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index db18d06..9398475 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -5127,13 +5127,13 @@ sub git_remote_block {
>
> if (defined $fetch) {
> if ($fetch eq $push) {
> - $urls_table .= format_repo_url("URL", $fetch);
> + $urls_table .= format_repo_url("<strong>URL:</strong>", $fetch);
I would really prefer to use CSS for that...
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 1/3] gitweb: add extensions to highlight feature
From: Jakub Narebski @ 2010-12-16 22:22 UTC (permalink / raw)
To: Sylvain Rabot; +Cc: git, Jakub Narebski
In-Reply-To: <1292535801-7421-2-git-send-email-sylvain@abstraction.fr>
Sylvain Rabot <sylvain@abstraction.fr> writes:
> added: sql, php5, phps, bash, zsh, mk
>
There is one issue with this patch (see below), but otherwise I like
it.
> Signed-off-by: Sylvain Rabot <sylvain@abstraction.fr>
> ---
> gitweb/gitweb.perl | 7 ++++---
> 1 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index d521c93..db18d06 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -250,13 +250,14 @@ our %highlight_ext = (
> # main extensions, defining name of syntax;
> # see files in /usr/share/highlight/langDefs/ directory
> map { $_ => $_ }
> - qw(py c cpp rb java css php sh pl js tex bib xml awk bat ini spec tcl),
> + qw(py c cpp rb java css php pl js tex bib xml awk bat ini spec tcl sql),
Why did you remove 'sh' => 'sh' mapping? Shouldn't it be
- qw(py c cpp rb java css php sh pl js tex bib xml awk bat ini spec tcl),
+ qw(py c cpp rb java css php sh pl js tex bib xml awk bat ini spec tcl sql),
> # alternate extensions, see /etc/highlight/filetypes.conf
> 'h' => 'c',
> + map { $_ => 'sh' } qw(bash zsh),
Good idea.
> map { $_ => 'cpp' } qw(cxx c++ cc),
> - map { $_ => 'php' } qw(php3 php4),
> + map { $_ => 'php' } qw(php3 php4 php5 phps),
Good idea.
> map { $_ => 'pl' } qw(perl pm), # perhaps also 'cgi'
> - 'mak' => 'make',
> + map { $_ => 'make'} qw(mak mk),
Good idea.
Sidenote: git itself uses *.mak extension. Is *.mk popular?
> map { $_ => 'xml' } qw(xhtml html htm),
> );
>
> --
> 1.7.3.2
>
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: How to unpack recent objects?
From: Jakub Narebski @ 2010-12-16 22:18 UTC (permalink / raw)
To: Phillip Susi; +Cc: Nicolas Pitre, git
In-Reply-To: <4D0A8D83.9080705@cfl.rr.com>
Phillip Susi <psusi@cfl.rr.com> writes:
> On 12/16/2010 4:19 PM, Nicolas Pitre wrote:
> > What makes you think that unpacking them will actually make the access
> > to them faster? Instead, you should consider _repacking_ them,
> > ultimately using the --aggressive parameter with the gc command, if you
> > want faster accesses.
>
> Because decompressing and undeltifying the objects in the pack file
> takes a fair amount of cpu time. It seems a waste to do this for the
> same set of objects repeatedly rather than just keeping them loose.
Loose objects are also compressed.
Besides git has some kind of delta cache, so when you are accessing a
few objects (like e.g. when doing 'git log -p' - log + diff) you don't
need to undeltify and uncompress the same objects repeatedly.
Also in practice it is IO that is bottleneck, not CPU. And having
many files is bad for filesystem cache. Originally packfiles were for
the network transfer, but it turned out that they are better also as
on-disk format.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: How to unpack recent objects?
From: Phillip Susi @ 2010-12-16 22:06 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <alpine.LFD.2.00.1012161616170.10437@xanadu.home>
On 12/16/2010 4:19 PM, Nicolas Pitre wrote:
> What makes you think that unpacking them will actually make the access
> to them faster? Instead, you should consider _repacking_ them,
> ultimately using the --aggressive parameter with the gc command, if you
> want faster accesses.
Because decompressing and undeltifying the objects in the pack file
takes a fair amount of cpu time. It seems a waste to do this for the
same set of objects repeatedly rather than just keeping them loose.
^ permalink raw reply
* Re: why the html and man versions of git-diff are different?
From: Jeff King @ 2010-12-16 21:55 UTC (permalink / raw)
To: Leo; +Cc: git
In-Reply-To: <m139px2y26.fsf@cam.ac.uk>
On Thu, Dec 16, 2010 at 09:43:45PM +0000, Leo wrote:
> I compared the html version of git-diff found in
> http://www.kernel.org/pub/software/scm/git/docs/git-diff.html and the
> man version from
> http://kernel.org/pub/software/scm/git/git-manpages-1.7.3.4.tar.bz2
>
> The man version says gitrevisions(1), which is incorrect since it is in
> man7.
Because it was fixed recently, and the html documention on kernel.org
uses the "master" branch, whereas that commit did not make it into the
maintenance release 1.7.3.4. It will be fixed in the manpages for
git-1.7.4.
-Peff
^ permalink raw reply
* why the html and man versions of git-diff are different?
From: Leo @ 2010-12-16 21:43 UTC (permalink / raw)
To: git
Hello,
I compared the html version of git-diff found in
http://www.kernel.org/pub/software/scm/git/docs/git-diff.html and the
man version from
http://kernel.org/pub/software/scm/git/git-manpages-1.7.3.4.tar.bz2
The man version says gitrevisions(1), which is incorrect since it is in
man7.
Leo
--
Oracle is the new evil
^ permalink raw reply
* [PATCH 2/3] gitweb: decorate a bit more remotes
From: Sylvain Rabot @ 2010-12-16 21:43 UTC (permalink / raw)
To: git; +Cc: Sylvain Rabot
In-Reply-To: <1292535801-7421-1-git-send-email-sylvain@abstraction.fr>
Signed-off-by: Sylvain Rabot <sylvain@abstraction.fr>
---
gitweb/gitweb.perl | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index db18d06..9398475 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -5127,13 +5127,13 @@ sub git_remote_block {
if (defined $fetch) {
if ($fetch eq $push) {
- $urls_table .= format_repo_url("URL", $fetch);
+ $urls_table .= format_repo_url("<strong>URL:</strong>", $fetch);
} else {
- $urls_table .= format_repo_url("Fetch URL", $fetch);
- $urls_table .= format_repo_url("Push URL", $push) if defined $push;
+ $urls_table .= format_repo_url("<strong>Fetch URL:</strong>", $fetch);
+ $urls_table .= format_repo_url("<strong>Push URL:</strong>", $push) if defined $push;
}
} elsif (defined $push) {
- $urls_table .= format_repo_url("Push URL", $push);
+ $urls_table .= format_repo_url("<strong>Push URL:</strong>", $push);
} else {
$urls_table .= format_repo_url("", "No remote URL");
}
--
1.7.3.2
^ permalink raw reply related
* [PATCH 1/3] gitweb: add extensions to highlight feature
From: Sylvain Rabot @ 2010-12-16 21:43 UTC (permalink / raw)
To: git; +Cc: Sylvain Rabot
In-Reply-To: <1292535801-7421-1-git-send-email-sylvain@abstraction.fr>
added: sql, php5, phps, bash, zsh, mk
Signed-off-by: Sylvain Rabot <sylvain@abstraction.fr>
---
gitweb/gitweb.perl | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index d521c93..db18d06 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -250,13 +250,14 @@ our %highlight_ext = (
# main extensions, defining name of syntax;
# see files in /usr/share/highlight/langDefs/ directory
map { $_ => $_ }
- qw(py c cpp rb java css php sh pl js tex bib xml awk bat ini spec tcl),
+ qw(py c cpp rb java css php pl js tex bib xml awk bat ini spec tcl sql),
# alternate extensions, see /etc/highlight/filetypes.conf
'h' => 'c',
+ map { $_ => 'sh' } qw(bash zsh),
map { $_ => 'cpp' } qw(cxx c++ cc),
- map { $_ => 'php' } qw(php3 php4),
+ map { $_ => 'php' } qw(php3 php4 php5 phps),
map { $_ => 'pl' } qw(perl pm), # perhaps also 'cgi'
- 'mak' => 'make',
+ map { $_ => 'make'} qw(mak mk),
map { $_ => 'xml' } qw(xhtml html htm),
);
--
1.7.3.2
^ permalink raw reply related
* [PATCH 3/3] gitweb: remove test when closing file descriptor
From: Sylvain Rabot @ 2010-12-16 21:43 UTC (permalink / raw)
To: git; +Cc: Sylvain Rabot
In-Reply-To: <1292535801-7421-1-git-send-email-sylvain@abstraction.fr>
it happens that closing file descriptor fails whereas
the blob is perfectly readable.
Signed-off-by: Sylvain Rabot <sylvain@abstraction.fr>
---
gitweb/gitweb.perl | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 9398475..9a885b1 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3450,8 +3450,7 @@ sub run_highlighter {
my ($fd, $highlight, $syntax) = @_;
return $fd unless ($highlight && defined $syntax);
- close $fd
- or die_error(404, "Reading blob failed");
+ close $fd;
open $fd, quote_command(git_cmd(), "cat-file", "blob", $hash)." | ".
quote_command($highlight_bin).
" --xhtml --fragment --syntax $syntax |"
--
1.7.3.2
^ permalink raw reply related
* [PATCH 0/3] minor gitweb modifications
From: Sylvain Rabot @ 2010-12-16 21:43 UTC (permalink / raw)
To: git; +Cc: Sylvain Rabot
Hi,
here a three patch serie with minor updates for gitweb based on master.
I'm not really fond of the third patch but it solves a problem
I've encountered on several files.
Regards.
Sylvain Rabot (3):
gitweb: add extensions to highlight feature
gitweb: decorate a bit more remotes
gitweb: remove test when closing file descriptor
gitweb/gitweb.perl | 18 +++++++++---------
1 files changed, 9 insertions(+), 9 deletions(-)
--
1.7.3.2
^ permalink raw reply
* Re: How to unpack recent objects?
From: Nicolas Pitre @ 2010-12-16 21:19 UTC (permalink / raw)
To: Phillip Susi; +Cc: git
In-Reply-To: <4D0A77A7.9080702@cfl.rr.com>
On Thu, 16 Dec 2010, Phillip Susi wrote:
> It looks like you can use git-unpack-objects to unpack ALL objects, but
> how can you unpack only recent ones that you are likely to use while
> leaving the ancient stuff packed? Ideally I want to unpack all file
> objects from the current commit, and a reasonable number of commit
> objects going back into the history so accessing them with checkout,
> diff, log, etc will be fast.
What makes you think that unpacking them will actually make the access
to them faster? Instead, you should consider _repacking_ them,
ultimately using the --aggressive parameter with the gc command, if you
want faster accesses.
Nicolas
^ permalink raw reply
* Re: How to unpack recent objects?
From: Jonathan Nieder @ 2010-12-16 20:40 UTC (permalink / raw)
To: Phillip Susi; +Cc: git
In-Reply-To: <4D0A77A7.9080702@cfl.rr.com>
Hi Phillip,
Phillip Susi wrote:
> It looks like you can use git-unpack-objects to unpack ALL objects, but
> how can you unpack only recent ones that you are likely to use while
> leaving the ancient stuff packed? Ideally I want to unpack all file
> objects from the current commit, and a reasonable number of commit
> objects going back into the history so accessing them with checkout,
> diff, log, etc will be fast.
Have you tried the experiment? You can pack all objects and then make
a few commits that do not reuse any blobs from before on top of that;
then "cp -a" the repository and use "git gc --aggressive" to get one
big pack as a control. Then it should be possible to time checkout,
diff, log, etc[1].
It would also be interesting to know what the nature of these objects
are, in case it is possible to speed things up some other way.
Jonathan
[1] My uninformed guess is that the packed version will be faster,
because of cache effects among other reasons. The point of loose
objects is to speed up writing objects rather than reading them.
But I'd be happy to be surprised.
^ permalink raw reply
* How to unpack recent objects?
From: Phillip Susi @ 2010-12-16 20:33 UTC (permalink / raw)
To: git
It looks like you can use git-unpack-objects to unpack ALL objects, but
how can you unpack only recent ones that you are likely to use while
leaving the ancient stuff packed? Ideally I want to unpack all file
objects from the current commit, and a reasonable number of commit
objects going back into the history so accessing them with checkout,
diff, log, etc will be fast.
^ permalink raw reply
* Re: Correctly detecting modified paths in merge commits?
From: Jakub Narebski @ 2010-12-16 18:33 UTC (permalink / raw)
To: Dun Peal; +Cc: Git ML
In-Reply-To: <AANLkTimsHZ543B7XWS6taa0w2Vc4huznx3UMs4Ejg3af@mail.gmail.com>
Dun Peal <dunpealer@gmail.com> writes:
> We wrote a post-receive hook that alerts users (via email) when
> specific paths are modified by their peers. The implementation is
> pretty simple: whenever a new commit is made, we ask git for the full
> list of files modified by that commit:
>
> git diff --name-only <COMMIT HASH>^!
>
> This works well for regular commits, but breaks for merge commits.
Note that <commit>^! is *range* specifier, and 'git diff' really takes
two *endpoints*.
>From git-diff(1) manpage.
For a more complete list of ways to spell <commit>, see "SPECIFYING
REVISIONS" section in gitrevisions(1). However, "diff" is about
comparing two _endpoints_, not ranges, and the range notations
("<commit>..<commit>" and "<commit>...<commit>") do not mean a
range as defined in the "SPECIFYING RANGES" section in gitrevisions(1).
<commit>^1 means include given commit but exclude all of its parents
(see gitrevisions(7)).
For a merge commit r1^! means r1 ^p1 ^p2 (where p1 and p2 are parents
of r1), which for git-diff probably means "git diff p1 r1".
> For example, suppose we have the following basic merge scenario:
>
> B
> / \
> A D
> \ /
> C
>
> Root A was branched to B and C, then merged into commit D.
>
> Problem is, the diff for D^! will include all the changes introduced by C.
See above.
Try
$ git diff-tree --name-only -c <COMMIT HADH>
instead. '-c' is to show merge commit as combined diff (noting changes
different from both parents). I'm not sure if this is what you want.
There is alwats '--cc' or '-m' instead of '-c'.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Correctly detecting modified paths in merge commits?
From: Dun Peal @ 2010-12-16 16:54 UTC (permalink / raw)
To: Git ML
Hi.
We wrote a post-receive hook that alerts users (via email) when
specific paths are modified by their peers. The implementation is
pretty simple: whenever a new commit is made, we ask git for the full
list of files modified by that commit:
git diff --name-only <COMMIT HASH>^!
This works well for regular commits, but breaks for merge commits.
For example, suppose we have the following basic merge scenario:
B
/ \
A D
\ /
C
Root A was branched to B and C, then merged into commit D.
Problem is, the diff for D^! will include all the changes introduced by C.
One obvious solution is to simply ignore merge commits, by parsing
`git cat-file commit D` and discarding all commits with parent count >
1. But merge commits may actually contain legitimate modified files if
there were any conflict resolutions.
So what's the best solution for this problem, oh wise Git wizards?
Thanks, D.
^ permalink raw reply
* Re: [PATCH] completion: add missing configuration variables
From: Jeff King @ 2010-12-16 14:28 UTC (permalink / raw)
To: Martin von Zweigbergk; +Cc: SZEDER Gábor, git, Junio C Hamano
In-Reply-To: <alpine.DEB.1.10.1012160810440.25560@debian>
On Thu, Dec 16, 2010 at 08:14:54AM +0100, Martin von Zweigbergk wrote:
> > On Wed, Dec 15, 2010 at 08:44:45PM +0100, Martin von Zweigbergk wrote:
> > > On Wed, 15 Dec 2010, Jeff King wrote:
> > > > As an aside, I would think "--unset" should actually choose from the set
> > > > of configured variables for completion (i.e., "git config --list | cut
> > > > -d= -f1"). But that would obviously be a separate patch.
> > >
> > > Good point. I'll put it on my todo.
> >
> > It already works that way since 0065236 (bash completion: complete
> > variable names for "git config" with options, 2009-05-08).
>
> Nice. Thanks. Removed from my todo :-). Then I don't see any reason at
> all to keep color.grep.external and add.ignore-errors.
Agreed. Thanks.
-Peff
^ permalink raw reply
* Re: [PATCH] completion: add missing configuration variables
From: Martin von Zweigbergk @ 2010-12-16 7:14 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: Martin von Zweigbergk, Jeff King, git, Junio C Hamano
In-Reply-To: <20101216124235.GA32636@neumann>
On Thu, 16 Dec 2010, SZEDER G?bor wrote:
> Hi,
>
>
> On Wed, Dec 15, 2010 at 08:44:45PM +0100, Martin von Zweigbergk wrote:
> > On Wed, 15 Dec 2010, Jeff King wrote:
> > > As an aside, I would think "--unset" should actually choose from the set
> > > of configured variables for completion (i.e., "git config --list | cut
> > > -d= -f1"). But that would obviously be a separate patch.
> >
> > Good point. I'll put it on my todo.
>
> It already works that way since 0065236 (bash completion: complete
> variable names for "git config" with options, 2009-05-08).
Nice. Thanks. Removed from my todo :-). Then I don't see any reason at
all to keep color.grep.external and add.ignore-errors.
/Martin
^ permalink raw reply
* Re: [PATCH] completion: add missing configuration variables
From: SZEDER Gábor @ 2010-12-16 12:42 UTC (permalink / raw)
To: Martin von Zweigbergk; +Cc: Jeff King, git, Junio C Hamano
In-Reply-To: <alpine.DEB.1.10.1012151931030.25560@debian>
Hi,
On Wed, Dec 15, 2010 at 08:44:45PM +0100, Martin von Zweigbergk wrote:
> On Wed, 15 Dec 2010, Jeff King wrote:
> > As an aside, I would think "--unset" should actually choose from the set
> > of configured variables for completion (i.e., "git config --list | cut
> > -d= -f1"). But that would obviously be a separate patch.
>
> Good point. I'll put it on my todo.
It already works that way since 0065236 (bash completion: complete
variable names for "git config" with options, 2009-05-08).
Best,
Gábor
^ permalink raw reply
* Re: [PATCH] Fix typo in git-gc document.
From: Matthieu Moy @ 2010-12-16 8:38 UTC (permalink / raw)
To: Jiang Xin; +Cc: Junio C Hamano, git
In-Reply-To: <4D09BCE1.9030209@gmail.com>
Jiang Xin <worldhello.net@gmail.com> writes:
> The variable gc.packrefs for git-gc can be set to true, false and
> "notbare", not "nobare".
Right, gc.c says:
if (!strcmp(var, "gc.packrefs")) {
if (value && !strcmp(value, "notbare"))
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* [PATCH] Fix typo in git-gc document.
From: Jiang Xin @ 2010-12-16 7:16 UTC (permalink / raw)
To: Junio C Hamano, git
The variable gc.packrefs for git-gc can be set to true, false and
"notbare", not "nobare".
Signed-off-by: Jiang Xin <jiangxin@ossxp.com>
---
Documentation/config.txt | 2 +-
Documentation/git-gc.txt | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 3fd4b62..4f1e979 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -971,7 +971,7 @@ gc.packrefs::
Running `git pack-refs` in a repository renders it
unclonable by Git versions prior to 1.5.1.2 over dumb
transports such as HTTP. This variable determines whether
- 'git gc' runs `git pack-refs`. This can be set to `nobare`
+ 'git gc' runs `git pack-refs`. This can be set to `notbare`
to enable it within all non-bare repos or it can be set to a
boolean value. The default is `true`.
diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt
index 315f07e..a01eef6 100644
--- a/Documentation/git-gc.txt
+++ b/Documentation/git-gc.txt
@@ -107,7 +107,7 @@ how long records of conflicted merge you have not resolved are
kept. This defaults to 15 days.
The optional configuration variable 'gc.packrefs' determines if
-'git gc' runs 'git pack-refs'. This can be set to "nobare" to enable
+'git gc' runs 'git pack-refs'. This can be set to "notbare" to enable
it within all non-bare repos or it can be set to a boolean value.
This defaults to true.
--
1.7.3.3
^ permalink raw reply related
* Re: [PATCH v2 resend] bash completion: add basic support for git-reflog
From: Jonathan Nieder @ 2010-12-16 7:15 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: Git Mailing List, Junio C Hamano, SZEDER Gábor
In-Reply-To: <20101216145608.000004df@unknown>
Tay Ray Chuan wrote:
> "Promote" the reflog command out of plumbing, so that we now run
> completion for it. After all, it's listed under porcelain (ancillary),
> and we do run completion for those commands.
Good point.
[...]
> Even get-tar-commit-id (I've never used this before) is treated
> better than reflog.
It's handy from time to time. :)
Thanks, and sorry to miss the point before. The patch looks good.
^ 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