Eric Wong normalper...@yhbt.net writes:
Perhaps we can depend on the URI.pm module? It seems to be
widely-available and not be a significant barrier to installation. On
the other hand, I don't know its history, either (especially since we're
now dealing with SVN changes...).
Anyways, I
On Monday 2012-07-30 16:58, Mojca Miklavec wrote:
COLUMNS=YourNumber git log YourArgs YourFile
Wow, perfect, thank you very much. Setting COLUMNS=200 (the high
number just in case) solved the problem.
200 ought to be enough for everybody? PATH_MAX is never enough...
--
To unsubscribe from
Junio C Hamano gits...@pobox.com writes:
Thomas Rast tr...@student.ethz.ch writes:
This patch fixes the first two by doing a more careful decoding of the
=AB outer quoting. Fixing the fundamental issues is left for a
future, more intrusive, patch.
What is this =AB thing?
The
On Monday 2012-07-30 18:08, Ralf Thielow wrote:
Translate 4 new messages came from git.pot update in 0bbe5b4
(l10n: Update git.pot (4 new, 3 removed messages)).
Signed-off-by: Ralf Thielow ralf.thie...@gmail.com
---
Hi German l10n team,
please review this small update on German
translation.
On Tue, Jul 31, 2012 at 10:13 AM, Jan Engelhardt jeng...@inai.de wrote:
On Monday 2012-07-30 18:08, Ralf Thielow wrote:
Translate 4 new messages came from git.pot update in 0bbe5b4
(l10n: Update git.pot (4 new, 3 removed messages)).
Signed-off-by: Ralf Thielow ralf.thie...@gmail.com
---
Hi
vishwajeet singh venit, vidit, dixit 31.07.2012 05:19:
On Tue, Jul 31, 2012 at 8:40 AM, Konstantin Khomoutov
kostix+...@007spb.ru wrote:
On Tue, Jul 31, 2012 at 08:36:07AM +0530, vishwajeet singh wrote:
Just wanted to know the difference between smart http and ssh and in
what scenarios we
Hi everyone,
I have some questions about rename detection.
The way I understand it, renames are not tracked in any way by GIT, at
least not in the repository. Instead some detection algorithm is
executed when data is extracted from the repository, prior to being
presented to the user (i.e.,
On Tue, Jul 31, 2012 at 2:17 PM, Michael J Gruber
g...@drmicha.warpmail.net wrote:
vishwajeet singh venit, vidit, dixit 31.07.2012 05:19:
On Tue, Jul 31, 2012 at 8:40 AM, Konstantin Khomoutov
kostix+...@007spb.ru wrote:
On Tue, Jul 31, 2012 at 08:36:07AM +0530, vishwajeet singh wrote:
Just
Am 24.07.2012 14:17, schrieb Chris Webb:
There is a bug with git rebase -i --root when a fixup or squash line is
applied to the new root. We attempt to amend the commit onto which they
apply with git reset --soft HEAD^ followed by a normal commit. Unlike a
real commit --amend, this sequence will
vishwajeet singh venit, vidit, dixit 31.07.2012 11:04:
On Tue, Jul 31, 2012 at 2:17 PM, Michael J Gruber
g...@drmicha.warpmail.net wrote:
vishwajeet singh venit, vidit, dixit 31.07.2012 05:19:
On Tue, Jul 31, 2012 at 8:40 AM, Konstantin Khomoutov
kostix+...@007spb.ru wrote:
On Tue, Jul 31,
On Tue, Jul 31, 2012 at 2:50 PM, Michael J Gruber
g...@drmicha.warpmail.net wrote:
vishwajeet singh venit, vidit, dixit 31.07.2012 11:04:
On Tue, Jul 31, 2012 at 2:17 PM, Michael J Gruber
g...@drmicha.warpmail.net wrote:
vishwajeet singh venit, vidit, dixit 31.07.2012 05:19:
On Tue, Jul 31,
It just doesn't matter.
Why are we arguing over which solution will be 4% better two years from now,
or if my commits are formatted perfectly, when tremendous amounts of basic
work to be done improving git-svn? The code is undocumented, lacking unit
tests, difficult to understand and riddled
Johannes Sixt j...@kdbg.org writes:
Am 24.07.2012 14:17, schrieb Chris Webb:
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index bef7bc0..0d2056f 100644
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -493,25 +493,28 @@ do_next () {
On Tue, Jul 31, 2012 at 2:50 PM, Michael J Gruber
g...@drmicha.warpmail.net wrote:
vishwajeet singh venit, vidit, dixit 31.07.2012 11:04:
On Tue, Jul 31, 2012 at 2:17 PM, Michael J Gruber
g...@drmicha.warpmail.net wrote:
vishwajeet singh venit, vidit, dixit 31.07.2012 05:19:
On Tue, Jul 31,
Chris Webb ch...@arachsys.com writes:
If we have a conflict in the middle of a chain of fixup/squashes, as far as
I can see, we have a HEAD with all the previous successful fixups applied,
conflict markers for the current failed pick, and when the conflict has been
resolved, git rebase
On Tue, 31 Jul 2012 14:27:15 +0200, Konstantin Khomoutov
flatw...@users.sourceforge.net wrote:
On Tue, 31 Jul 2012 14:02:50 +0200
Manuela Hutter manue...@opera.com wrote:
we have some python scripts that are run from Visual Studio, and one
of them fails because of a wrong git return code
On Tue, Jul 31, 2012 at 5:33 PM, Javier Domingo javier...@gmail.com wrote:
I am currently planifying a 3D project, and I will be having large binary
files. If I add a distributed VCS, the amount of disk space required will
increase significantly.
You are going to transfer something that wont
Git's rename detection is good but still not perfect. There have been
a few times I wanted to correct git for better output but I
couldn't. This PoC WIP patch attempts to address that. It allows to
break/rearrange any file pairs. We can do something crazy like this:
attr.c = dir.c | 1786
On Tue, Jul 31, 2012 at 3:08 PM, Javier Domingo javier...@gmail.com wrote:
Network, in this case is cheaper. The thing is that If I commit
frecuently, will have plenty of GBs of history, that nearly for sure I
won't use. I just need to have other people's work to merge. But I
want to think in
Javier,
Are you sure you need git for those big binary files at all?
Branching makes sense only if merging makes sense, and I can hardly see
how you can merge three 700-megabyte video files.
--
Edward Hades Toroshchin
dr_lepper on irc.freenode.org
--
To unsubscribe from this list: send the
Nguyen Thai Ngoc Duy pclo...@gmail.com writes:
The above output is done with git diff --manual-rename=foo A B
and foo contains (probably not in the best format though)
-- 8 --
attr.c dir.c
dir.c attr.c
-- 8 --
...
Comments?
It is a good direction to go in, I would think, to give users a
Enables the -P flag for perl regexps by default. When both the
perlRegexp and extendedRegexp options are enabled, the last enabled
option wins.
---
Documentation/config.txt | 6 ++
Documentation/git-grep.txt | 6 ++
builtin/grep.c | 17 +++--
t/t7810-grep.sh
Hi! I'm interested in translation git-scm.com to Russian and can do that
if your site has any features for multilangual support.
You can answer to this mail.
Best regards,
Nick Brovko
smime.p7s
Description: Криптографическая подпись S/MIME
René Scharfe wrote:
Am 28.07.2012 20:46, schrieb Ramsay Jones:
Unfortunately, I was unable to reproduce the final failure in t7810-grep.sh.
I tried, among other things, to provoke a failure thus:
$ for i in $(seq 100); do
if ! ./t7810-grep.sh -i -v; then
break;
In practice, the majority of paths do not have any utf8 character
that needs the canonicalization. Lazily call iconv_open() and
iconv_close() to avoid unnecessary overhead.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
* This is not even compile tested, so it needs testing and
J Smith dark.pa...@gmail.com writes:
Enables the -P flag for perl regexps by default. When both the
perlRegexp and extendedRegexp options are enabled, the last enabled
option wins.
Turning grep.extendedregexp from boolean to an extended boolean to
allow grep.extendedregexp = perl might be a
Junio C Hamano gits...@pobox.com writes:
In practice, the majority of paths do not have any utf8 character
that needs the canonicalization. Lazily call iconv_open() and
iconv_close() to avoid unnecessary overhead.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
* This is not even
On Tue, Jul 31, 2012 at 7:52 PM, Junio C Hamano gits...@pobox.com wrote:
+ /* Avoid iconv_open()/iconv_close() if there is nothing to convert */
+ for (i = 0; i argc; i++) {
+ if (has_utf8(argv[i], (size_t)-1, NULL))
+ break;
+ }
+
Ralf Thielow ralf.thie...@gmail.com writes:
On Tue, Jul 31, 2012 at 7:52 PM, Junio C Hamano gits...@pobox.com wrote:
+ /* Avoid iconv_open()/iconv_close() if there is nothing to convert */
+ for (i = 0; i argc; i++) {
+ if (has_utf8(argv[i], (size_t)-1, NULL))
+
Hey guys,
I'm trying to set up a post-receive hook that redirects code based on
the content of the actual push. Specifically, I'm trying to set up
automatic deployment of web apps with the option of sending the code
to a build farm first. For example, if you push your code to a git
repo, there
In practice, the majority of paths do not have utf8 that needs
the canonicalization. Lazily call iconv_open()/iconv_close() to
avoid unnecessary overhead.
Signed-off-by: Junio C Hamano gits...@pobox.com
Helped-by: Ralf Thielow ralf.thie...@gmail.com
Helped-by: Linus Torvalds
On Tue, Jul 31, 2012 at 8:37 PM, Junio C Hamano gits...@pobox.com wrote:
+ /* Avoid iconv_open()/iconv_close() if there is nothing to convert */
+ for (i = 0; i argc; i++) {
+ if (has_utf8(argv[i], (size_t)-1, NULL))
+ break;
+ }
+
Ralf Thielow ralf.thie...@gmail.com writes:
On Tue, Jul 31, 2012 at 8:37 PM, Junio C Hamano gits...@pobox.com wrote:
+ /* Avoid iconv_open()/iconv_close() if there is nothing to convert */
+ for (i = 0; i argc; i++) {
+ if (has_utf8(argv[i], (size_t)-1, NULL))
+
Jessica Lucci jessicalucc...@gmail.com writes:
Hey guys,
I'm trying to set up a post-receive hook that redirects code based on
the content of the actual push. Specifically, I'm trying to set up
automatic deployment of web apps with the option of sending the code
to a build farm first. For
On Tue, Jul 31, 2012 at 09:32:49AM -0700, Junio C Hamano wrote:
Nguyen Thai Ngoc Duy pclo...@gmail.com writes:
The above output is done with git diff --manual-rename=foo A B
and foo contains (probably not in the best format though)
-- 8 --
attr.c dir.c
dir.c attr.c
-- 8 --
...
On Monday 30 July 2012 09:28:27 Junio C Hamano wrote:
Florian Achleitner florian.achleitner.2.6...@gmail.com writes:
Enables basic fetching from subversion repositories. When processing
Remote URLs starting with svn::, git invokes this remote-helper.
It starts svnrdump to extract revisions
Dear list,
Project : Use JavaScript library / framework in
gitweb
Project Description :
https://github.com/peff/git/wiki/SoC-2012-Ideas
Code:
https://github.com/jaseemabid/git/commits/gitweb
The
On Monday 30 July 2012 11:55:02 Jonathan Nieder wrote:
Florian Achleitner wrote:
Hm .. that would mean, that both fast-import and git (transport-helper)
would write to the remote-helper's stdin, right?
Yes, first git writes the list of refs to import, and then fast-import
writes feedback
When you have a non-directory on your PATH, a funny thing happens:
$ PATH=$PATH:/bin/sh git foo
fatal: cannot exec 'git-foo': Not a directory?
Worse yet, as real commands always take precedence over aliases,
this behaviour interacts rather badly with them:
$
On Tue, Jul 31, 2012 at 11:37 AM, Junio C Hamano gits...@pobox.com wrote:
* This is not even compile tested, so it needs testing and
benchmarking, as I do not even know how costly the calls to
open/close are when we do not have to call iconv() itself.
Ok, so it's easily compile-tested:
Am 31.07.2012 14:48, schrieb Chris Webb:
Chris Webbch...@arachsys.com writes:
If we have a conflict in the middle of a chain of fixup/squashes, as far as
I can see, we have a HEAD with all the previous successful fixups applied,
conflict markers for the current failed pick, and when the
Linus Torvalds torva...@linux-foundation.org writes:
On Tue, Jul 31, 2012 at 11:37 AM, Junio C Hamano gits...@pobox.com wrote:
* This is not even compile tested, so it needs testing and
benchmarking, as I do not even know how costly the calls to
open/close are when we do not have to
Jeff King p...@peff.net writes:
A much better hint is to annotate pairs of sha1s, to say do not bother
doing inexact rename correlation on this pair; I promise that they have
value N.
Surely. And I suspect that the patch to the current codebase to do
so would be much less impact if you go
On Tue, Jul 31, 2012 at 2:04 PM, Junio C Hamano gits...@pobox.com wrote:
Turning grep.extendedregexp from boolean to an extended boolean to
allow grep.extendedregexp = perl might be a better alternative.
That way, the user wouldn't have to worry about 7 variants of
grep.fooRegexp variables
On Tue, Jul 31, 2012 at 12:46:13PM -0700, Junio C Hamano wrote:
When you have a non-directory on your PATH, a funny thing happens:
$ PATH=$PATH:/bin/sh git foo
fatal: cannot exec 'git-foo': Not a directory?
Worse yet, as real commands always take precedence over aliases,
this
J Smith dark.pa...@gmail.com writes:
... For the sake of completeness (verbosity? pedantry?) I also
included a setting for extended which is equivalent to true.
Good thinking.
With this sort of change, would a more generic grep.regexpMode,
grep.patternType or something similar perhaps be
On Tue, Jul 31, 2012 at 4:30 PM, Junio C Hamano gits...@pobox.com wrote:
J Smith dark.pa...@gmail.com writes:
... For the sake of completeness (verbosity? pedantry?) I also
included a setting for extended which is equivalent to true.
Good thinking.
With this sort of change, would a more
On Tue, Jul 31, 2012 at 1:16 PM, Junio C Hamano gits...@pobox.com wrote:
Eek.
Oh, I agree. Doing a full character set conversion both ways is quite
a bit more work.
Not just write_entry() codepath that creates the final paths on the
filesystem, you would need to touch lstat() calls that
J Smith dark.pa...@gmail.com writes:
On Tue, Jul 31, 2012 at 4:30 PM, Junio C Hamano gits...@pobox.com wrote:
J Smith dark.pa...@gmail.com writes:
... For the sake of completeness (verbosity? pedantry?) I also
included a setting for extended which is equivalent to true.
Good thinking.
Florian Achleitner wrote:
I haven't tried that yet, nor do I remember anything where I've already seen
two processes writing to the same pipe.
It's a perfectly normal and well supported thing to do.
[...]
Will try that in test-program..
Thanks.
Good luck,
Jonathan
--
To unsubscribe from
Johannes Sixt j...@kdbg.org writes:
One subtlety to watch out for is when commit messages are edited. That is,
if you edit the proposed message at 'rebase --continue' after the first
squash failed, is the new text preserved until the last squash? I *think*
that previously that was the case.
Adds basic, extended, fixed, and perl settings to the
grep.extendedRegexp configuration option which set --basic-regexp,
--extended-regexp, --fixed-strings, and --perl-regexp options by
default respectively. For the purposes of backwards compatibility,
extended is equivalent to true.
---
With the addition of the basic, extended, fixed, and perl
values for the grep.extendedRegexp option the name grep.patternType
better represents the option's functionality. grep.extendedRegexp
remains available as an alias to grep.patternType for the purposes of
backwards compatibility.
---
On Tue, Jul 31, 2012 at 5:05 PM, Junio C Hamano gits...@pobox.com wrote:
Ok, then grep.patternType it is.
Thanks.
Cool, patches should be on their way. I added options for basic,
extended, fixed and perl for completeness along with the name
change with a BC alias patch separately for perusal.
Eric Wong normalper...@yhbt.net writes:
Michael G Schwern schw...@pobox.com wrote:
It just doesn't matter.
Why are we arguing over which solution will be 4% better two years from now,
or if my commits are formatted perfectly, when tremendous amounts of basic
work to be done improving
J Smith dark.pa...@gmail.com writes:
With the addition of the basic, extended, fixed, and perl
values for the grep.extendedRegexp option the name grep.patternType
better represents the option's functionality. grep.extendedRegexp
remains available as an alias to grep.patternType for the
On 2012.7.31 1:01 PM, Eric Wong wrote:
Michael G Schwern schw...@pobox.com wrote:
It just doesn't matter.
Why are we arguing over which solution will be 4% better two years from now,
or if my commits are formatted perfectly, when tremendous amounts of basic
work to be done improving git-svn?
On 2012.7.31 4:05 PM, Junio C Hamano wrote:
What I won't accept is maintainability does not matter. It does.
I'm sorry, that's not what I intended to convey at all. My reply to Eric lays
it out more clearly, I think.
--
Reality is that which, when you stop believing in it, doesn't go away.
Hi,
On a freshly checked out copy of the maint branch (0e4c8822), the
t9100-git-svn-basic.sh tests are failing 21 of 25 tests. Is this
known, or am I missing some dependencies? Is it possibly due to
using subversion 1.7?
I've run into a small bug with git-svn, and wanted to make sure
the test
On Tue, Jul 31, 2012 at 01:20:42PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
A much better hint is to annotate pairs of sha1s, to say do not bother
doing inexact rename correlation on this pair; I promise that they have
value N.
Surely. And I suspect that the patch
On Wed, Aug 1, 2012 at 2:23 AM, Jeff King p...@peff.net wrote:
It is a good direction to go in, I would think, to give users a way
to explicitly tell that in comparison between these two trees, I
know path B in the postimage corresponds to path A in the preimage.
I do not think that is the
On Wed, Aug 1, 2012 at 9:01 AM, Jeff King p...@peff.net wrote:
On Wed, Aug 01, 2012 at 08:10:12AM +0700, Nguyen Thai Ngoc Duy wrote:
I do not think that is the right direction. Let's imagine that I have a
commit A and I annotate it (via notes or whatever) to say between
A^^{tree} and
62 matches
Mail list logo
