Feature requst

"git grep xxx" currently does not follow symlinks. Please consider adding this functionality Thx YuriW

Git doesn't always add files to a commit (amend)

nning git-2.9.0. Regards, Yuri -- 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

Can't get 'git archive' to work

t=tar --remote=http://github.com/yurivict/vm-to-tor.git fatal: Operation not supported by protocol. git-2.6.2 on FreeBSD 10.2 Yuri -- 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

Re: A better git log --graph?

On 01/08/2015 08:52 AM, Kyle J. McKay wrote: Since --graph is text-based, this response may not be on-topic hence no cc: to the list. I see --graph as an important tool to get an overview on how the development is being done. I don't mind having a graphical tool for the job, and I was even

A better git log --graph?

Hi everyone, git log --graph is hard for me to parse mentally when developing a project which has a lot of branches. All the tools I've been using seem to just parse log --graph's output, and thus are no better at showing history. I would love to have a graph mode where each branch is assigned

Re: A better git log --graph?

On 01/07/2015 04:47 PM, Johan Herland wrote: Have you looked at git show-branch --all? I didn't. Helpful, but I need to get used to the output. The first impression after looking at some random repository histories is that it's still not what I had in mind, though. -- To unsubscribe from this

Thinning a repository

Hi everyone, Is there a quick way to reproduce the effect of a shallow clone on a local repository that doesn't involve filter-branch and/or re-clone? My motivation is to reduce the local size of repositories I'm only following, by trimming the history without prejudice to a [N] set of last

Re: Thinning a repository

On 11/30/2014 01:34 PM, Fredrik Gustafsson wrote: On Sun, Nov 30, 2014 at 01:18:34PM +0100, Yuri D'Elia wrote: Is there a quick way to reproduce the effect of a shallow clone on a local repository that doesn't involve filter-branch and/or re-clone? I'm curious, why is it a bad thing to do

Re: [PATCH 2/3] setup_pager: set MORE=R

script check if the current PAGER supports colors and build git accordingly? configure could run the pager as one of its tests, and determine if ESC appears on the output. Yuri -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org

Re: [PATCH 2/3] setup_pager: set MORE=R

for example. Such 'experimental' approach is maybe more reliable. Yuri -- 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

Re: 'git log' escape symbols shown as ESC[33 and ESC[m

For me, if git would have told me that my pager doesn't support escape sequences, I could have taken it from there. Yuri -- 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

'git diff' command doesn't honor utf8 symbol boundaries, and doesn't use actual terminal width

truncation size is made somewhere in 'git diff' command. Suggested behavior: 1. git should respect utf8, and in case of truncation it should add … symbol. 2. truncation algorithm should read current terminal width and truncate at width-1 length to allow for the above-mentioned symbol Yuri

Re: [PATCH 0/3] improved out-of-the-box color settings

On 01/16/2014 20:14, Jeff King wrote: The second patch turns on MORE=R only for FreeBSD. Yuri, if you can confirm that my patch works for you, that would be excellent. And if you (or anyone) has access to NetBSD or OpenBSD to test the second patch on, I'd welcome updates to config.mak.uname

Re: git quietly fails on https:// URL, https errors are never reported to user

-0400 I think that in a rare case of error this extra-printout wouldn't hurt. I also made this message more user friendly, without mentioning the term helper. Yuri diff --git a/transport-helper.c b/transport-helper.c index 2010674..5ea2831 100644 --- a/transport-helper.c +++ b/transport-helper.c

Re: 'git log' escape symbols shown as ESC[33 and ESC[m

like this: MORE_DASH_R_WORKS This would be very accurate. Not sure if this is an overkill for this issue. Yuri -- 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

Re: git quietly fails on https:// URL, https errors are never reported to user

case is the one Yuri hit: some library misconfiguration that causes the helper not to run at all. Adding back any message is hurting the common case to help the uncommon one. But you can use the error code value to convey the cause of the failure to git, and avoid an unnecessary message in git

Date format in 'git log' should be in local timezone

-like systems. Yuri -- 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

git quietly fails on https:// URL, https errors are never reported to user

(in this and other locations) are reported to the user, and git never quits on error without saying what the error is. git-1.8.5.2 Yuri -- 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

Re: git quietly fails on https:// URL, https errors are never reported to user

the supporting libraries and didn't report it. I can't tell now because I updated and the problem is gone. Yuri -- 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

'git log' escape symbols shown as ESC[33 and ESC[m

? Is this because this is some kind of linuxism that doesn't work on FreeBSD maybe? Also, there are the termcap functions that allow to determine what does the actual terminal supports. You should first check for cap bits corresponding to the features you expect, if you expect something uncommon. Yuri

Re: 'git log' escape symbols shown as ESC[33 and ESC[m

? Yuri -- 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

Re: Load testing of git

Thanks to everyone. The information was useful. On 24 February 2013 21:31, Shawn Pearce spea...@spearce.org wrote: On Sun, Feb 24, 2013 at 8:58 AM, Thomas Koch tho...@koch.ro wrote: Yuri Mikhailov: Dear Git community, I am a Software Developer and I have been using git for a while