On Tue, Feb 18, 2014 at 08:13:16AM +0100, Daniel Stenberg wrote:
> >Right; I'd expect multiple connections for parallel requests, but
> >in this case we are completing the first and removing the handle
> >before starting the second. Digging further, I was able to
> >reproduce the behavior with a s
On Sun, Feb 16, 2014 at 05:22:45PM +0100, David Kastrup wrote:
> Not really relevant to this patch, but looking at the output of
>
> git grep config_error_nonbool
>
> seems like a serious amount of ridiculousness going on. The header
> shows
>
> cache.h:extern int config_error_nonbool(const ch
Hi
I've got a repository where "git log --raw > _somefile" took a few
seconds in the past, but after an attempt at merging some commits that
were collected in a clone of the same repo that was created about a
year ago, I noticed that this command was now taking 3 minutes 7
seconds. "git gc", "git
On Mon, 17 Feb 2014, Jeff King wrote:
Right; I'd expect multiple connections for parallel requests, but in this
case we are completing the first and removing the handle before starting the
second. Digging further, I was able to reproduce the behavior with a simple
program:
Yeah, given your d
Without this when maintaining stable branches it's easy to forget to use
-x to track where a patch was cherry-picked from.
Signed-off-by: Guido Günther
---
Documentation/git-cherry-pick.txt | 8
builtin/revert.c | 10 ++
2 files changed, 18 insertions(+)
diff
On Mon, Feb 17, 2014 at 03:12:48PM -0500, Murtuza Mukadam wrote:
> We have linked peer review discussions on
> git@vger.kernel.org to their respective commits within the main
> git.git repository. You can view the linked reviews from 2012
> until present in the GitHub repo at:
> https://github.com
On Tue, Feb 18, 2014 at 12:52:28AM +0100, Johannes Schindelin wrote:
> Hopefully the Postfix Greylisting Policy Server will not try again to
> greylist me, as it might however do without violating the RFC.
>
> -- Forwarded message --
> Date: Tue, 18 Feb 2014 00:38:54 +0100 (CET)
>
On Sun, Feb 16, 2014 at 01:18:52PM +0100, Daniel Stenberg wrote:
> On Sat, 15 Feb 2014, Kyle J. McKay wrote:
>
> >If pipelining is off (the default) and total connections is not 1
> >it sounds to me from the description above that the requests will
> >be executed on separate connections until the
Hopefully the Postfix Greylisting Policy Server will not try again to
greylist me, as it might however do without violating the RFC.
-- Forwarded message --
Date: Tue, 18 Feb 2014 00:38:54 +0100 (CET)
From: Johannes Schindelin
To: msys...@googlegroups.com
Cc: git@vger.kernel.org
S
On Sun, Feb 16, 2014 at 02:33:06PM +0100, Daniel Stenberg wrote:
> On Sun, 16 Feb 2014, Daniel Stenberg wrote:
>
> >Right, the problem is there to make sure that a NTLM-auth
> >connection with different credentials aren't re-used. NTLM with its
> >connection-oriented authentication breaks the tra
>From the Git Bash command line, I enter
$ git difftool
and type y when the file I want to difference appears. Git correctly
calls the external diff tool (LVCompare.exe), but the path for the remote
file Git passes to that tool is malformed (e.g.,
C:\/Users/Paul/AppData/Local/Temp/QCpqLa_calcLo
Duy Nguyen gmail.com> writes:
> Prevent is a strong word. I meant we only do it if they force
> it. Something like this..
>
I would propose to make this even stronger:
Forbid to create any branches which start with any of:
- "refs/"
- "heads/"
- "remotes/"
- "tags/"
as long as you do not use th
Hello All,
We have linked peer review discussions on
git@vger.kernel.org to their respective commits within the main
git.git repository. You can view the linked reviews from 2012
until present in the GitHub repo at:
https://github.com/mmukadam/git/tree/review
If you want to search for the reviews
David Kastrup writes:
> Thomas Rast writes:
>
>> David Kastrup writes:
>>
>>> When comparing two branches, decorating the flat diff with the
>>> respectively responsible commits seems like it would be nice to do/have
>>> (the blame on the identical parts, in contrast, is not really
>>> interest
I looked into this and they seem to be deliberately holding off onto a
release due to some max path issues on Windows:
https://github.com/msysgit/git/pull/122
Also there are some unofficial builds for 1.8.5.4 I think, you just
have to Google for it.
On Mon, Feb 17, 2014 at 9:45 AM, Dr. Torsten Th
On Mon, Feb 17, 2014 at 04:45:20PM +0100, Dr. Torsten Thurow wrote:
> Hello,
>
> many thanks for all your working. Git is a very good help tool. A
> smal bug is on your download website for windows. Here we can read:
> "Latest stable release 1.9.0 Release Notes (2014-02-14) Download for
> Windows"
Hi Tay,
On Mon, 17 Feb 2014, Tay Ray Chuan wrote:
> Posting to msysgit since this was on Windows.
Thanks.
> On Mon, Feb 17, 2014 at 3:45 PM, youngseonkim <1.youngsun@gmail.com>
> wrote:
> > git svn clone https://my.svn.repo/url --stdlayout
> >
> > When I test a small svn repository and 're
Hello,
many thanks for all your working. Git is a very good help tool. A smal
bug is on your download website for windows. Here we can read:
"Latest stable release 1.9.0 Release Notes (2014-02-14) Download for
Windows", but the link loads Git-1.8.5.2.preview20131230.exe
--
Mit freundlichen Gr
When displaying a blob in gitweb, if it's an image, specify constraints for
maximum display width and height to prevent the image from overflowing the
frame of the enclosing page_body div.
This change assumes that it is more desirable to see the whole image without
scrolling (new behavior) than it
On Mon, Feb 10, 2014 at 3:19 AM, Torsten Bögershausen wrote:
>
> On 2014-02-08 09.53, Duy Nguyen wrote:
file-watcher.c | 32
1 file changed, 32 insertions(+)
>>>
>>> I feel a little bit unsure about the 700.
>>> Most often Git does not care about permissio
On Mon, Feb 17, 2014 at 4:36 PM, Daniel Hahler
wrote:
> On 09.02.2014 10:08, Duy Nguyen wrote:
>> On Tue, Feb 04, 2014 at 11:20:39AM +0100, Daniel Hahler wrote:
>
> Thanks for looking into this.
>
>>> when using a submodule "sm", there is a relative worktree in its config:
>>>
>>>.git/modules/
Since 1a72cfd (commit -v: strip diffs and submodule shortlogs from the
commit message - 2013-12-05) we have a less fragile way to cut out
"git status" at the end of a commit message but it's only enabled for
stripping submodule shortlogs. Add new cleanup option that reuses the
same mechanism for th
Signed-off-by: Nguyễn Thái Ngọc Duy
---
wt-status.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/wt-status.c b/wt-status.c
index 4e55810..65e35c3 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -17,7 +17,7 @@
#include "strbuf.h"
#include "utf8.h"
-static char cut_line[] =
Signed-off-by: Nguyễn Thái Ngọc Duy
---
wt-status.c | 19 ---
wt-status.h | 1 +
2 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/wt-status.c b/wt-status.c
index 65e35c3..ed31b6a 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -808,6 +808,17 @@ void wt_status_truncat
Slight changes in git-commit.txt and some commit messages after Brian
and Eric's comments.
Nguyễn Thái Ngọc Duy (3):
wt-status.c: make cut_line[] const to shrink .data section a bit
wt-status.c: move cut-line print code out to wt_status_add_cut_line
commit: add --cleanup=scissors
Documenta
Posting to msysgit since this was on Windows.
--
Cheers,
Ray Chuan
On Mon, Feb 17, 2014 at 3:45 PM, youngseonkim <1.youngsun@gmail.com> wrote:
> Hi, I really wonder about this happen.
> I want svn→git migrate, and I use this command.
>
> git svn clone https://my.svn.repo/url --stdlayout
>
>
Thomas Rast writes:
> David Kastrup writes:
>
>> When comparing two branches, decorating the flat diff with the
>> respectively responsible commits seems like it would be nice to do/have
>> (the blame on the identical parts, in contrast, is not really
>> interesting). Is there any tool that pro
David Kastrup writes:
> When comparing two branches, decorating the flat diff with the
> respectively responsible commits seems like it would be nice to do/have
> (the blame on the identical parts, in contrast, is not really
> interesting). Is there any tool that provides something like that?
T
Dario Bertini writes:
> On 02/14/2014 09:03 PM, Junio C Hamano wrote:
>> This is a combined diff, and yaml-related lines are added relative
>> to your _other_ branch you are merging (notice these + are indented
>> by one place). Relative to what you had at the tip of your branch
>> before you st
On 09.02.2014 10:08, Duy Nguyen wrote:
> On Tue, Feb 04, 2014 at 11:20:39AM +0100, Daniel Hahler wrote:
Thanks for looking into this.
>> when using a submodule "sm", there is a relative worktree in its config:
>>
>>.git/modules/sm/config:
>>[core]
>> worktree = ../../../smworktree
>>
There are two problems here:
1) If no argument is provided, then the command segfaults
2) The argument is not consumed, so there will be excess output
Fix both of these in one go by restructuring the handler for this
option.
Reported-by: Daniel Hahler
Signed-off-by: John Keeping
---
builtin/r
I have noticed that the output from "git rev-parse --resolve-git-dir" changed.
While it used to only print the resolved git dir, it now prints the argument
passed to it itself:
% git rev-parse --resolve-git-dir .git
/path/to/root/.git/modules/vim/bundle/reporoot
.git
This is with Gi
32 matches
Mail list logo
