On Fri, Oct 11, 2013 at 12:35 PM, Stefan Zager wrote:
> For my test, I first run 'git clone -n ', and then measure the
> running time of 'git checkout --force HEAD'. On linux, the checkout
> command runs in 0:12; on Windows, it's about 3:30.
try
git read-tree HEAD
git ls-files | xargs -P=XXX -n
On Thu, Oct 10, 2013 at 5:51 PM, Karsten Blees wrote:
> >> I've noticed that when working with a very large repository using msys
> >> git, the initial checkout of a cloned repository is excruciatingly
> >> slow (80%+ of total clone time). The root cause, I think, is that git
> >> does all the fi
As discussed on #git irc:
git init
vim file1
vim file2
git add file1
git add file2
git commit -m 'foo'
vim file1
vim file2
vim file3
vim file4
git add -p file1 # add part of file1, use 'e' to change code too.
git add file2 # add all of file2
git add file3
git stash # do a stash
hack hack hack
git
Am 10.10.2013 22:19, schrieb Sebastian Schuberth:
> Please keep in mind to CC the msysgit mailing list for Windows-specific
> stuff. I'm also CC'ing Karsten who has worked on performance improvements for
> Git for Windows in the past.
>
Thanks
> Thanks for bringing this up!
>
> --
> Sebastia
On Thu, Oct 10, 2013 at 5:24 PM, Andrew Ardill wrote:
> On 11 October 2013 08:43, Felipe Contreras wrote:
>> After gathering all the relevant
>> people, it groups them to show what exactly was their role when the
>> participated in the development of the relevant commit, and on how
>> many releva
On case-insensitive filesystems, git-merge deletes files that were
recapitalized in another branch if rename detection fails.
To repro: Run this script with git 1.8.4 on a case-insensitive filesystem. It
repros for me on the default HFS filesystem on OS X 10.8, and also on Win7 NTFS.
#!/bin/sh
On 11 October 2013 08:43, Felipe Contreras wrote:
> After gathering all the relevant
> people, it groups them to show what exactly was their role when the
> participated in the development of the relevant commit, and on how
> many relevant commits they participated.
It looks like you group by ema
On Thu, Oct 10, 2013 at 4:43 PM, Felipe Contreras
wrote:
> Just put git-related in your PATH, and enjoy :)
And of course I forgot the link:
https://github.com/felipec/git-related
--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
Hi,
This is basically the same as my original series[1] which was dropped
for no good reasons, plus all the other features I also sent patches
for.
This is way superior to the current git-contacts that sits on the contrib area.
For the uninitiated, this tool finds people that might be interested
On 10/10/2013 06:41 PM, Jeff King wrote:
> On Fri, Oct 04, 2013 at 04:09:12PM +0200, Stefan Beller wrote:
>
>> Commit 182d7dc46b (2013-09-05, cherry-pick: allow "-" as abbreviation of
>> '@{-1}') accesses the first argument without checking whether it exists.
>
> I think this is an obviously corr
mingw_path was introduced in abd4284 to output a mangled path as it is
passed as an argument to main(). But the name is misleading because
mangling does not come from MinGW, but from MSYS [1]. As abd4284 does not
introduce any MSYS or MinGW specific code but just prints out argv[2] as
it is passed
On Thu, Oct 10, 2013 at 10:04 PM, Johannes Sixt wrote:
>> PS: I'm also quite unhappy about naming the function "mingw_path". The
>> path mangling comes from MSYS, not MinGW, so if at all it should be
>> named msys_path. But as the code for the "mingw_path" function does
>> nothing either MSYS or
On 20.09.2013 04:38, Jiang Xin wrote:
Tvangeste found that the "relative_path" function could not work
properly on Windows if "in" and "prefix" have DOS driver prefix
(such as "C:/windows"). ($gmane/234434)
s/driver/drive/
E.g., When execute: test-path-utils relative_path "C:/a/b" "D:/x/y",
On 20.09.2013 04:38, Jiang Xin wrote:
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 DOS drive on MINGW platform. Use an umambigous leading path
"/foo" instead.
>
> Also change two leading slashes (//) to t
On Thu, Oct 10, 2013 at 10:04 PM, Johannes Sixt wrote:
>> So the obvious thing would be to replace /a/b/ with
>> /foo/bar/ in the tests, but that just masks the problem, or?
>
> The strange behavior is not a problem in Git, it is a problem of MSYS.
> Using /foo/bar instead of /a/b in Git's test s
Please keep in mind to CC the msysgit mailing list for Windows-specific
stuff. I'm also CC'ing Karsten who has worked on performance
improvements for Git for Windows in the past.
Thanks for bringing this up!
--
Sebastian Schuberth
Hi folks,
I don't follow the mailing list carefully, so for
Am 10.10.2013 21:47, schrieb Sebastian Schuberth:
> So the obvious thing would be to replace /a/b/ with
> /foo/bar/ in the tests, but that just masks the problem, or?
The strange behavior is not a problem in Git, it is a problem of MSYS.
Using /foo/bar instead of /a/b in Git's test suite is a reas
On Thu, Oct 10, 2013 at 7:57 PM, Johannes Sixt wrote:
>> test-path-utils I get this on Windows Server 2008 R2 64-bit:
>>
>> $ test-path-utils mingw_path /a/b/
>> a:/b/
>>
>> But if I install [1] on my local Windows 8 64-bit I get:
>>
>> $ test-path-utils mingw_path /a/b/
>> C:/msysgit/msysGit/a/b
I wrote a simple bash script that does git-archive recursively with
submodules. It first does a full mirror clone of the repo and
submodules, so that subsequent calls are faster.
https://github.com/ambakshi/git-archiver
Amit
On Thu, Oct 10, 2013 at 7:09 AM, Damien Regad wrote:
> Robert Quattl
Jeff King wrote:
> 3. The pain in doing the big rebase-test-deploy cycle meant that we
> often delayed it, keeping us several versions behind upstream.
> This is bad not only for the end product (you aren't getting other
> bugfixes from upstream as quickly), but also because the l
Hi folks,
I don't follow the mailing list carefully, so forgive me if this has
been discussed before, but:
I've noticed that when working with a very large repository using msys
git, the initial checkout of a cloned repository is excruciatingly
slow (80%+ of total clone time). The root cause, I
Am 10.10.2013 17:52, schrieb Sebastian Schuberth:
> Hi again,
>
> the problem can also be reproduced in an easier way, independently of
> mingwGitDevEnv and using the mingw_path function instead of
> relative_path. If I install msysGit 1.8.4 from [1] and run
> test-path-utils I get this on Windows
Stefan Beller wrote:
> On 10/09/2013 09:39 PM, Jonathan Nieder wrote:
>> Stefan Beller wrote:
>>> This test was put in, but commented out in fed1b5ca (2007-11-09,
>>> git-checkout: Test for relative path use.)
>>> It's been a while since 2007 and the intended test case works now.
>>> (I could not
On Thu, Oct 10, 2013 at 05:53:57PM +0100, Tony Finch wrote:
> Our aim is to get as many patches into the upstream version as we can,
> which is why my starting point is a clean rebased patch series. I am also
> thinking that this will help me to know when a patch can be dropped from
> the series b
Jeff King wrote:
>
> Do you need to keep the modifications you make on top of upstream as a
> nice, clean series of rebased patches? If not, then you can avoid the
> repeated rebasing, and just use a more traditional topic-branch
> workflow. Treat modifications from upstream as just another topic.
On Fri, Oct 04, 2013 at 04:09:12PM +0200, Stefan Beller wrote:
> Commit 182d7dc46b (2013-09-05, cherry-pick: allow "-" as abbreviation of
> '@{-1}') accesses the first argument without checking whether it exists.
I think this is an obviously correct fix for the immediate segfault,
but...
> diff
On Thu, Oct 10, 2013 at 09:59:38AM +0200, Karsten Blees wrote:
> > On Mon, Oct 07, 2013 at 07:24:11AM -0400, Jeff King wrote:
> >> However, one thing I expected to work but didn't is:
> >>
> >> echo '*' >.gitignore
> >> echo '!*' >my_dir/.gitignore
> >>
> >> That _does_ work for attributes,
Hi again,
the problem can also be reproduced in an easier way, independently of
mingwGitDevEnv and using the mingw_path function instead of
relative_path. If I install msysGit 1.8.4 from [1] and run
test-path-utils I get this on Windows Server 2008 R2 64-bit:
$ test-path-utils mingw_path /a/b/
a:
On 10/10/2013 15:58, SZEDER Gábor wrote:
> Hi,
>
> On Thu, Oct 10, 2013 at 03:32:13PM +0200, Julien Carsique wrote:
>> @@ -204,6 +206,9 @@ __git_ps1_show_upstream ()
>> *) # diverged from upstream
>> p=" u+${count#* }-${count% *}" ;;
>> e
From: Julien Carsique
When working with multiple remotes, it is common to switch the upstream
from a remote to another. Doing so, the prompt may not be the expected
one. Providing an option to display tracking information sounds useful.
Add a "name" option to GIT_PS1_SHOWUPSTREAM which will show
Robert Quattlebaum deepdarc.com> writes:
> I got too busy to continue working to get it included. Please feel free to
pick up where I left off.
>
> On Apr 20, 2012, at 2:32 PM, André Caron gmail.com> wrote:
> > Since you've touched this only last year, I'd like to know where you
> > were at and
Hello git maintainer crew,
recently I stumbled about gitweb generating improper HTML after
somebody merged from a branch contining an ampersand, e.g. branch
name=fixes&features.
Thanks, Alexander Kurz
>From beccd85ba8b8421213056883f31365f33d6e4490 Mon Sep 17 00:00:00 2001
From: kurz
Date: Th
Hi,
On Thu, Oct 10, 2013 at 03:32:13PM +0200, Julien Carsique wrote:
> @@ -204,6 +206,9 @@ __git_ps1_show_upstream ()
> *) # diverged from upstream
> p=" u+${count#* }-${count% *}" ;;
> esac
> + if [[ -n "$count" && -n "$n
From: Julien Carsique
When working with multiple remotes, it is common to switch the upstream
from a remote to another. Doing so, the prompt may not be the expected
one. Providing an option to display tracking information sounds useful.
Add a "name" option to GIT_PS1_SHOWUPSTREAM which will show
Hi,
for my mingwGitDevEnv project [1] I'm currently looking at the failing
Git tests [2]. The first tests that fails is t0060-path-utils [3]:
not ok 88 - relative path: / /a/b/ => ../../
# test "$(test-path-utils relative_path '/' '/a/b/')" = '../../'
not ok 91 - relative path: /x/y /a/b/ => ../
Stefan Saasen wrote:
>Thanks for the review David, much appreciated.
>
>> I think this line was already too long in its current form. Would
>you mind
>> splitting up this long line?
>
>I've updated the patch and had a look at how to avoid repeating the
>list of
>available merge/difftools.
>
>> ..
On Wed, Oct 9, 2013 at 6:35 PM, brian m. carlson
wrote:
> On Wed, Oct 09, 2013 at 05:37:42PM -0400, Jeff King wrote:
>> On Wed, Oct 09, 2013 at 02:19:36PM -0700, Shawn O. Pearce wrote:
>> > 206b099 was written because the Google web servers for
>> > android.googlesource.com and code.google.com do
On 10/09/2013 09:39 PM, Jonathan Nieder wrote:
> Stefan Beller wrote:
>
>> This test was put in, but commented out in fed1b5ca (2007-11-09,
>> git-checkout: Test for relative path use.)
>> It's been a while since 2007 and the intended test case works now.
>> (I could not find the enabling commit i
> On Mon, Oct 07, 2013 at 07:24:11AM -0400, Jeff King wrote:
>> However, one thing I expected to work but didn't is:
>>
>> echo '*' >.gitignore
>> echo '!*' >my_dir/.gitignore
>>
>> That _does_ work for attributes, like:
>>
>> echo '* foo=one' >.gitattributes
>> echo '* foo=two' >my_dir/
> On Mon, Oct 7, 2013 at 5:23 AM, AJ wrote:
>> I'm hoping to get the following feature implemented into git.
>>
>> Add the ability to recursively include using:
>> !/my_dir/**/*
>
>
> You can do that since v1.8.2. Actually the pattern should be
>
> !/my_dir/**
>
Another solution to include ju
Hi,
maybe some people will find this useful:
based on an old mail from Daniele Segato (to be found here:
http://git.661346.n2.nabble.com/cherry-pick-from-a-branch-to-another-with-git-svn-automatically-stripping-git-svn-id-from-commit-mese-tt4548700.html#none)
I made following .gitconfig entry:
[
Keshav Kini wrote:
> I'm not sure if this was the best way to split my changes into commits.
> Please let me know if it wasn't.
>
> Keshav Kini (4):
> git-svn.txt: fix AsciiDoc formatting error
> git-svn.txt: reword description of gc command
> git-svn.txt: replace .git with $GIT_DIR
> git
42 matches
Mail list logo
