2013/9/18 Junio C Hamano gits...@pobox.com:
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 winansi_fprintf(FILE *stream, const char *format,
...)
On Tue, Sep 17, 2013 at 11:46 PM, Junio C Hamano gits...@pobox.com wrote:
I don't think people on other platforms seeing the ugliness is really
an issue. After all, the file is called git-*compat*-util.h;
Well, judging from the way Linus reacted to the patch, I'd have to
disagree. After
Thanks a lot for your answer.
That's really good arguments that i was waiting for and that i have
not get until now.
My comprehension now :
- it's not easy to maintain several versions of a binary file in parallel.
So basically, it's not recommanded to have complex workflow for binary files.
In
On Tue, Sep 17, 2013 at 1:06 AM, Jens Lehmann jens.lehm...@web.de wrote:
Thanks Jens for having a look!
Am 15.09.2013 19:38, schrieb Tay Ray Chuan:
When 'update' is run with no path in a repository with uninitialized
submodules, the program terminates with no output, and zero status code.
Be
On Wed, Sep 18, 2013 at 5:43 AM, Sebastian Schuberth
sschube...@gmail.com wrote:
My feeling is that Linus' reaction was more about that this
work-around is even necessary (and MinGW is buggy) rather than
applying it to git-compat-util.h and not elsewhere.
So I think it's an annoying MinGW
In pack version 4, ref-delta technically could be used to compress any
objects including commits and trees (both canonical and v4). But it
does not make sense to do so. It can only lead to performance
degradation. Catch those packers.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
I
Hello,
I am trying to clone a repository and I am getting the following output:
$ git clone -q git://kernel.ubuntu.com/ubuntu/linux.git
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed
The fatal: lines usually appear a few minutes after running the clone. Of
When --shallow-file is added to the command line, it has to be
before the subcommand name, the first argument won't be the command
name any more. Stop assuming that and keep track of the command name
explicitly.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
fetch-pack.c | 10
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 Wed, 18 Sep 2013, Nguyễn Thái Ngọc Duy wrote:
In pack version 4, ref-delta technically could be used to compress any
objects including commits and trees (both canonical and v4). But it
does not make sense to do so. It can only lead to performance
degradation. Catch those packers.
* commit 21cf32279120799a766d22416be7d82d9ecfbd04
|
| Author: Huynh Khoi Nguyen Nguyen huynh-khoi-nguyen.ngu...@ensimag.imag.fr
| Date: Fri Jun 22 11:03:23 2012 +0200
|
|config: read (but not write) from $XDG_CONFIG_HOME/git/config file
|
|Teach git to read the gitconfig information
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
Madhu enom...@meer.net writes:
* commit 21cf32279120799a766d22416be7d82d9ecfbd04
|
| Author: Huynh Khoi Nguyen Nguyen huynh-khoi-nguyen.ngu...@ensimag.imag.fr
| Date: Fri Jun 22 11:03:23 2012 +0200
|
|config: read (but not write) from $XDG_CONFIG_HOME/git/config file
|
|Teach
This sounds suspiciously like 05e95155 (upload-pack: send keepalive
packets during pack computation, 2013-09-08) that is cooking in
'next'.
If you are talking with other people's server side, you are SOL
until the server end gets the patch.
--
To unsubscribe from this list: send the line
Jiang Xin worldhello@gmail.com writes:
2013/9/18 Junio C Hamano gits...@pobox.com:
+ if (!is_dir_sep(*path) || !is_dir_sep(*(path+1)) ||
is_dir_sep(*(path+2)))
+ return 0;
If path[1] == '\0', it would be !is_dir_sep() and we end up
inspecting past the end of the string?
One of our Perl scripts that does a git clone suddenly
started to fail when I upgraded to git 1.8.4 from 1.8.3.1.
The failing Perl code used a construct like this:
Git::command_oneline('clone', $url, $path);
There is no error raised, but the directory specified by
$path is not
Similar to Bash's default filename completion, our git-aware filename
completion stops at directory boundaries, i.e. it doesn't offer the
full 'path/to/file' at first, but only 'path/'. To achieve that the
completion script runs 'git ls-files' with specific command line
options to get the list of
I think the pack v4 format and compatibility code is pretty stable now,
and probably as optimal as it can reasonably be.
@Junio: might be a good idea to refresh your pu branch again.
Now the biggest problem to solve is the actual tree
deltification. I don't have the time to spend on this
On Wed, Sep 18, 2013 at 11:16:15AM -0700, Junio C Hamano wrote:
I wondered if this is something we can have a test for easily.
Unlike the --upload-pack option, there is no way for the receiving
end to choose which index-pack (or unpack-objects) to run, but we
may force a failure by
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
When --shallow-file is added to the command line, it has to be
before the subcommand name, the first argument won't be the command
name any more. Stop assuming that and keep track of the command name
explicitly.
Signed-off-by: Nguyễn Thái Ngọc
On Wed, Sep 18, 2013 at 02:44:18PM +0200, Marek Vasut wrote:
I am trying to clone a repository and I am getting the following output:
$ git clone -q git://kernel.ubuntu.com/ubuntu/linux.git
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed
The fatal:
[I posted this via gmane (m3mwnac9ob@leonis4.robolove.meer.net)
but the posting hasn't appeared, so I'm sending this by email..]
* Matthieu Moy vpq8uyuxjfe@anie.imag.fr :
Wrote on Wed, 18 Sep 2013 17:01:57 +0200:
| * commit 21cf32279120799a766d22416be7d82d9ecfbd04
| |In the order of
Apologies for top post -- anybody have a recommendation for a better app then
maildroid?
Will this not conflict with folks that supply their own gitconfig?
I like the idea. Docs? Also, should this not be done in the C side so that we
don't waste time reading the config, and also prevent users
On Wed, Sep 18, 2013 at 06:52:13PM +0200, Peter Kjellerstedt wrote:
The failing Perl code used a construct like this:
Git::command_oneline('clone', $url, $path);
There is no error raised, but the directory specified by
$path is not created. If I look at the process using strace
I
On Wed, Sep 18, 2013 at 1:13 PM, David Aguilar dav...@gmail.com wrote:
Apologies for top post -- anybody have a recommendation for a better app then
maildroid?
Will this not conflict with folks that supply their own gitconfig?
You mean people that provide their own ETC_GITCONFIG? If you mean
On Tuesday, September 17, 2013 09:45:26 PM Nicolas Adenis-Lamarre wrote:
Ooops. It seems that each time somebody says these two words together,
people hate him, and he is scorned by friends and family.
See the thread intend-to-edit flag for one implementation idea:
On Wed, Sep 18, 2013 at 02:45:51PM -0400, Jeff King wrote:
That being said, the new messages should almost certainly go to stderr.
-- 8 --
Subject: [PATCH] clone: write checking connectivity to stderr
In commit 0781aa4 (clone: let the user know when
check_everything_connected is run,
Hello.
I don't believe that git-cvsexportcommit.perl is working properly.
First off, invocations of git-apply fail on my system. git apply works.
(The aforementioned script uses the former.)
Second, please have a look at this output (specific strings have been replaced
with 'foo')
Am 18.09.2013 12:12, schrieb Tay Ray Chuan:
On Tue, Sep 17, 2013 at 1:06 AM, Jens Lehmann jens.lehm...@web.de wrote:
Thanks Jens for having a look!
Am 15.09.2013 19:38, schrieb Tay Ray Chuan:
When 'update' is run with no path in a repository with uninitialized
submodules, the program
Jeff King p...@peff.net writes:
On Wed, Sep 18, 2013 at 02:45:51PM -0400, Jeff King wrote:
That being said, the new messages should almost certainly go to stderr.
-- 8 --
Subject: [PATCH] clone: write checking connectivity to stderr
In commit 0781aa4 (clone: let the user know when
Jeff King p...@peff.net writes:
The keepalive patch is not in any released version yet, but we have been
running it in production at GitHub for a few weeks.
That is good to hear; I'd feel safer to bump the scheduled
graduation date to 'master' for the topic in that case.
Like tomorrow ;-)
--
When stderr does not point to a tty, we typically suppress
we are now in this phase progress reporting (e.g., we ask
the server not to send us counting objects and the like).
The new checking connectivity message is in the same vein,
and should be suppressed. Since clone relies on the
transport
On Wed, Sep 18, 2013 at 12:31:23PM -0700, Junio C Hamano wrote:
Hrm, this actually breaks t5701, which expects clone 2err to print
nothing to stderr.
Hmm, where in t5701? Ah, you meant t5702 and possibly t5601.
Yes, sorry, I meant t5702.
I actually think it is long and not meant to be
On Wed, Sep 18, 2013 at 04:06:50PM -0400, Jeff King wrote:
Note that we do not set up that progress flag for a local
clone, as we do not fetch using the transport at all. That's
acceptable here, though, because we also do not perform a
connectivity check in that case.
Signed-off-by: Jeff
Hi,
Jeff King p...@peff.net writes:
The keepalive patch is not in any released version yet, but we have been
running it in production at GitHub for a few weeks.
That is good to hear; I'd feel safer to bump the scheduled
graduation date to 'master' for the topic in that case.
Like
On 09/18/2013 01:15 AM, Nicolas Adenis-Lamarre wrote:
Ooops. It seems that each time somebody says these two words together,
people hate him, and he is scorned by friends and family.
However,
- gitolite implement it (but gitolite is not git).
No. It pretends to implement it, for people who
From: Jeff King p...@peff.net
Most of git's traversals are robust against minor breakages
in commit data. For example, git log will still output an
entry for a commit that has a broken encoding or missing
author, and will not abort the whole operation.
Shortlog, on the other hand, will die as
On 09/18/2013 03:42 PM, Nicolas Adenis-Lamarre wrote:
Thanks a lot for your answer.
That's really good arguments that i was waiting for and that i have
not get until now.
My comprehension now :
- it's not easy to maintain several versions of a binary file in parallel.
So basically, it's
On Thu, Sep 19, 2013 at 12:40 AM, Nicolas Pitre n...@fluxnic.net wrote:
I think the pack v4 format and compatibility code is pretty stable now,
and probably as optimal as it can reasonably be.
@Junio: might be a good idea to refresh your pu branch again.
Now the biggest problem to solve is
On Wed, Sep 18, 2013 at 1:13 PM, David Aguilar dav...@gmail.com wrote:
Will this not conflict with folks that supply their own gitconfig?
You mean people that provide their own ETC_GITCONFIG? If you mean
distributions, their packaging would override /etc/gitconfig, if you
mean people that have
40 matches
Mail list logo
