The previous implementation said that the filesystem information on
Windows is not reliable to determine whether a file is executable.
To find gather this information it was peeking into the first two bytes
of a file to see whether it looks executable.
Apart from the fact that on Windows executable
Am 10.08.2012 18:27, schrieb Shawn Pearce:
> There is no need to define your own mmap(). Define NO_MMAP=1 in the
> Makefile. Git already has its own fake mmap and knows how to write it
> back to disk when making changes.
Or better to say: the fake mmap has functionality that is sufficient for
git.
Junio C Hamano wrote:
>Some ideas:
>
>- Make "clone --reference" without "-s" not to borrow from the
> reference repository. (...)
Generalize: Introduce volatile alternate object stores. Commands like
(remote) fetch, repack, gc will copy desired objects they see there.
That allows
I should add to the facts that:
- git version: git version 1.7.11.2
- Happens only when using protocols git:// and have seen it with
https:// too, but never with http://
- Saw a similar issue here:
http://code.google.com/p/msysgit/issues/detail?id=361
On 11 August 2012 04:48, Paul Alesius wrot
On Sat, Aug 11, 2012 at 12:51 PM, wrote:
> Hi
>
> Why i cannot use git svn info outside of git folder ? This command miss an
> url/dir parameter. Can somebody add such function to this command ? It's for
> batch scripts etc
>
This isn't Windows specific, so this feature-request is more suited
fo
Signed-off-by: Nguyễn Thái Ngọc Duy
---
I know it's late in the cycle so let's queue it for the next one
before I forget it.
I'm after the "done\n" in index-pack but we should also make it
possible to translate units (especially "bytes" which is plural).
There are ellipsis elsewhere in thi
Difficult that it is a git problem. It is better to trace the network
communication, a wireshark trace for example. But it is probably a
firewall or UTM, if you have, issue.
Best
2012/8/11, Paul Alesius :
> I should add to the facts that:
>
>
> - git version: git version 1.7.11.2
> - Happens only
Hello!
What I am doing is:
invoking a bash script that does the
git add ${i##$TXPATH/}/strings.xml
git commit --author="$AUTHOR" ${i##$TXPATH\/}/strings.xml -m "l10n:
$LNAME update"
after a user confirmation.
IIUC setting LANGUAGE=en at the top of this script _did_ help.
So I run everything
matt...@korich.net wrote on Fri, 10 Aug 2012 12:14 -0700:
> Using git p4 on git version 1.7.12.rc2 has path issues. Standard
> clone/sync ops apparently place detected master and branches on
> independent and parallel directory structures instead of git branches.
> See http://stackoverflow.com/q/11
This code will be useful in --detect-branches --use-client-spec tests.
Signed-off-by: Pete Wyckoff
---
t/lib-git-p4.sh | 18 ++
t/t9809-git-p4-client-view.sh | 17 -
2 files changed, 18 insertions(+), 17 deletions(-)
diff --git a/t/lib-git-p4.sh b/t
Signed-off-by: Pete Wyckoff
---
t/t9801-git-p4-branch.sh | 77
1 file changed, 77 insertions(+)
diff --git a/t/t9801-git-p4-branch.sh b/t/t9801-git-p4-branch.sh
index 99fe16b..ca3a7f9 100755
--- a/t/t9801-git-p4-branch.sh
+++ b/t/t9801-git-p4-bra
This instance variable is needed during commit() to map
files from p4 to their relative locations in git. Set
it when initializing P4Sync to avoid passing it to every
commit() call.
Signed-off-by: Pete Wyckoff
---
git-p4.py | 25 ++---
1 file changed, 14 insertions(+), 11 de
Instead of having to remember to do it after each call to
stripRepoPath, make it part of that function.
Signed-off-by: Pete Wyckoff
---
git-p4.py | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/git-p4.py b/git-p4.py
index 6d07115..e20ff5d 100755
--- a/git-p4
The bug report in http://stackoverflow.com/questions/11893688
observes that files are mapped into the wrong locations in
git when both --use-client-spec and --branch-detection are enabled.
Fix this by changing the relative path prefix to match discovered
branches when using a client spec.
The pro
This fixes a bug where git finds the incorrect merge parent. Consider a
repository with trunk, branch1 of trunk, and branch2 of branch1.
Without this change, git interprets a merge of branch2 into trunk as a
merge of branch1 into trunk.
Signed-off-by: Steven Walter
---
git-svn.perl
Consider the case where you have trunk, branchA of trunk, and branchB of
branchA. trunk is merged back into branchB, and then branchB is
reintegrated into trunk. The merge of branchB into trunk will have
svn:mergeinfo property references to both branchA and branchB. When
performing the check_che
Am 11.08.2012 00:47, schrieb Junio C Hamano:
Sven Strickroth writes:
when I create a git repository, add a file containing utf-8 characters
or umlauts (like öäü.txt), commit and then export the HEAD revision to a
zip archive using "git archive --format zip -o 1.zip HEAD", the zip file
contains
Am 11.08.2012 01:53, schrieb Sven Strickroth:
Am 11.08.2012 00:47 schrieb Junio C Hamano:
Do you know in what encoding the pathnames are _expected_ to be
stored in zip archives?
re-encoding to latin1 does not always work and may break double byte
totally (e.g. chinese or japanese).
PKZIP APPN
Am 11.08.2012 22:53 schrieb René Scharfe:
> The standard says we need to convert to CP437, or to UTF-8, or provide
> both versions. A more interesting question is: What's supported by which
> programs?
>
> The ZIP functionality built into Windows 7 doesn't seem to work with
> UTF-8 encoded file
René Scharfe writes:
>> PKZIP APPNOTE seems to be the zip standard and it specifies a utf-8
>> flag: http://www.pkware.com/documents/casestudies/APPNOTE.TXT
>>> A. Local file header:
>>> general purpose bit flag: (2 bytes)
>>> Bit 11: Language encoding flag (EFS). If this bit is
>>> set, the fi
René Scharfe writes:
> ... A more interesting question is: What's supported by
> which programs?
Yes, that is the most interesting question.
>> Of course, "git archive --format=zip --path-reencode=utf8-to-latin1"
>> would be the most generic way to do this.
>
> I really hope we can make do with
Heiko Voigt writes:
> help.c | 15 ---
> 1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/help.c b/help.c
> index 662349d..b41fa21 100644
> --- a/help.c
> +++ b/help.c
> @@ -103,10 +103,19 @@ static int is_executable(const char *name)
> return 0;
>
>
Nguyễn Thái Ngọc Duy writes:
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> I know it's late in the cycle so let's queue it for the next one
> before I forget it.
I won't necessarily be queuing this. Not forgetting is a
responsibility of individual developers.
But it is a good idea to show
Pete Wyckoff writes:
> matt...@korich.net wrote on Fri, 10 Aug 2012 12:14 -0700:
>> Using git p4 on git version 1.7.12.rc2 has path issues. Standard
>> clone/sync ops apparently place detected master and branches on
>> independent and parallel directory structures instead of git branches.
>> See
Heiko Voigt writes:
> I did not know that you prefer a space after the function name. I simply
> imitated the style from C and there we do not have spaces. It makes the
> style rules a bit more complicated. Wouldn't it be nicer to have the
> same as in C so we have less rules?
I do not think so,
25 matches
Mail list logo
