On Wed, Aug 1, 2012 at 1:44 AM, Ammon Riley wrote:
> 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?
Yes, and work
On Wed, Aug 1, 2012 at 1:09 PM, Junio C Hamano wrote:
> Nguyen Thai Ngoc Duy writes:
>
>> Yes. This is probably cosmetics only, but without path information, we
>> leave it to chance to decide which A to pair with B and C (in the
>> A->B, A->C case above). Wrong path might lead to funny effects (
Nguyen Thai Ngoc Duy writes:
> Yes. This is probably cosmetics only, but without path information, we
> leave it to chance to decide which A to pair with B and C (in the
> A->B, A->C case above). Wrong path might lead to funny effects (i'm
> thinking of git log --follow).
Isn't that why and ca
Jeff King writes:
> @@ -175,6 +177,11 @@ static int estimate_similarity(struct diff_filespec *src,
> if (max_size * (MAX_SCORE-minimum_score) < delta_size * MAX_SCORE)
> return 0;
>
> + hashcpy(pair.one, src->sha1);
> + hashcpy(pair.two, dst->sha1);
> + if (renam
On Wed, Aug 1, 2012 at 9:01 AM, Jeff King 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 A^{tr
On 2012-07-31, at 7:22 PM, Junio C Hamano wrote:
> J Smith 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
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 A^{tree}, foo.c became bar.c". That will help me when
> > doi
On Wed, Aug 1, 2012 at 2:23 AM, Jeff King 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 right
On Tue, Jul 31, 2012 at 01:20:42PM -0700, Junio C Hamano wrote:
> Jeff King 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 t
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 sui
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
On 2012.7.31 1:01 PM, Eric Wong wrote:
> Michael G Schwern 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? The c
J Smith 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 purpose
Eric Wong writes:
> Michael G Schwern 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? The code is undocumente
On Tue, Jul 31, 2012 at 5:05 PM, Junio C Hamano 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.
Chee
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 compatibili
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 "t
Johannes Sixt 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.
Hi. Yes, d
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
J Smith writes:
> On Tue, Jul 31, 2012 at 4:30 PM, Junio C Hamano wrote:
>> J Smith 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 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 check the
> existe
On Tue, Jul 31, 2012 at 4:30 PM, Junio C Hamano wrote:
> J Smith 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",
J Smith 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 more descript
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,
On Tue, Jul 31, 2012 at 2:04 PM, Junio C Hamano 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 twenty year
Jeff King 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 that way.
Linus Torvalds writes:
> On Tue, Jul 31, 2012 at 11:37 AM, Junio C Hamano 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 ea
Am 31.07.2012 14:48, schrieb Chris Webb:
Chris Webb 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
resolv
Michael G Schwern 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? The code is undocumented, lacking unit
> tests, di
On Tue, Jul 31, 2012 at 11:37 AM, Junio C Hamano 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: just add
+
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:
$ PATH=$PATH:/b
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 fe
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 pro
On Monday 30 July 2012 09:28:27 Junio C Hamano wrote:
> Florian Achleitner 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 from the subversion repositor
On Tue, Jul 31, 2012 at 09:32:49AM -0700, Junio C Hamano wrote:
> Nguyen Thai Ngoc Duy 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< --
>
Jessica Lucci 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 example, if you push
Ralf Thielow writes:
> On Tue, Jul 31, 2012 at 8:37 PM, Junio C Hamano 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;
>>
On Tue, Jul 31, 2012 at 8:37 PM, Junio C Hamano 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;
> + }
> + if (argc <
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
Helped-by: Ralf Thielow
Helped-by: Linus Torvalds
---
* This is not even compile tested, so it needs testing
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 sho
Ralf Thielow writes:
> On Tue, Jul 31, 2012 at 7:52 PM, Junio C Hamano 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;
>>
On Tue, Jul 31, 2012 at 7:52 PM, Junio C Hamano 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;
> + }
> + if (i < ar
Junio C Hamano 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
> ---
>
> * This is not even compile tested, so it needs t
J Smith 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 better alternat
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
---
* This is not even compile tested, so it needs testing and
benchmarking, as I do not
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
>> > b
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
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
Nguyen Thai Ngoc Duy 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 wa
On Tue, Jul 31, 2012 at 8:22 PM, Ævar Arnfjörð Bjarmason
wrote:
> On Tue, Jul 31, 2012 at 3:08 PM, Javier Domingo 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 o
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 li
On Tue, Jul 31, 2012 at 3:08 PM, Javier Domingo 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 Git style, I am
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 5:33 PM, Javier Domingo 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 fit into your h
On Tue, 31 Jul 2012 14:27:15 +0200, Konstantin Khomoutov
wrote:
On Tue, 31 Jul 2012 14:02:50 +0200
"Manuela Hutter" wrote:
we have some python scripts that are run from Visual Studio, and one
of them fails because of a wrong git return code when calling
'git describe --dirty'
[...]
Run f
Chris Webb 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 --continue will commi
On Tue, 31 Jul 2012 14:02:50 +0200
"Manuela Hutter" wrote:
> we have some python scripts that are run from Visual Studio, and one
> of them fails because of a wrong git return code when calling
> 'git describe --dirty'
[...]
> Run from wingw, the return code is 0.
> Run from cmd, the return code
Hi,
we have some python scripts that are run from Visual Studio, and one of
them fails because of a wrong git return code when calling 'git describe
--dirty'
Here's the issue:
=
import subprocess
GIT_EXE = ""
GIT_SRC = ""
# call 'git describe --dirty':
run_git = subprocess.P
On Tue, Jul 31, 2012 at 2:50 PM, Michael J Gruber
wrote:
> vishwajeet singh venit, vidit, dixit 31.07.2012 11:04:
>> On Tue, Jul 31, 2012 at 2:17 PM, Michael J Gruber
>> wrote:
>>> vishwajeet singh venit, vidit, dixit 31.07.2012 05:19:
On Tue, Jul 31, 2012 at 8:40 AM, Konstantin Khomoutov
>>
Hi all,
I've encountered what I think is a bug in the subtree split command
included in contrib.
According to the docs:
"Repeated splits of exactly the same history are
guaranteed to be identical (ie. to produce the same
commit ids). Because of this, if you add new commits
and then re-split,
Johannes Sixt 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 () {
> > a
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 with
On Tue, Jul 31, 2012 at 2:50 PM, Michael J Gruber
wrote:
> vishwajeet singh venit, vidit, dixit 31.07.2012 11:04:
>> On Tue, Jul 31, 2012 at 2:17 PM, Michael J Gruber
>> wrote:
>>> vishwajeet singh venit, vidit, dixit 31.07.2012 05:19:
On Tue, Jul 31, 2012 at 8:40 AM, Konstantin Khomoutov
>>
vishwajeet singh venit, vidit, dixit 31.07.2012 11:04:
> On Tue, Jul 31, 2012 at 2:17 PM, Michael J Gruber
> wrote:
>> vishwajeet singh venit, vidit, dixit 31.07.2012 05:19:
>>> On Tue, Jul 31, 2012 at 8:40 AM, Konstantin Khomoutov
>>> wrote:
On Tue, Jul 31, 2012 at 08:36:07AM +0530, vishwaj
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
On Tue, Jul 31, 2012 at 2:17 PM, Michael J Gruber
wrote:
> vishwajeet singh venit, vidit, dixit 31.07.2012 05:19:
>> On Tue, Jul 31, 2012 at 8:40 AM, Konstantin Khomoutov
>> wrote:
>>> On Tue, Jul 31, 2012 at 08:36:07AM +0530, vishwajeet singh wrote:
>>>
Just wanted to know the difference be
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., gi
vishwajeet singh venit, vidit, dixit 31.07.2012 05:19:
> On Tue, Jul 31, 2012 at 8:40 AM, Konstantin Khomoutov
> 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 need them
>
On Tue, Jul 31, 2012 at 10:13 AM, Jan Engelhardt 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
>>---
>>Hi German l10n team,
>>
>>ple
Matthieu Moy venit, vidit, dixit 31.07.2012 08:38:
> Jialin Liu writes:
>
>> In http://git-scm.com/book/en/Git-Basics-Recording-Changes-to-the-Repository
>>
>> Notice how you don’t have to run git add on the benchmarks.rb file in this
>> case before you commit.
>
> In which case? (the page is r
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
>---
>Hi German l10n team,
>
>please review this small update on German
>translation.
Patch is fine f
Junio C Hamano writes:
> Thomas Rast 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 two-hex-digits quoting in the style of MI
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 f
73 matches
Mail list logo
