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 Git
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 genml+git-2...@thequod.de
Signed-off-by:
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
Dario Bertini berda...@gmail.com 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
David Kastrup d...@gnu.org 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
Thomas Rast t...@thomasrast.ch writes:
David Kastrup d...@gnu.org 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
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
When I
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
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
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
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
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
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 the
On Mon, Feb 17, 2014 at 4:36 PM, Daniel Hahler
genml+git-2...@thequod.de 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:
On Mon, Feb 10, 2014 at 3:19 AM, Torsten Bögershausen tbo...@web.de 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 permissions,
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
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
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 'real working
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, but
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
David Kastrup d...@gnu.org writes:
Thomas Rast t...@thomasrast.ch writes:
David Kastrup d...@gnu.org 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
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
Duy Nguyen pclouds at 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 the
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.,
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
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 johannes.schinde...@gmx.de
To:
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
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)
From:
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:
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 a...@sigxcpu.org
---
Documentation/git-cherry-pick.txt | 8
builtin/revert.c | 10 ++
2 files changed, 18
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
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 fsck,
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 char *);
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 simple
32 matches
Mail list logo
