Jonathan Nieder jrnie...@gmail.com wrote:
Nicolas Vigier wrote:
When parsing a commit object, git-svn wrongly think that a line
containing spaces means the end of headers and the start of the commit
message. In case of signed commit, the gpgsig entry contains a line with
one space, so
Keshav Kini keshav.k...@gmail.com 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
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:
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/.gitattributes
On Mon, Oct 7, 2013 at 5:23 AM, AJ allj...@gmail.com 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
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 in
On Wed, Oct 9, 2013 at 6:35 PM, brian m. carlson
sand...@crustytoothpaste.net 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
Stefan Saasen ssaa...@atlassian.com 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
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/ =
From: Julien Carsique julien.carsi...@gmail.com
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
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 $name ]];
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=fixesfeatures.
Thanks, Alexander Kurz
From beccd85ba8b8421213056883f31365f33d6e4490 Mon Sep 17 00:00:00 2001
From: kurz
Robert Quattlebaum darco at 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 andre.l.caron at gmail.com wrote:
Since you've touched this only last year, I'd like to know where
From: Julien Carsique julien.carsi...@gmail.com
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
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% *} ;;
esac
+
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/
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, like:
echo '*
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
Jeff King p...@peff.net 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
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
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 find the
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
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
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
On Thu, Oct 10, 2013 at 7:57 PM, Johannes Sixt j...@kdbg.org 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/
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
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
On Thu, Oct 10, 2013 at 10:04 PM, Johannes Sixt j...@kdbg.org 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
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 three
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,
should
On Thu, Oct 10, 2013 at 10:04 PM, Johannes Sixt j...@kdbg.org 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
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 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 correct fix
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
On Thu, Oct 10, 2013 at 4:43 PM, Felipe Contreras
felipe.contre...@gmail.com 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
On 11 October 2013 08:43, Felipe Contreras felipe.contre...@gmail.com 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
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 Thu, Oct 10, 2013 at 5:24 PM, Andrew Ardill andrew.ard...@gmail.com wrote:
On 11 October 2013 08:43, Felipe Contreras felipe.contre...@gmail.com 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
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!
--
Sebastian
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
On Thu, Oct 10, 2013 at 5:51 PM, Karsten Blees karsten.bl...@gmail.comwrote:
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
On Fri, Oct 11, 2013 at 12:35 PM, Stefan Zager sza...@google.com wrote:
For my test, I first run 'git clone -n repo', 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
42 matches
Mail list logo
