On 2014-02-05 02.16, Jeff King wrote:
On Tue, Feb 04, 2014 at 03:40:15PM -0800, Junio C Hamano wrote:
* Somehow this came to my private mailbox without Cc to list, so I
am forwarding it.
I think with 1190a1ac (pack-objects: name pack files after
trailer hash, 2013-12-05),
On 2014-02-05 21.31, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
The minimal fix you posted below does make sense to me as a stopgap, and
we can look into dropping the code entirely during the next cycle. It
would be nice to have a test to cover this case, though.
Sounds
On 2014-02-03 23.11, Reuben Hawkins wrote:
On Mon, Feb 3, 2014 at 2:21 PM, Torsten Bögershausen tbo...@web.de
mailto:tbo...@web.de wrote:
[]
So to summarize, when fast-import uses strncmp_icase (what fast-import
does now) import on a repository where ignorecase=true is wrong
On 2014-02-04 15.25, Martin Erik Werner wrote:
t/t0060-path-utils.sh | 10 ++
1 file changed, 10 insertions(+)
diff --git a/t/t0060-path-utils.sh b/t/t0060-path-utils.sh
index b8e92e1..c0a14f6 100755
--- a/t/t0060-path-utils.sh
+++ b/t/t0060-path-utils.sh
@@ -201,6 +201,16 @@
[]
So to summarize, when fast-import uses strncmp_icase (what fast-import does
now) import on a repository where ignorecase=true is wrong. My patch,
fast-import.c: always honor the filename case fixes this. Can you verify?
Thanks in advance,
Reuben
Yes, I can verify. My feeling is that
On 2014-02-02 12.21, David Kastrup wrote:
Martin Erik Werner martinerikwer...@gmail.com writes:
On Sun, Feb 02, 2014 at 09:19:04AM +0700, Duy Nguyen wrote:
On Sun, Feb 2, 2014 at 8:59 AM, Martin Erik Werner
martinerikwer...@gmail.com wrote:
+ /* check if work tree is already the
Another comment:
The raw comparison with '/' is probably working well on all
POSIX/Linux/Unix systems.
To be more portable, the macro
is_dir_sep()
can be used:
if (is_dir_sep(path[wtlen]))
Since the path is already normalized by 'normalize_path_copy_len' which
seems to guarantee
(It seems as if the mail went only to Junio, sorry)
On 2014-02-02 16.09, Torsten Bögershausen wrote:
On 2014-01-29 19.17, Junio C Hamano wrote:
But after a closer inspection, I no longer think that hunk is an
improvement. These new packfiles were created by pack-objects,
which finishes each
On 2014-02-02 14.13, Reuben Hawkins wrote:
fast-import should not use strncmp_icase. When it does, files with
similar names, but different case can be lost in the import. For
example...
M 100644 :1 FileName.txt
D Filename.txt
That seems to be wrong, shouldn't it be
D Filename.txt
M 100644
On 2014-02-01 10.14, Reuben Hawkins wrote:
Most case-insensitive filesystems are case-preserving. In these
filesystems (such as HFS+ on OS X) you can name a file Filename.txt,
then rename the file to FileName.txt. That file will be accessible
by both filenames, but the case is otherwise
On 2014-01-31 21.22, Martin Erik Werner wrote:
In order to extract the part of an absolute path which lies inside the
repo, it is not possible to directly use real_path, since that would
dereference symlinks both outside and inside the work tree.
Add an 'abspath_part_inside_repo' function
[]
filepattern is related to current directory too (e.g. *.sh from t
won't cover git-rebase.sh, :/*.sh does). Yes a patch to update
git-add.txt to use the term pathspec instead of filepattern would
be nice. A pointer to pathspec glossary could help discover
case-insensitive matching, negative
In a1bbc6c0 a shell command mv -f was replaced with the rename() function.
Use move_temp_to_file() from sha1_file.c instead of rename().
This is in line with the handling of other Git internal tmp files,
and calls adjust_shared_perm()
Signed-off-by: Torsten Bögershausen tbo...@web.de
---
Thanks
.
So setting a file to read-only under Windows is a way for a user
to protect it from being deleted.
Changing the behaviour of rename() globally may not be what we want.
Reported-by: Jochen Haag zwanzi...@googlemail.com
Signed-off-by: Torsten Bögershausen tbo...@web.de
---
builtin/repack.c | 4
On 2014-01-22 22.27, salmansheikh wrote:
Got it working but then I had some issues with the perl portions of the
install and I subsequently thought I could eliminate those portions and
tried setting export NO_PERL=1 and that installed everything else...and got
pass this error but when I tried
On 2014-01-22 16.59, salmansheikh wrote:
Hello,
I have a RHEL system that I am not the admin of. I needed to install git and
got the source. Everything is okay until I got to this point below. I
downloaded and installed the latest libz (1.2.8) but i installed it under a
local directory
: 'rerere' 'gc'
trace: built-in: git 'rerere' 'gc'
The problem might be related to this commit:
https://github.com/msysgit/git/commit/a1bbc6c0176f1fa2d4aa571cc0183a1f0ff9b285
Best regards,
Jochen
--
Am Freitag, 17. Januar 2014 19:02:07 UTC+1 schrieb Torsten Bögershausen:
So
On 2014-01-17 10.47, Nguyễn Thái Ngọc Duy wrote:
[snip[
diff --git a/file-watcher-lib.c b/file-watcher-lib.c
+int connect_watcher(const char *path)
Could it be worth to check if we can use some code from unix-socket.c ?
Especially important could be that unix_sockaddr_init() wotks around a
On 01/17/2014 03:26 AM, Jeff King wrote:
On Thu, Jan 16, 2014 at 03:58:57PM -0800, SH wrote:
We have a repository which holds lots of shell and perl scripts. We add the
files to repository (from windows client) with executable permissions (using
cygwin) but when we pull that repository on
(Please no top posting next time)
On 2014-01-17 20.20, SH wrote:
On Friday, January 17, 2014 10:08 AM, Torsten Bögershausen tbo...@web.de
wrote:
On 01/17/2014 03:26 AM, Jeff King wrote:
On Thu, Jan 16, 2014 at 03:58:57PM -0800, SH wrote:
We have a repository which holds lots of shell
On 2014-01-14 19.26, Junio C Hamano wrote:
Ivan Zakharyaschev i...@altlinux.org writes:
Hello!
git-1.8.4.4
The manpage for git-pull mentions -m in a comment:
--edit, -e, --no-edit
Invoke an editor before committing successful mechanical merge to further
edit
the auto-generated merge
On 2014-01-12 01.23, THILLOSEN Andreas wrote:
Hi,
I have a question about a specific use case for subtrees, but I'm not
I feel a little bit confused: Are you talking about git submodules?
And you may want to have a look at the repo tool:
https://code.google.com/p/git-repo/
HTH
/Torsten
--
On 2014-01-10 20.28, Jonathan Nieder wrote:
Dan Kaplan wrote:
Do you think it'll still work?
Yes, that's why I suggested it. ;-)
You might need to install the gcc-core, libcurl-devel, openssl-devel,
and subversion-perl packages first.
Regards,
Jonathan
On 2013-12-29 12.30, Antoine Pelisse wrote:
Mercurial can have bookmarks pointing to nullid (the empty root
revision), while Git can not have references to it.
When cloning or fetching from a Mercurial repository that has such a
bookmark, the import will fail because git-remote-hg will not be
On 2013-12-30 18.07, stephen_le...@stephe-leake.org wrote:
I forgot to do 'ssh-add', so a 'git fetch' running under Windows Emacs
Windows native emacs or emacs under cygwin ?
tried to prompt for the ssh passphrase, could not find an ssh passphrase
prompt program, and aborted.
That left the
On 2013-12-24 00.46, Duy Nguyen wrote:
[snip]
We don't complain about adding an empty directory before or after this patch.
Ok, thanks for the explanation.
I think that
https://www.kernel.org/pub/software/scm/git/docs/git-add.html
could deserve an update.
My understanding is that filepattern
On 2013-12-23 10.02, Nguyễn Thái Ngọc Duy wrote:
This behavior was added in 07d7bed (add: don't complain when adding
empty project root - 2009-04-28) then broken by 84b8b5d (remove
match_pathspec() in favor of match_pathspec_depth() -
2013-07-14). Reinstate it.
Noticed-by: Thomas Ferris
On 2013-12-20 10.12, Jeff King wrote:
On Thu, Dec 19, 2013 at 09:39:55AM -0800, Junio C Hamano wrote:
Torsten Bögershausen tbo...@web.de writes:
Thanks for an interesting reading,
please allow a side question:
Could it be, that -1 == unlimited is Linux specific?
And therefore not 100
On 2013-12-19 01.15, Jeff King wrote:
On Wed, Dec 18, 2013 at 02:59:12PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
Yes, that is locally OK, but depending on how the caller behaves, we
might need to have an extra saved_errno dance here, which I didn't
want to get into...
On 2013-12-14 11.54, Nguyễn Thái Ngọc Duy wrote:
We've been avoiding PATH_MAX whenever possible. This patch avoids
PATH_MAX in get_pathname() and gives it enough room not to worry about
really long paths.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
path.c | 28
On 12/13/2013 01:57 AM, Junio C Hamano wrote:
[Cooking]
* fc/transport-helper-fixes (2013-12-09) 6 commits
- remote-bzr: support the new 'force' option
- test-hg.sh: tests are now expected to pass
- transport-helper: check for 'forced update' message
- transport-helper: add 'force' to
On 2013-12-09 23.10, Junio C Hamano wrote:
Torsten Bögershausen tbo...@web.de writes:
The old log-line looked like this:
+ 9d498b0...8598732 master - master (forced update)
And the new one like this:
9d498b0..8598732 master - master
- Loosen the grep pattern by not demanding (forced
The old log-line looked like this:
+ 9d498b0...8598732 master - master (forced update)
And the new one like this:
9d498b0..8598732 master - master
- Loosen the grep pattern by not demanding (forced update)
- Improve the grep pattern and check the new SHA id
Signed-off-by: Torsten
On 2013-12-09 21.40, Thomas Gummerer wrote:
+test_expect_success 'git diff --no-index with broken index' '
+ cd repo
+ echo broken .git/index
+ git diff --no-index a ../non/git/a
^^
I'm confused: Does this work with the trailing ?
On 12/04/2013 07:48 PM, Marius Schamschula wrote:
Hi all,
Over the years I have built many versions of git and released them on hmug.org.
git 1.8.5.1 builds just fine under OS 10.7 (Lion) and 10.9 (Mavericks), but the
build fails (also for 1.8.5) on 10.8 (Mountain Lion):
snip
GIT_VERSION =
On 2013-11-30 13.01, Nguyễn Thái Ngọc Duy wrote:
Bug 6530 [1] causes git show v0.99.6~1 to fail with error your
causes or caused (as we have a work around?)
vsnprintf is broken. The workaround avoids that, but it corrupts
system error messages in non-C locales.
[snip]
The bug in glibc has been
gnu_glibc_version()=2.11.3 /* Ubuntu 10.4, no updates */
Sorry, Copy-paste error:
2.11.1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
() uses start_command() to invoke the command; consequently,
the limits of the system still apply, but are diagnosed only at execve()
time. But these limits are more lenient than the 1K that git_connect()
imposed.
Signed-off-by: Johannes Sixt j...@kdbg.org
Signed-off-by: Torsten Bögershausen tbo
Add more tests testing all the combinations:
-IPv4 or IPv6
-path starting with / or with /~
-with and without the ssh:// scheme
Some test fail, they need updates in connect.c
Signed-off-by: Torsten Bögershausen tbo...@web.de
---
t/t5601-clone.sh | 100
git_connect has grown large due to the many different protocols syntaxes
that are supported. Move the part of the function that parses the URL to
connect to into a separate function for readability.
Signed-off-by: Johannes Sixt j...@kdbg.org
Signed-off-by: Torsten Bögershausen tbo...@web.de
- separate URLs like file (which are local)
from URLs like host:repo which should use ssh
Add the new parameter --diag-url to git fetch-pack,
which prints the value for protocol, host and path to stderr and exits.
Signed-off-by: Torsten Bögershausen tbo...@web.de
---
builtin/fetch-pack.c | 14
could be used to determine if
the URL had a scheme or not: ssh://host/host != host.
After 356bec [::1] was converted into ::1, yielding
url != hostname as well.
Solution:
Don't use if (url != hostname), but look at the separator instead.
Rename the variable c into separator.
Signed-off-by: Torsten
Signed-off-by: Torsten Bögershausen tbo...@web.de
---
t/t5500-fetch-pack.sh | 59 +++
1 file changed, 59 insertions(+)
diff --git a/t/t5500-fetch-pack.sh b/t/t5500-fetch-pack.sh
index d87ddf7..a2b37af 100755
--- a/t/t5500-fetch-pack.sh
+++ b/t/t5500
:/user/repo should be used).
Signed-off-by: Torsten Bögershausen tbo...@web.de
---
connect.c | 57 +++
connect.h | 1 +
t/t5500-fetch-pack.sh | 7 +++
t/t5601-clone.sh | 8
transport.c | 12
-by: Jeff King p...@peff.net
Signed-off-by: Torsten Bögershausen tbo...@web.de
---
Comments to V6:
Code from Johannes Sixt is part of the series, original found here:
http://permalink.gmane.org/gmane.comp.version-control.git/237339
http://permalink.gmane.org/gmane.comp.version-control.git/237338
Changes
Commit faea9ccbadf75128 introduced user-relative paths:
ssh://host.xz/~junio/repo is the same as host.xz:~junio/repo.
Commit 356bece0a27258181 Support [address] in URLs introduced a regression:
When an URL like [::1]:/~repo is used, the replacement of /~
with ~ was enabled for IPv6 host names,
Add more tests testing all the combinations:
-IPv4 or IPv6
-path starting with / or with /~
-with and without the ssh:// scheme
Some test fail, they need updates in connect.c
---
t/t5601-clone.sh | 102 +--
1 file changed, 100 insertions(+),
Since day one, function git_connect() had a limit on the command line of
the command that is invoked to make a connection. 7a33bcbe converted the
code that constructs the command to strbuf. This would have been the
right time to remove the limit, but it did not happen. Remove it now.
Add test cases using git fetch-pack --diag-url:
- parse out host and path for URLs with a scheme (git:// file:// ssh://)
- parse host names embedded by [] correctly
- extract the port number, if present
- seperate URLs like file (which are local)
from URLs like host:repo which should use ssh
git_connect has grown large due to the many different protocols syntaxes
that are supported. Move the part of the function that parses the URL to
connect to into a separate function for readability.
Signed-off-by: Johannes Sixt j...@kdbg.org
---
connect.c | 80
-by: Jeff King p...@peff.net
Signed-off-by: Torsten Bögershausen tbo...@web.de
---
Changes since last version:
- updated t5601, thanks Peff
- Split up the patch into 10 commits
- Hannes suggested 2 patches
- Add tests for git fetch-pack, which verifies the parsing
- Added lots of test cases in t5500 via git
Since commit faea9ccb URLs host:~repo or ssh://host:/~repo
reach the home directory.
In 356bece0 support for [] was introduced, and as a side
effect, [host]:/~repo was the same as [host]:~repo.
The side effect was removed in c01049ae, connect.c: Corner case for IPv6.
Re-reading the documentation
Use get_host_and_port() even for ssh.
Remove the variable port git_connect(), and simplify parse_connect_url()
Use only one return point in git_connect(), doing the free() and return conn.
t5601 had 2 corner test cases which now pass.
---
connect.c | 47
The main purpose is to trace the URL parser called by git_connect() in
connect.c
The main features of the parser can be listed as this:
- parse out host and path for URLs with a scheme (git:// file:// ssh://)
- parse host names embedded by [] correctly
- extract the port number, if present
-
Make the function is_local() from tramsport.c public and use it
in both transport.c and connect.c
Use a protocol local for URLs for the local file system.
---
connect.c| 58 ++--
connect.h| 1 +
t/t5601-clone.sh | 10 +-
-by: Jeff King p...@peff.net
Signed-off-by: Torsten Bögershausen tbo...@web.de
---
Changes since last version:
- updated t5601, thanks Peff
- Split up the patch into 10 commits
- Hannes suggested 2 patches
- Add tests for git fetch-pack, which verifies the parsing
- Added lots of test cases in t5500 via git
Hej,
I think the patch went in and out in git.git, please see below.
(I coudn't the following in msysgit,
but if it was there, the clipped_write() for Windows could go away.
/Torsten
commit 0b6806b9e45c659d25b87fb5713c920a3081eac8
Author: Steffen Prohaska proha...@zib.de
Date: Tue Aug 20
On 2013-11-11 18.44, Junio C Hamano wrote:
Torsten Bögershausen tbo...@web.de writes:
git fetch-pack allows [host:]directory to point out the source
repository.
Use the term repository, which is already used in git fetch or git pull
to describe URLs supported by Git.
Sign-off?
Sorry
On 2013-11-08 23.29, Jeff King wrote:
On Fri, Nov 08, 2013 at 06:10:30PM +0100, Torsten Bögershausen wrote:
Side question:
Do we have enough test coverage for htonll()/ntohll(),
or do we want do the module test which I send a couple of days before ?
The series adds tests for building
On 2013-11-07 23.19, Jeff King wrote:
On Thu, Nov 07, 2013 at 09:58:02PM +, Ramsay Jones wrote:
These patches fix various errors/warnings on the cygwin, MinGW and
msvc builds, provoked by the jk/pack-bitmap branch.
Thanks. Your timing is impeccable, as I was just sitting down to
git fetch-pack allows [host:]directory to point out the source
repository.
Use the term repository, which is already used in git fetch or git pull
to describe URLs supported by Git.
---
Documentation/git-fetch-pack.txt | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff
On 2013-11-05 22.22, Johannes Sixt wrote:
Am 05.11.2013 21:45, schrieb Torsten Bögershausen:
On 2013-11-05 20.39, Johannes Sixt wrote:
Thanks for picking this up, please see some minor nits inline,
and git_connect() is at the end
-struct child_process *git_connect(int fd[2], const char
On 2013-11-05 01.00, Ramsay Jones wrote:
On 31/10/13 13:24, Torsten Bögershausen wrote:
On 2013-10-30 22.07, Ramsay Jones wrote:
[ ... ]
Yep, this was the first thing I did as well! ;-) (*late* last night)
I haven't had time today to look into fixing up the msvc build
(or a complete re
On 2013-11-05 20.39, Johannes Sixt wrote:
Thanks for picking this up, please see some minor nits inline,
and git_connect() is at the end
-struct child_process *git_connect(int fd[2], const char *url_orig,
- const char *prog, int flags)
+static enum protocol
Signed-off-by: Torsten Bögershausen tbo...@web.de
---
Changes since V3:
- Integrated Peffs suggestions in t5601
(Remove clear_ssh)
- Decide early if it is ssl or local in connect.c
- Use git fetch instead of git clone in t5601:
clone use absolute_path() (adding a / before :), fetch does
Signed-off-by: Torsten Bögershausen tbo...@web.de
---
Changes since V3:
- Integrated Peffs suggestions in t5601
(Remove clear_ssh)
- Decide early if it is ssl or local in connect.c
- Use git fetch instead of git clone in t5601:
clone use absolute_path() (adding a / before :), fetch does
Signed-off-by: Torsten Bögershausen tbo...@web.de
---
Changes since V3:
- Integrated Peffs suggestions in t5601
(Remove clear_ssh)
- Decide early if it is ssl or local in connect.c
- Use git fetch instead of git clone in t5601:
clone use absolute_path() (adding a / before :), fetch does
On 2013-10-30 22.07, Ramsay Jones wrote:
On 30/10/13 20:30, Torsten Bögershausen wrote:
On 2013-10-30 20.06, Ramsay Jones wrote:
On 30/10/13 17:14, Torsten Bögershausen wrote:
On 2013-10-30 18.01, Vicent Martí wrote:
On Wed, Oct 30, 2013 at 5:51 PM, Torsten Bögershausen tbo...@web.de
wrote
test-endianess.c adds test code for htonl(), ntohll()
and the recently introduced ntohll() and htonll()
The test is called in t0070
Signed-off-by: Torsten Bögershausen tbo...@web.de
---
.gitignore |1 +
Makefile |3 +++
t/t0070-fundamental.sh |3 +++
test
On 2013-10-28 20.28, Junio C Hamano wrote:
* jk/pack-bitmap (2013-10-28) 20 commits
There is a name clash under cygwin 1.7 (1.5 is OK)
The following first aid hot fix works for me:
/Torsten
$ git diff
diff --git a/compat/bswap.h b/compat/bswap.h
index ea1a9ed..8dc39be 100644
--- a/compat/bswap.h
On 2013-10-30 18.01, Vicent Martí wrote:
On Wed, Oct 30, 2013 at 5:51 PM, Torsten Bögershausen tbo...@web.de wrote:
There is a name clash under cygwin 1.7 (1.5 is OK)
The following first aid hot fix works for me:
/Torsten
If Cygwin declares its own bswap_64, wouldn't it be better to use
On 2013-10-30 18.14, Torsten Bögershausen wrote:
On 2013-10-30 18.01, Vicent Martí wrote:
On Wed, Oct 30, 2013 at 5:51 PM, Torsten Bögershausen tbo...@web.de wrote:
There is a name clash under cygwin 1.7 (1.5 is OK)
The following first aid hot fix works for me:
/Torsten
If Cygwin declares
On 2013-10-30 20.06, Ramsay Jones wrote:
On 30/10/13 17:14, Torsten Bögershausen wrote:
On 2013-10-30 18.01, Vicent Martí wrote:
On Wed, Oct 30, 2013 at 5:51 PM, Torsten Bögershausen tbo...@web.de wrote:
There is a name clash under cygwin 1.7 (1.5 is OK)
The following first aid hot fix works
!= url), which never
worked for host names with literal IPv6 adresses, embedded by []
Support for the [] URLs was introduced in 356bece0a.
- Do not tamper local URLs starting with '[' which have a ']'
Signed-off-by: Torsten Bögershausen tbo...@web.de
---
(Thanks for the reviews)
Changes since
!= url), which never
worked for host names with literal IPv6 adresses, embedded by []
Support for the [] URLs was introduced in 356bece0a.
- Do not tamper local URLs starting with '[' which have a ']'
Signed-off-by: Torsten Bögershausen tbo...@web.de
---
(This does apply on pu, not on master
!= url), which never
worked for host names with literal IPv6 adresses, embedded by []
Support for the [] URLs was introduced in 356bece0a.
- Do not tamper local URLs starting with '[' which have a ']'
Signed-off-by: Torsten Bögershausen tbo...@web.de
---
(This does apply on pu, not on master
On 20.10.13 08:05, Ondřej Bílka wrote:
On Sun, Oct 20, 2013 at 07:47:06AM +0200, Torsten Bögershausen wrote:
(may be s/path is too big/path is too long/ ?)
On 19.10.13 12:52, Antoine Pelisse wrote:
Currently, most buffers created with PATH_MAX length, are not checked
when being written
(may be s/path is too big/path is too long/ ?)
On 19.10.13 12:52, Antoine Pelisse wrote:
Currently, most buffers created with PATH_MAX length, are not checked
when being written, and can overflow if PATH_MAX is not big enough to
hold the path.
Fix that by using strlcpy() where strcpy() was
(Please, not top-posting)
On Oct 12, 2013, at 8:47 AM, brian m. carlson
sand...@crustytoothpaste.net wrote:
On Fri, Oct 11, 2013 at 11:06:17PM -0500, Fernando Ortiz (e2k) wrote:
I'm getting the following error when I do:
git send-email --compose --from Fernando Ortiz eratos2...@gmail.com
On 05.10.13 21:48, Torsten Bögershausen wrote:
On 2013-10-03 03.31, Jeff King wrote:
http://article.gmane.org/gmane.comp.version-control.git/235473
What do we think about extending the test a little bit:
git diff 771cf1dab9303bab3c8198b8b6 -- t5602-clone-remote-exec.sh
diff --git a/t
On 2013-09-29 02.33, Duy Nguyen wrote:
On Sun, Sep 29, 2013 at 2:37 AM, Torsten Bögershausen tbo...@web.de wrote:
git clone /foo/bar:baz or git clone ../foo/bar:baz
are meant to clone from the local file system, and not to clone
from a remote server over git-over-ssh.
I don't think
On 2013-09-27 23.56, Jonathan Nieder wrote:
Nguyễn Thái Ngọc Duy wrote:
commit 6000334 (clone: allow cloning local paths with colons in them -
2013-05-04) is added to make it possible to specify a path that has
colons in it without file://, e.g. ../foo:bar/somewhere. But the check
is a bit
git clone /foo/bar:baz or git clone ../foo/bar:baz
are meant to clone from the local file system, and not to clone
from a remote server over git-over-ssh.
Signed-off-by: Torsten Bögershausen tbo...@web.de
---
connect.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
* jx/relative-path-regression-fix (2013-09-20) 3 commits
- Use simpler relative_path when set_git_dir
- relative_path should honor dos-driver-prefix
- test: use unambigous leading path (/foo) for mingw
Waiting for the review to settle.
Is this V3, which is both fixing a regression
and
On 2013-09-17 21.32, Johannes Sixt wrote:
Am 17.09.2013 10:24, schrieb Jiang Xin:
I have checked the behavior of UNC path on Windows (msysGit):
* I can cd to a UNC path:
cd //server1/share1/path
* can cd to other share:
cd ../../share2/path
* and can cd to other server's share:
On 2013-09-18 16.37, Torsten Bögershausen wrote:
On 2013-09-17 18.12, Junio C Hamano wrote:
Jiang Xin worldhello@gmail.com writes:
diff --git a/compat/mingw.h b/compat/mingw.h
index bd0a88b..06e9f49 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -311,6 +311,15 @@ int
On 13.09.13 07:08, Jiang Xin wrote:
Tvangeste found that the relative_path function could not work
properly on Windows if in and prefix have dos driver prefix.
($gmane/234434)
e.g., When execute: test-path-utils relative_path C:/a/b D:/x/y,
should return C:/a/b, but returns ../../C:/a/b,
On 2013-09-13 21.51, Junio C Hamano wrote:
Jiang Xin worldhello@gmail.com writes:
In test cases for relative_path, path with one leading character
(such as /a, /x) may be recogonized as a:/ or x:/ if there is
such doc drive on MINGW platform. Use an umambigous leading path
/foo instead.
On 13.09.13 06:55, Jiang Xin wrote:
2013/9/13 Junio C Hamano gits...@pobox.com:
For systems that need POSIX escape hatch for Apollo Domain ;-), we
would need a bit more work. When both path1 and path2 begin with a
double-dash, we would need to check if they match up to the next
slash, so
On 2013-09-12 11.12, Jiang Xin wrote:
Tvangeste found that the relative_path function could not work
properly on Windows if in and prefix have dos driver prefix.
($gmane/234434)
e.g., When execute: test-path-utils relative_path C:/a/b D:/x/y,
should return C:/a/b, but returns ../../C:/a/b,
(Sorry for the somewhat late reply, thanks for review)
Torsten Bögershausen tbo...@web.de writes:
When core.precomposeunicode was introduced, it was set to false
by default, to be compatible with older versions of Git.
Whenever UTF-8 file names are used in a mixed environment,
the Mac OS
can be achieved,
so set core.precomposeunicode to true on a decomposing file system.
Signed-off-by: Torsten Bögershausen tbo...@web.de
---
compat/precompose_utf8.c | 7 ++-
t/t0050-filesystem.sh| 1 +
t/t3910-mac-os-precompose.sh | 2 +-
t/t7400-submodule-basic.sh | 1 -
4 files
On 27.08.13 16:49, Junio C Hamano wrote:
Torsten Bögershausen tbo...@web.de writes:
... see if that path can be seen under its alias. Why do we set it
to false? Isn't this the true culprit?
After all, this is not in the reinit codepath, so we know we are
dealing with a repository
On 27.08.13 17:10, Ron Tregaskis - NOAA Federal wrote:
Does git work with Eclipse?
No.
If the question is does Eclipse work with git: yes.
For more information please feel free to spend some seconds using a seach
engine.
--
To unsubscribe from this list: send the line unsubscribe git in
the
On 2013-08-27 18.27, Junio C Hamano wrote:
Torsten Bögershausen tbo...@web.de writes:
2)
When we access a repo from Windows/Linux using SAMBA,
You mean s/repo/repository that resides on HFS+/?
Sorry being unclear here, trying being clearer with an example:
I have a /data/Docs on my linux
On 2013-08-20 08.43, Steffen Prohaska wrote:
[]
Thanks for V5. It was tested OK on my system here.
(And apologies for recommending a wrapper on top of a wrapper).
One question is left:
As xread() is tolerant against EAGAIN and especially EINTR,
could it make sense to replace read() with xread()
On 2013-08-19 08.38, Steffen Prohaska wrote:
[snip]
diff --git a/builtin/var.c b/builtin/var.c
index aedbb53..e59f5ba 100644
--- a/builtin/var.c
+++ b/builtin/var.c
@@ -38,6 +38,7 @@ static struct git_var git_vars[] = {
{ , NULL },
};
+#undef read
This is techically right for
On 2013-08-17 14.40, Steffen Prohaska wrote:
Previously, filtering more than 2GB through an external filter (see
test) failed on Mac OS X 10.8.4 (12E55) with:
error: read from external filter cat failed
error: cannot feed the input to external filter cat
error: cat died of
On 2013-08-11 08.45, Илья Воронцов wrote:
git under windows doesn't check case of letters in filename. So when
one rename for example images from *.JPG to *.jpg, git doesn't files
in a repository so when one deliver this repo on *nix -system, old
filenames preserve and this matters.
It can be
On 2013-08-01 22.51, Ramsay Jones wrote:
Junio C Hamano wrote:
Ramsay Jones ram...@ramsay1.demon.co.uk writes:
I am personally in favor of this simpler solution. Comments?
I had expected this to me marked for 'master'.
Has this simply been overlooked, or do you have reservations about
901 - 1000 of 1221 matches
Mail list logo
