* Re: [msysGit] Windows & executable bit
From: Thomas Rast @ 2009-08-18 10:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Ferry Huberts, msysgit, git
In-Reply-To: <alpine.DEB.1.00.0908181213590.4680@intel-tinevez-2-302>
Johannes Schindelin wrote:
>
> git config trust.fileMode false
Isn't that core.filemode ?
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [msysGit] Windows & executable bit
From: Johannes Schindelin @ 2009-08-18 10:14 UTC (permalink / raw)
To: Ferry Huberts; +Cc: msysgit, git
In-Reply-To: <45321.77.61.241.211.1250588523.squirrel@hupie.xs4all.nl>
Hi,
On Tue, 18 Aug 2009, Ferry Huberts wrote:
> after a checkout the status of SQC.sh is always 'modified' and we can't
> convince git to reset it. I actually succeeded _once_ but can not
> remember how I did it. The file is _always_ dirty.
>
> Is this a bug?
>
> I have to note that when I re-clone the repo I don't have the problem.
> So it seems to be somewhere in the 'update the working copy' code?
git config trust.fileMode false
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 05/11] Remove va_copy at MSVC because there are va_copy.
From: Johannes Schindelin @ 2009-08-18 9:54 UTC (permalink / raw)
To: Frank Li; +Cc: Paolo Bonzini, git, msysgit
In-Reply-To: <1976ea660908172206hc75c1e6i117806338be5ccea@mail.gmail.com>
Hi,
On Tue, 18 Aug 2009, Frank Li wrote:
> > #ifndef va_copy
> > #define va_copy(dst, src) ((dst) = (src))
> > #endif
> >
> > if it works on MSVC?
>
> I test it, it works.
But please, either put it into compat/msvc.h or make it dependent on some
#define such as "DEFINE_VA_COPY_TRIVIALLY" so that other platforms who
might miss va_copy (but can use the trivial definition above) can use it.
I do not think that va_copy can be defined like this in general.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH][resend] git-svn: Respect GIT_SSH setting
From: Johannes Schindelin @ 2009-08-18 9:52 UTC (permalink / raw)
To: Karthik R; +Cc: git
In-Reply-To: <4A8A2EFE.6000203@fastmail.fm>
Hi,
On Mon, 17 Aug 2009, Karthik R wrote:
> Johannes Schindelin wrote:
>
> > On Mon, 17 Aug 2009, Karthik R wrote:
> >
> > > Setting GIT_SSH when using "git svn clone svn+ssh://..." does not
> > > override the default ssh; SVN_SSH needed to be set instead.
> >
> > This is now in past tense, no?
>
> Yes... this is all in the past tense now :) ... should be "did not
> override the default ssh". I'll fix it if I have to resend the patch for
> a different reason.
> > > diff --git a/git-svn.perl b/git-svn.perl
> > > index b0bfb74..9bc1e71 100755
> > > --- a/git-svn.perl
> > > +++ b/git-svn.perl
> > > @@ -21,6 +21,13 @@ $Git::SVN::default_ref_id = $ENV{GIT_SVN_ID} ||
> > > 'git-svn';
> > > $Git::SVN::Ra::_log_window_size = 100;
> > > $Git::SVN::_minimize_url = 'unset';
> > >
> > > +# If GIT_SSH is set, also set SVN_SSH...
> > > +$ENV{SVN_SSH} = $ENV{GIT_SSH} if defined $ENV{GIT_SSH};
> > > +# ... and escape \s in shell-variable on Windows
> > > +if ($^O eq 'MSWin32' || $^O eq 'msys') {
> > > + $ENV{SVN_SSH} =~ s/\\/\\\\/g if defined $ENV{SVN_SSH};
> > > +}
> > >
> >
> > This is a change from before... I do not know if it is a good one, as
> > SVN_SSH could be defined differently by the user, no? In that case,
> > the user was most likely using the correct amount of backslashes...
>
> Dscho, The *correct* amount of backslashes is 1 (per dir) - same as used
> with GIT_SSH. If the user has set SVN_SSH but not GIT_SSH (most likely
> without escaping \), then fixing up SVN_SSH for use with git-svn is not
> a bad thing.
>
> I did this change to retain existing behavior (using SVN_SSH to
> override) even when user doesn't know the \\ quirk - or if the user has
> set it for some other non-msys version of svn.
Two things: you want to say that much in the commit message, lest people
as stupid as me fall into the same trap. And you might want to avoid
doing that for MSWin32: we may have a MinGW Perl in the near future (Bosko
was working really hard on that), and then we do _not_ want that behavior,
right?
Ciao,
Dscho
^ permalink raw reply
* [PATCH] filter-branch: make the usage string fit on 80 chars terminals.
From: Matthieu Moy @ 2009-08-18 9:51 UTC (permalink / raw)
To: git, gitster; +Cc: Matthieu Moy
It used to be a single, huge line, badly wrapped by xterm.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
git-filter-branch.sh | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 37e044d..a480d6f 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -97,12 +97,12 @@ set_ident () {
echo "case \"\$GIT_${uid}_NAME\" in \"\") GIT_${uid}_NAME=\"\${GIT_${uid}_EMAIL%%@*}\" && export GIT_${uid}_NAME;; esac"
}
-USAGE="[--env-filter <command>] [--tree-filter <command>] \
-[--index-filter <command>] [--parent-filter <command>] \
-[--msg-filter <command>] [--commit-filter <command>] \
-[--tag-name-filter <command>] [--subdirectory-filter <directory>] \
-[--original <namespace>] [-d <directory>] [-f | --force] \
-[<rev-list options>...]"
+USAGE="[--env-filter <command>] [--tree-filter <command>]
+ [--index-filter <command>] [--parent-filter <command>]
+ [--msg-filter <command>] [--commit-filter <command>]
+ [--tag-name-filter <command>] [--subdirectory-filter <directory>]
+ [--original <namespace>] [-d <directory>] [-f | --force]
+ [<rev-list options>...]"
OPTIONS_SPEC=
. git-sh-setup
--
1.6.4.171.g24636.dirty
^ permalink raw reply related
* Re: [PATCH 09/11] Add MSVC porting header files.
From: Johannes Schindelin @ 2009-08-18 9:47 UTC (permalink / raw)
To: Frank Li; +Cc: git, msysgit
In-Reply-To: <1976ea660908171915v62fb6c40j17f750cac9836433@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1353 bytes --]
Hi,
On Tue, 18 Aug 2009, Frank Li wrote:
> >> Add unix head file, dirent.h, unistd.h and time.h
> >
> > These are copied from somewhere. From where? What is the license?
>
> It comes from msys, which used to build msysgit.
I know. After reading the patch. But it would be better if everybody
knew after reading the commit message... _Especially_ in this
increasingly lawsuit-defined business, it is very nice to see early that
the files you are including here are in the public domain, and come from
MSys.
> I really want to in .vcproj. but the same context needs to copy
> DEBUG\RELEASE 32\64bit, libgit.vcproj and git.vcproj. 8 place needs
> copy. To avoid copy in vcproj file, I move it hear.
As I said earlier, there are common flags, but as I also said, it is
probably better to keep the #define's in a header file for better
visibility and editability, albeit in logically clustered blocks (i.e. all
the NO_* and other #define's that affect what source code is
compiled, all default paths in another cluster, #define's to bow before
Microsoft's C runtime's decision to deprecate the C99 standard function
names, etc)
BTW it is funny that your typos seem to be influenced by the _sound_ of
the word ("hear" instead of "here"), rather than just simple transposed
letters... most of my typos are the same ;-)
Ciao,
Dscho
^ permalink raw reply
* [MSysGit] Windows & executable bit
From: Ferry Huberts @ 2009-08-18 9:42 UTC (permalink / raw)
To: msysgit; +Cc: git
Hi list,
Our project is (also) using msysgit.
Recently we changed the permissions on a file
(a Linux shell script) by this (gitk) patch:
----------------------------- xxxx/SQC/SQC.sh -----------------------------
old mode 100644
new mode 100755
We did this on a Linux machine.
Now on a Windows machine we pull in the change:
This causes problems when checking out the branch on which the change was
made: after a checkout the status of SQC.sh is always 'modified' and we can't
convince git to reset it. I actually succeeded _once_ but can not remember how
I did it.
The file is _always_ dirty.
Is this a bug?
I have to note that when I re-clone the repo I don't have the problem. So it
seems to be somewhere in the 'update the working copy' code?
Ferry
^ permalink raw reply
* Re: [PATCH 07/11] Add O_BINARY flag to open flag at mingw.c
From: Johannes Schindelin @ 2009-08-18 9:40 UTC (permalink / raw)
To: Frank Li; +Cc: git, msysgit
In-Reply-To: <1976ea660908171902ubf04991x7d6890d4d9accd9a@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1263 bytes --]
Hi,
On Tue, 18 Aug 2009, Frank Li wrote:
> > How about this instead?
> >
> > mingw.c: Use the O_BINARY flag to open files
> >
> > On Windows, non-text files must be opened using the O_BINARY flag.
> > MinGW does this for us automatically, but Microsoft Visual C++
> > does not.
> >
> > Also, Johannes said that this would be a nice cleanup.
> >
>
> Okay, Do you need me change commit comments to resubmit patch?
How about updating your branch at tgit.git with the new commit
messages first? (Use rebase -i...)
> > BTW what about fopen()?
>
> I never found problem at fopen, I will double check it.
Well, it is better to be sure, not by testing it, but rather by inspecting
the code paths. Is there any way Git wants to open a binary file with
fopen()? If so, it cannot use the modes "r" and "w" there, but must use
"rb" and "wb".
It gets doubly complicated if there are code paths that _want_ to open
text files (such as .git/config), which are user-writable, so they could
(in theory) contain CR/LF line endings.
Ciao,
Dscho
>
> >
> > Patch is obviously good.
> >
> > Ciao,
> > Dscho
> >
>
P.S.: please remove such quoted text, it is totally uninteresting in this
context (you do not reply to it, either).
^ permalink raw reply
* Re: [PATCH 08/11] Place __stdcall to correct position.
From: Johannes Schindelin @ 2009-08-18 9:36 UTC (permalink / raw)
To: Frank Li; +Cc: git, msysgit
In-Reply-To: <1976ea660908171851n16b8b56j378ace9ecf0ce272@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1172 bytes --]
Hi,
On Tue, 18 Aug 2009, Frank Li wrote:
> > How about "... to the correct ..." and "MSVC requires _stdcall to be
> > between return value..." and "All Win32 API functions are declared with
> > the WINAPI attribute."?
>
> WINAPI always like
>
> BOOL WINAPI function_name(xxx);
> It compile fail if WINAPI BOOL function_name(xxx);
Oh, okay, so let's say
Furthermore, Microsoft Visual C++ requires the order
BOOL WINAPI function();
instead of
WINAPI BOOL function();
> >> #if defined(__MINGW32__) || defined(_MSC_VER)
> >> -static __stdcall unsigned run_thread(void *data)
> >> +static unsigned __stdcall run_thread(void *data)
> >> {
> >> struct async *async = data;
> >> return async->proc(async->fd_for_proc, async->data);
> >> }
> >> -#endif
> >> +#endif /* __MINGW32__ || _MSC_VER */
> >
> > I do not think this is necessary. There are only 5 lines wrapped into
> > those #ifdef guards, the developer should be able to see that far.
> >
> Do you means remove /* __MINGW32__ || _MSC_VER */?
I was talking about this change:
> -#endif
> +#endif /* __MINGW32__ || _MSC_VER */
which is IMHO distracting rather than helpful.
Ciao,
Dscho
^ permalink raw reply
* Re: [msysGit] Re: [PATCH 02/11] Fix declare variable at mid of function
From: Johannes Schindelin @ 2009-08-18 9:34 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: Reece Dunn, Frank Li, git, msysgit
In-Reply-To: <4A8A3ADE.9010703@gmail.com>
Hi,
On Tue, 18 Aug 2009, Marius Storm-Olsen wrote:
> Johannes Schindelin said the following on 17.08.2009 21:36:
>
> > On Mon, 17 Aug 2009, Reece Dunn wrote:
> >
> > > 2009/8/17 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> > >
> > > > On Tue, 18 Aug 2009, Frank Li wrote:
> > > >
> > > > > Some compiler such as MSVC can't support declear variable at mid of
> > > > > funtion at c file.
> > > > Please wrap your commit messages after 76 characters.
> > > >
> > > > > Signed-off-by: Frank Li <lznuaa@gmail.com>
> > > > > ---
> > > > How about this instead?
> > > >
> > > > Avoid declaration after instruction
> > > >
> > > > Microsoft Visual C++ does not understand this C99 style.
> > > >
> > > > ?
> > > >
> > > > The patch itself is good.
> > > Shouldn't GCC be changed to use -std=c89 as well to pick up errors for
> > > compilers that don't support c99 (like the Microsoft Visual C++ C
> > > compiler)?
> >
> > Hmm. I played with the thought of adding -Werror -Wno-pointer-to-int-cast
> > -Wold-style-definition -Wdeclaration-after-statement like Junio described in
> > one of his mails for MinGW (as we _know_ what compiler we have there).
> >
> > Dunno.
>
> IMO it would be a good change. We should not have any of those anyways..
Okay, I will wait for Frank's updates (just fetched tgit.git and it still
contains the old branch), merge the early part and add the compiler flags.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-log: allow --decorate[=short|full]
From: Jeff King @ 2009-08-18 9:33 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <8c5c35580908150723h6e4c8fcay43b708969a86ae27@mail.gmail.com>
On Sat, Aug 15, 2009 at 04:23:12PM +0200, Lars Hjemli wrote:
> This patch introduces an extension to --decorate to allow the caller to
> specify either the short or the full versions.
>
> Signed-off-by: Lars Hjemli <hjemli@gmail.com>
> ---
>
> Thanks for the review. I've adapted the patch to your comments, and
> modified the documentation of '--decorate' to be more specific.
Thanks. Looks good to me.
Acked-by: Jeff King <peff@peff.net>
-Peff
^ permalink raw reply
* Re: [PATCH 03/11] Define SNPRINTF_SIZE_CORR 1 when use MSVC build git
From: Johannes Schindelin @ 2009-08-18 9:31 UTC (permalink / raw)
To: Frank Li; +Cc: git, msysgit
In-Reply-To: <1976ea660908171819m38d3524ud174a7e76a171e75@mail.gmail.com>
Hi,
On Tue, 18 Aug 2009, Frank Li wrote:
> > How about this instead?
> >
> > Define SNPRINTF_SIZE_CORR=1 for Microsoft Visual C++
> >
> > The Microsoft C runtime's vsnprintf function does not add NUL at
> > the end of the buffer.
> >
> > Further, Microsoft deprecated vsnprintf in favor of _vsnprintf, so
> > add a #define to that end.
>
> Of course, do you need me change commit comment and resend patch?
I think it would be best if you could rewrite your vcpatch branch using
the new commit message.
> > The patch is good, although I suspect that the definition of vsnprintf
> > is better handled in the precompiler options in .vcproj.
>
> If define in .vcproj, it needs copy that to DEBUG\RELEASE and
> 32bit\64bit (2x2) 4 places. It is easy to miss one.
No, there are the common precompiler options, too.
But maybe it is better to leave the #define's in a header file for another
reason: better visibility (I always hated it that I had to open the
project files in a text editor in order to find the settings with Visual
Studio, the GUI seems to be designed by a fan of hide-and-seek).
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] tests: disable interactive hunk selection tests if perl not available
From: Thomas Rast @ 2009-08-18 8:33 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20090818061244.GA20659@coredump.intra.peff.net>
Jeff King wrote:
> +++ b/t/lib-patch-mode.sh
> @@ -1,5 +1,10 @@
> . ./test-lib.sh
>
> +if ! test_have_prereq PERL; then
Thanks. I always forget about these little things...
Acked-By: Thomas Rast <trast@student.ethz.ch>
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH] add -p: do not attempt to coalesce mode changes
From: Kirill Smelkov @ 2009-08-18 7:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, Jeff King, git
In-Reply-To: <7vtz09lz2r.fsf@alter.siamese.dyndns.org>
On Sat, Aug 15, 2009 at 11:19:24AM -0700, Junio C Hamano wrote:
> Thomas Rast <trast@student.ethz.ch> writes:
>
> > Hmm. I briefly considered worrying about futureproofing, but then
> > decided it wasn't worth it since we also rely on
> > coalesce_overlapping_hunks only being run over the hunks of a single
> > file.
>
> Thanks, all.
Thomas, Jeff, Junio,
Thanks for fixing this!
^ permalink raw reply
* Re: [PATCH] git-instaweb: fix mod_perl detection for apache2
From: Jakub Narebski @ 2009-08-18 7:45 UTC (permalink / raw)
To: Mark A Rada; +Cc: Junio C Hamano, git
In-Reply-To: <3300D840-9BAB-4233-B949-6A5B300CD9A8@mailservices.uwaterloo.ca>
On Wed, 15 Aug 2009, Mark A Rada wrote:
> On 10-Aug-09, at 4:55 AM, Jakub Narebski wrote:
>> Junio C Hamano <gitster@pobox.com> writes:
>>> Thanks. That sounds like an ancient bug that in turn perhaps
>>> suggests nobody uses instaweb. Will apply to 'maint'..
>>
>> Hmmm... taking a peek at current "Git User's Survey 2009" results
>> http://www.survs.com/shareResults?survey=2PIMZGU0&rndm=678J66QRA2
>>
>> 11. What Git interfaces, implementations, frontends and tools do you
>> use?
>>
>> git-instaweb 3% 77 / 2712
>>
>> 16. How often do you use the following forms of git commands or extra
>> git tools?
>>
>> git instaweb
>> never: 1983 - 79%
>> rarely: 208 - 8%
>> sometimes: 50 - 2%
>> often: 9 - 0%
>>
>> Total respondents 2506
>>
>
> Does this means it may be taken off the menu in the not too distant
> future or deprecated?
I don't think so. We keep git-relink, which almost nobody uses, and
few know what it does.
I guess that git-instaweb is not advertised enough, but that might
change, as Scott Chacon in "Pro Git" mentions / covers git-instaweb.
P.S. I'd like to create GIT::Web, which would use (contrary to gitweb)
many CPAN modules (and PAR to help installing it with dependencies),
which would use HTTP::Engine (and therefore run as CGI, FastCGI,
mod_perl and standalone HTTP::Server::Simple), and be similar in
structure to SVN::Web. With it using HTTP::Server::Simple git-instaweb
would be needed less... But it is in "Duke Nuke Forever" (or
packv4 ;-) future...
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] block-sha1: Windows declares ntohl() in winsock2.h
From: Johannes Sixt @ 2009-08-18 7:15 UTC (permalink / raw)
To: msysGit; +Cc: Junio C Hamano, Git Mailing List
From: Johannes Sixt <j6t@kdbg.org>
This is a minimal fix to compile block-sha1 on Windows. I did not do any
benchmarks whether the implementation of ntohl() is actually faster than
bytewise access and shifts.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
I would appreciate if our Windows experts could tell whether the
implementation of ntohl/htonl is worth its money or whether we should
go with the generic byte access plus shifts.
the function call over
block-sha1/sha1.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/block-sha1/sha1.c b/block-sha1/sha1.c
index a1228cf..67c1ee8 100644
--- a/block-sha1/sha1.c
+++ b/block-sha1/sha1.c
@@ -7,7 +7,11 @@
*/
#include <string.h>
+#ifndef _WIN32
#include <arpa/inet.h>
+#else
+#include <winsock2.h>
+#endif
#include "sha1.h"
--
1.6.4.1179.g9a91.dirty
^ permalink raw reply related
* [PATCH] upload-pack: add a trigger for post-upload-pack hook
From: Tom Preston-Werner @ 2009-08-18 7:04 UTC (permalink / raw)
To: git; +Cc: Tom Preston-Werner
A post-upload-pack hook is desirable for Git hosts that need to
collect statistics on how many clones and/or fetches are made
on each repository.
The hook is called with either "clone" or "fetch" as the only
argument, depending on whether a full pack file was sent to the
client or not.
Signed-off-by: Tom Preston-Werner <tom@mojombo.com>
---
upload-pack.c | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/upload-pack.c b/upload-pack.c
index f7d308a..96231dc 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -141,6 +141,13 @@ static int do_rev_list(int fd, void *create_full_pack)
return 0;
}
+static void run_post_upload_pack_hook(int create_full_pack)
+{
+ const char *fetch_type;
+ fetch_type = (create_full_pack) ? "clone" : "fetch";
+ run_hook(get_index_file(), "post-upload-pack", fetch_type);
+}
+
static void create_pack_file(void)
{
struct async rev_list;
@@ -314,6 +321,8 @@ static void create_pack_file(void)
}
if (use_sideband)
packet_flush(1);
+
+ run_post_upload_pack_hook(create_full_pack);
return;
fail:
--
1.6.3.1
^ permalink raw reply related
* Re: Continue git clone after interruption
From: Tomasz Kontusz @ 2009-08-18 6:58 UTC (permalink / raw)
To: git
In-Reply-To: <vpqskfphe2k.fsf@bauges.imag.fr>
Dnia 2009-08-18, wto o godzinie 07:43 +0200, Matthieu Moy pisze:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Hi,
> >
> > On Mon, 17 Aug 2009, Tomasz Kontusz wrote:
> >
> >> is anybody working on making it possible to continue git clone after
> >> interruption? It would be quite useful for people with bad internet
> >> connection (I was downloading a big repo lately, and it was a bit
> >> frustrating to start it over every time git stopped at ~90%).
> >
> > Unfortunately, we did not have enough GSoC slots for the project to allow
> > restartable clones.
> >
> > There were discussions about how to implement this on the list,
> > though.
>
> And a paragraph on the wiki:
>
> http://git.or.cz/gitwiki/SoC2009Ideas#RestartableClone
Ok, so it looks like it's not implementable without some kind of cache
server-side, so the server would know what the pack it was sending
looked like.
But here's my idea: make server send objects in different order (the
newest commit + whatever it points to first, then next one,then
another...). Then it would be possible to look at what we got, tell
server we have nothing, and want [the newest commit that was not
complete]. I know the reason why it is sorted the way it is, but I think
that the way data is stored after clone is clients problem, so the
client should reorganize packs the way it wants.
Tomasz K.
^ permalink raw reply
* git find (was: [RFC PATCH v3 8/8] --sparse for porcelains)
From: Jakub Narebski @ 2009-08-18 6:25 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: skillzero, Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <fcaeb9bf0908171843x6ab0763dqff7e8aea0443c374@mail.gmail.com>
On Tue, Aug 18, 2009, Nguyen Thai Ngoc Duy wrote:
> On Tue, Aug 18, 2009 at 7:34 AM, <skillzero@gmail.com> wrote:
> > I would like it to git grep to not search paths outside the sparse
> > area (although --no-sparse would be nice for git grep in case you did
> > want to search everything). The main reason I want sparse checkouts is
> > for performance reasons. For example, git grep can take 10 minutes on
> > my full repository so excluding paths outside the sparse area would
> > reduce that to a few seconds.
>
> That's a porcelain question that I'd leave it for now. FWIW you can do
> something like this:
>
> git ls-files -v|grep '^H'|cut -c 2-|xargs git grep
>
> /me misses "cleartool find"
Well, I also think that it would be nice and useful to have "git find"
in addition to current "git grep".
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] tests: disable interactive hunk selection tests if perl not available
From: Jeff King @ 2009-08-18 6:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, git
These are all backed by git-add--interactive.perl under the
hood.
Signed-off-by: Jeff King <peff@peff.net>
---
On top of tr/reset-checkout-patch.
t/lib-patch-mode.sh | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/t/lib-patch-mode.sh b/t/lib-patch-mode.sh
index afb4b66..75a3ee2 100755
--- a/t/lib-patch-mode.sh
+++ b/t/lib-patch-mode.sh
@@ -1,5 +1,10 @@
. ./test-lib.sh
+if ! test_have_prereq PERL; then
+ say 'skipping --patch tests, perl not available'
+ test_done
+fi
+
set_state () {
echo "$3" > "$1" &&
git add "$1" &&
--
1.6.4.301.g8099b
^ permalink raw reply related
* Re: [PATCH v2] remove ARM and Mozilla SHA1 implementations
From: David Aguilar @ 2009-08-18 5:49 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LFD.2.00.0908172007590.6044@xanadu.home>
On Mon, Aug 17, 2009 at 08:09:56PM -0400, Nicolas Pitre wrote:
>
> Makefile | 26 +------
>
> -ifneq (,$(findstring arm,$(uname_M)))
> - ARM_SHA1 = YesPlease
> - NO_MKSTEMPS = YesPlease
> -endif
When I added NO_MKSTEMPS I was being conservative when defining
it on arm (I wasn't able to test that platform).
Looks like it wasn't needed afterall.
Thanks.
--
David
^ permalink raw reply
* Re: [PATCH][resend] git-svn: Respect GIT_SSH setting
From: Karthik R @ 2009-08-18 5:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <4A89EC07.2010402@fastmail.fm>
Karthik R wrote:
> Junio C Hamano wrote:
>> Karthik R <karthikr@fastmail.fm> writes:
>>
>>
>>> +# If GIT_SSH is set, also set SVN_SSH...
>>> +$ENV{SVN_SSH} = $ENV{GIT_SSH} if defined $ENV{GIT_SSH};
>>> +# ... and escape \s in shell-variable on Windows
>>> +if ($^O eq 'MSWin32' || $^O eq 'msys') {
>>> + $ENV{SVN_SSH} =~ s/\\/\\\\/g if defined $ENV{SVN_SSH};
>>> +}
>>> +
>>>
>>
>> Two questions.
>>
>> - What if a user has SVN_SSH exported _and_ wants to use a different
>> one
>> from the one s/he uses for git? Naturally such a user would set both
>> environment variables and differently, but this seems to override the
>> value in SVN_SSH;
>>
> Do you mean user wants to use a different one with "git svn ...
> svn+ssh://" (than the one with "git clone ssh://") ?
> In this case
> - defining SVN_SSH, but not GIT_SSH will still work (with this patch,
> GIT_SSH overrides)
> - but SVN_SSH needs to have \\s.
> So unless the user already knew of this quirk, we'll only see
> unescaped \s - so it *does* make sense to escape the \s (if the user
> knew, then too many escaped \s still work).
>> - Can a user have SVN_SSH exported, on MSWin32 or msys, and use svn
>> outside git? If so, what does the value of SVN_SSH look like?
>> Does it
>> typically have necessary doubling of backslashes already?
>>
> With subversion for Windows, these \\s are not needed (but doesn't
> cause any break). The doubling is something to do with the bash (in
> msys) I think.
I was wrong... the \\ seems to be a subversion issue. This s/\\/ line in
this patch would at best be a work-around (necessary because GIT_SSH
doesn't have this bug).
http://subversion.tigris.org/issues/show_bug.cgi?id=3454 (GIT_SSH would
look like the last one in the list - and with this patch, SVN_SSH can
also look the same)
^ permalink raw reply
* Re: Continue git clone after interruption
From: Matthieu Moy @ 2009-08-18 5:43 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Tomasz Kontusz, git
In-Reply-To: <alpine.DEB.1.00.0908171430010.4991@intel-tinevez-2-302>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Mon, 17 Aug 2009, Tomasz Kontusz wrote:
>
>> is anybody working on making it possible to continue git clone after
>> interruption? It would be quite useful for people with bad internet
>> connection (I was downloading a big repo lately, and it was a bit
>> frustrating to start it over every time git stopped at ~90%).
>
> Unfortunately, we did not have enough GSoC slots for the project to allow
> restartable clones.
>
> There were discussions about how to implement this on the list,
> though.
And a paragraph on the wiki:
http://git.or.cz/gitwiki/SoC2009Ideas#RestartableClone
--
Matthieu
^ permalink raw reply
* Re: [msysGit] Re: [PATCH 02/11] Fix declare variable at mid of function
From: Marius Storm-Olsen @ 2009-08-18 5:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Reece Dunn, Frank Li, git, msysgit
In-Reply-To: <alpine.DEB.1.00.0908172134150.8306@pacific.mpi-cbg.de>
Johannes Schindelin said the following on 17.08.2009 21:36:
> Hi,
>
> On Mon, 17 Aug 2009, Reece Dunn wrote:
>
>> 2009/8/17 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>>
>>> On Tue, 18 Aug 2009, Frank Li wrote:
>>>
>>>> Some compiler such as MSVC can't support declear variable at mid of
>>>> funtion at c file.
>>> Please wrap your commit messages after 76 characters.
>>>
>>>> Signed-off-by: Frank Li <lznuaa@gmail.com>
>>>> ---
>>> How about this instead?
>>>
>>> Avoid declaration after instruction
>>>
>>> Microsoft Visual C++ does not understand this C99 style.
>>>
>>> ?
>>>
>>> The patch itself is good.
>> Shouldn't GCC be changed to use -std=c89 as well to pick up errors for
>> compilers that don't support c99 (like the Microsoft Visual C++ C
>> compiler)?
>
> Hmm. I played with the thought of adding -Werror -Wno-pointer-to-int-cast
> -Wold-style-definition -Wdeclaration-after-statement like Junio described
> in one of his mails for MinGW (as we _know_ what compiler we have there).
>
> Dunno.
IMO it would be a good change. We should not have any of those anyways..
--
.marius
^ permalink raw reply
* Re: [PATCH 05/11] Remove va_copy at MSVC because there are va_copy.
From: Frank Li @ 2009-08-18 5:06 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: git, msysgit, Johannes.Schindelin
In-Reply-To: <4A898B27.3040507@gnu.org>
>
> #ifndef va_copy
> #define va_copy(dst, src) ((dst) = (src))
> #endif
>
> if it works on MSVC?
>
> Paolo
>
I test it, it works.
^ 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