* Re: [PATCH v2] Fix git-tag test breakage caused by broken sed on Leopard
From: Mike Hommey @ 2007-11-16 16:59 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Junio C Hamano, Johannes Schindelin, Git Mailing List
In-Reply-To: <03D3DFCD-B5F7-47CF-AFD2-F1408BB11AB3@wincent.com>
On Fri, Nov 16, 2007 at 02:48:09PM +0100, Wincent Colaiuta wrote:
> El 16/11/2007, a las 14:45, Wincent Colaiuta escribió:
>
> > El 16/11/2007, a las 6:14, Junio C Hamano escribió:
> >
> >> Wincent Colaiuta <win@wincent.com> writes:
> >>
> >>> diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
> >>> index 096fe33..b54c2e0 100755
> >>> --- a/t/t7004-tag.sh
> >>> +++ b/t/t7004-tag.sh
> >>> @@ -1007,7 +1007,7 @@ test_expect_failure \
> >>> test_expect_success \
> >>> 'message in editor has initial comment' '
> >>> GIT_EDITOR=cat git tag -a initial-comment > actual || true &&
> >>> - test $(sed -n "/^\(#\|\$\)/p" actual | wc -l) -gt 0
> >>> + test $(grep -e "^#" -e "^\$" actual | wc -l ) -gt 0
> >>> '
> >>
> >> Heh, doesn't grep exit with zero only when it found some lines
> >> that match the pattern already? What's that "wc -l" for?
> >
> >
> > I was just trying to make the minimal change (swapping grep for
> > sed), but if you want a shorter version then we don't even need the
> > "test"; it could just be:
> >
> > - test $(sed -n "/^\(#\|\$\)/p" actual | wc -l) -gt 0
> > + grep -e "^#" -e "^\$" actual
>
> Although I don't know if we should be testing for empty lines there
> because an 0-byte empty "actual" file would spuriously pass the test.
> Perhaps this would be better:
>
> - test $(sed -n "/^\(#\|\$\)/p" actual | wc -l) -gt 0
> + grep -e "^#" actual
Matching both would as in your previous pseudo patch wouldn't catch
empty file. On the other hand, both my initial bloated version and yours
won't catch a file that doesn't contain the comment.
grep -e "^$" actual && grep -e "^#" actual would actually be a better
test.
Mike
^ permalink raw reply
* Re: Git User's Survey comparison at GitWiki
From: Jakub Narebski @ 2007-11-16 16:39 UTC (permalink / raw)
To: git
In-Reply-To: <200711160302.59786.jnareb@gmail.com>
I'd like to announce that comparison of Git User's Survey 2006
and Git User's Survey 2007 is now present on Git Wiki at
http://git.or.cz/gitwiki/GitSurvey2006vs2007
So you can now see what changed during this year (this was one
of the reason for repeating the survey this year).
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Fix per-directory exclude handing for "git add"
From: Bruce Stephens @ 2007-11-16 15:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <80y7cy2tay.fsf@tiny.isode.net>
Bruce Stephens <bruce.stephens@isode.com> writes:
[...]
> I guess really the output of "git status" (or "git runstatus") is
> more significant since that's what we'd normally be running (that's
> presumably what "git gui" and similar tools run, though perhaps they
> use "git ls-files"---probably the underlying code's the same, I
> guess).
Bah. "git status" also works correctly, I think. I was just testing
stupidly.
[...]
^ permalink raw reply
* Re: git-cvsimport bug with dates
From: Elijah Newren @ 2007-11-16 14:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr6iq207f.fsf@gitster.siamese.dyndns.org>
On Nov 15, 2007 11:06 PM, Junio C Hamano <gitster@pobox.com> wrote:
> When you use "branch@{date}" notation, you are not asking a
> question on the project history, but a question on the local
> view from _your_ repository on that project.
Interesting; that makes sense from a merge or pull viewpoint, but
wouldn't it make more sense to have cvsimport ensure the commits are
treated as though they actually existed in master as of the date
specified in CVS?
Elijah
^ permalink raw reply
* Re: Fix per-directory exclude handing for "git add"
From: Bruce Stephens @ 2007-11-16 13:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vodduzh36.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
[...]
> While read_directory_recursive() runs, calls to excluded() makes use
> the data in the exclusion elements, including this base string. The
> caller of read_directory_recursive() is not supposed to free the
> buffer it gave to push_exclude_per_directory() earlier, until it
> returns.
Cool, that fixes the "git add" issue I was seeing. (So Acked-by:
Bruce Stephens <bruce.stephens@isode.com>, for what it's worth.)
I guess really the output of "git status" (or "git runstatus") is more
significant since that's what we'd normally be running (that's
presumably what "git gui" and similar tools run, though perhaps they
use "git ls-files"---probably the underlying code's the same, I
guess).
However, that doesn't mean the issue with git add shouldn't be
resolved.
[...]
^ permalink raw reply
* Re: [PATCH v2] Fix git-tag test breakage caused by broken sed on Leopard
From: Wincent Colaiuta @ 2007-11-16 13:48 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Junio C Hamano, Johannes Schindelin, Git Mailing List
In-Reply-To: <7A6820DE-C6EE-4E3E-A97F-97766F682B85@wincent.com>
El 16/11/2007, a las 14:45, Wincent Colaiuta escribió:
> El 16/11/2007, a las 6:14, Junio C Hamano escribió:
>
>> Wincent Colaiuta <win@wincent.com> writes:
>>
>>> diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
>>> index 096fe33..b54c2e0 100755
>>> --- a/t/t7004-tag.sh
>>> +++ b/t/t7004-tag.sh
>>> @@ -1007,7 +1007,7 @@ test_expect_failure \
>>> test_expect_success \
>>> 'message in editor has initial comment' '
>>> GIT_EDITOR=cat git tag -a initial-comment > actual || true &&
>>> - test $(sed -n "/^\(#\|\$\)/p" actual | wc -l) -gt 0
>>> + test $(grep -e "^#" -e "^\$" actual | wc -l ) -gt 0
>>> '
>>
>> Heh, doesn't grep exit with zero only when it found some lines
>> that match the pattern already? What's that "wc -l" for?
>
>
> I was just trying to make the minimal change (swapping grep for
> sed), but if you want a shorter version then we don't even need the
> "test"; it could just be:
>
> - test $(sed -n "/^\(#\|\$\)/p" actual | wc -l) -gt 0
> + grep -e "^#" -e "^\$" actual
Although I don't know if we should be testing for empty lines there
because an 0-byte empty "actual" file would spuriously pass the test.
Perhaps this would be better:
- test $(sed -n "/^\(#\|\$\)/p" actual | wc -l) -gt 0
+ grep -e "^#" actual
Cheers,
Wincent
^ permalink raw reply
* Re: [PATCH v2] Fix git-tag test breakage caused by broken sed on Leopard
From: Wincent Colaiuta @ 2007-11-16 13:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <7v4pfm3h6f.fsf@gitster.siamese.dyndns.org>
El 16/11/2007, a las 6:14, Junio C Hamano escribió:
> Wincent Colaiuta <win@wincent.com> writes:
>
>> diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
>> index 096fe33..b54c2e0 100755
>> --- a/t/t7004-tag.sh
>> +++ b/t/t7004-tag.sh
>> @@ -1007,7 +1007,7 @@ test_expect_failure \
>> test_expect_success \
>> 'message in editor has initial comment' '
>> GIT_EDITOR=cat git tag -a initial-comment > actual || true &&
>> - test $(sed -n "/^\(#\|\$\)/p" actual | wc -l) -gt 0
>> + test $(grep -e "^#" -e "^\$" actual | wc -l ) -gt 0
>> '
>
> Heh, doesn't grep exit with zero only when it found some lines
> that match the pattern already? What's that "wc -l" for?
I was just trying to make the minimal change (swapping grep for sed),
but if you want a shorter version then we don't even need the "test";
it could just be:
- test $(sed -n "/^\(#\|\$\)/p" actual | wc -l) -gt 0
+ grep -e "^#" -e "^\$" actual
Cheers,
Wincent
^ permalink raw reply
* [PATCH] Fix t9101 test failure caused by Subversion "auto-props"
From: Wincent Colaiuta @ 2007-11-16 13:25 UTC (permalink / raw)
To: Björn Steinbrink
Cc: Benoit Sigoure, Git Mailing List,
Väinö Järvelä, Junio Hamano
In-Reply-To: <20071116124850.GA14473@atjola.homenet>
If a user has an "auto-prop" in his/her ~/.subversion/config file for
automatically setting the svn:keyword Id property on all ".c" files
(a reasonably common configuration in the Subversion world) then one
of the "svn propset" operations in the very first test would become a
no-op, which in turn would make the next commit a no-op.
This then caused the 25th test ('test propget') to fail because it
expects a certain number of commits to have taken place but the actual
number of commits was off by one.
Björn Steinbrink identified the "auto-prop" feature as the cause
of the failure. This patch avoids it by passing the "--no-auto-prop"
flag to "svn import" when setting up the test repository, thus ensuring
that the "svn propset" operation is no longer a no-op, regardless of the
users' settings in their config.
Signed-off-by: Wincent Colaiuta <win@wincent.com>
---
t/t9101-git-svn-props.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t9101-git-svn-props.sh b/t/t9101-git-svn-props.sh
index 3c83127..d7a7047 100755
--- a/t/t9101-git-svn-props.sh
+++ b/t/t9101-git-svn-props.sh
@@ -48,7 +48,7 @@ EOF
printf "\r\n" > empty_crlf
a_empty_crlf=`git-hash-object -w empty_crlf`
- svn import -m 'import for git-svn' . "$svnrepo" >/dev/null
+ svn import --no-auto-props -m 'import for git-svn' .
"$svnrepo" >/dev/null
cd ..
rm -rf import
--
1.5.3.5
^ permalink raw reply related
* Re: [PATCH] t9101 (master) busted on Leopard
From: Wincent Colaiuta @ 2007-11-16 13:14 UTC (permalink / raw)
To: Björn Steinbrink
Cc: Benoit Sigoure, Git Mailing List,
Väinö Järvelä
In-Reply-To: <20071116124850.GA14473@atjola.homenet>
El 16/11/2007, a las 13:48, Björn Steinbrink escribió:
> On 2007.11.16 12:00:02 +0100, Wincent Colaiuta wrote:
>> That last commit is a no-op because, for some reason, the svn propset
>> before it is also a no-op:
>>
>> svn propset svn:keywords Id kw.c
>
> It _is_ a no-op. At least here. Because I got an auto-props setting in
> my ~/.subversion/config to automatically add Id for *.c files. So that
> property was already there before we explicitly ask for it and the
> propset turns into a no-op. If I remove that line from the subversion
> configuration, the test succeeds. Same for you I guess.
>
> That said, I had a quick glance over the subversion CLI help, but it
> didn't tell me how to ignore/override ~/.subversion/config. Anyone
> less
> clueless than me around, having a smart idea how to work around that
> "bug"?
Ah, excellent catch, Björn. That's it. The --no-auto-props switch will
fix this then; will post a patch to the list in a few minutes.
Cheers,
Wincent
^ permalink raw reply
* Re: [PATCH] Git.pm: Don't return 'undef' in vector context.
From: Sebastian Harl @ 2007-11-16 12:47 UTC (permalink / raw)
To: git
In-Reply-To: <7vfxz61yox.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1407 bytes --]
Hi,
On Thu, Nov 15, 2007 at 10:39:26PM -0800, Junio C Hamano wrote:
> Dan Zwell <dzwell@gmail.com> writes:
> > Previously, the Git->repository()->config('non-existent.key')
> > evaluated to as true in a vector context. Return an empty list
> > instead.
> > ---
> > I don't know whether this breaks anything, because I don't use most of
> > the git perl scripts. I can't imagine that there is a script that
> > relies on the fact that config('non-existent.key') actually returns
> > (''), in an array context. Is this a reasonable change?
>
> I did not examine the callers but my gut feeling is that it
> would be simpler and cleaner to always return () without
> checking the context.
[...]
> I generally try to stay away from functions that changes their
> return values depending on the context, because they tend to
> make reading the callers to find bugs more difficult.
In fact, if you simply return without any value, it will evaluate to "false"
no matter which context it has been called in ("()" in list context, "undef"
in scalar context, etc.). So, it's generally a good idea to use "return;" to
indicate an error.
Cheers,
Sebastian
--
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/
Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Fix "identifier redeclared" compilation error with SUN cc.
From: Björn Steinbrink @ 2007-11-16 12:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: raa.lkml, git, git
In-Reply-To: <7vd4ua3hww.fsf@gitster.siamese.dyndns.org>
On 2007.11.15 20:58:55 -0800, Junio C Hamano wrote:
> How about doing it this way?
>
> # ifndef FLEX_ARRAY
> # if defined(__GNUC__)
> # if (__GNUC__ < 3)
> # define FLEX_ARRAY 0
> # else
> # define FLEX_ARRAY /* empty */
> # endif
> # else
> /* more cases we know we can use 0 or empty can come here */
> # endif
> # endif
>
> /* if still undefined, default to the safe, old fashioned way */
> # ifndef FLEX_ARRAY
> # define FLEX_ARRAY 1
> # endif
Yeah, looks a bit smarter.
> The basic idea is:
>
> * The user (from Makefile command line, config.mak, or you
> could add autoconf test) can pass -DFLEX_ARRAY=... to specify
> exactly what should happen;
Eeeek! He said autoconf! Waaah! ... Ehrm, sorry where was I?
> * Otherwise, if we happen to know for sure that we can use "0"
> or "/* empty */" with the compiler, we define FLEX_ARRAY;
> currently we know such things for gcc.
>
> * For everybody else, we use safer default of "1". IOW, if you
> know your compiler does not grok "/* empty */" nor "0", you
> do not have to do anything special but use the default case
> as everybody else.
Yep, definitely better than my patch.
Björn
^ permalink raw reply
* Re: [BUG] t9101 (master) busted on Leopard
From: Björn Steinbrink @ 2007-11-16 12:48 UTC (permalink / raw)
To: Wincent Colaiuta
Cc: Benoit Sigoure, Git Mailing List,
Väinö Järvelä
In-Reply-To: <73246E38-9C22-4279-A53E-678434238E5C@wincent.com>
On 2007.11.16 12:00:02 +0100, Wincent Colaiuta wrote:
> El 15/11/2007, a las 22:13, Benoit Sigoure escribió:
>> Hi Wincent,
>> Can you reproduce this deterministically? If yes, can you re-run the test
>> with the --verbose flag and post the gzipped output (or send it to me if
>> the list doesn't like this sort of attachment).
>
> Inspecting the output of --verbose has allowed me to the point where things
> are failing; look at the very first test in t9101-git-svn-props.sh and
> witness the following:
>
> - before the test we are at revision 1
> - there are 3 "svn commits" in the test
> - but it looks like only 2 of the commits proceed
> - so the revision number goes up to 2 then 3, when it should be 4
> - as a result, in one of the later tests we fail because the test expects
> revision 8 but we only have revision 7
>
> Checked out revision 1.
> * ok 1: checkout working copy from svn
>
> * expecting success: cd test_wc &&
> echo Greetings >> kw.c &&
> poke kw.c &&
> svn commit -m "Not yet an Id" &&
> echo Hello world >> kw.c &&
> poke kw.c &&
> svn commit -m "Modified file, but still not yet an Id" &&
> svn propset svn:keywords Id kw.c &&
> poke kw.c &&
> svn commit -m "Propset Id" &&
> cd ..
> Sending kw.c
> Transmitting file data .
> Committed revision 2.
> Sending kw.c
> Transmitting file data .
> Committed revision 3.
> property 'svn:keywords' set on 'kw.c'
> * ok 2: setup some commits to svn
>
> That last commit is a no-op because, for some reason, the svn propset
> before it is also a no-op:
>
> svn propset svn:keywords Id kw.c
>
> In other words, it echos "property 'svn:keyword' set on 'kw.c'" but if I
> insert an "svn status" as the next command then I get no output at all. If
> I run the exact same commands manually from the terminal then they work
> (ie. it is not a no-op and "svn status" shows that the file is modified).
>
> Actually, it's not really a no-op, because if I insert an "svn proplist -v
> kw.c" I get:
>
> Properties on 'kw.c':
> svn:keywords : Id
It _is_ a no-op. At least here. Because I got an auto-props setting in
my ~/.subversion/config to automatically add Id for *.c files. So that
property was already there before we explicitly ask for it and the
propset turns into a no-op. If I remove that line from the subversion
configuration, the test succeeds. Same for you I guess.
That said, I had a quick glance over the subversion CLI help, but it
didn't tell me how to ignore/override ~/.subversion/config. Anyone less
clueless than me around, having a smart idea how to work around that
"bug"?
Björn
^ permalink raw reply
* Re: preserving mtime
From: Erik Warendorph @ 2007-11-16 12:09 UTC (permalink / raw)
To: Fabrizio Pollastri; +Cc: git
In-Reply-To: <473D63F9.4010201@inrim.it>
* Fabrizio Pollastri <f.pollastri@inrim.it> [2007-11-16 10:33:45 +0100]:
>
> is it possible to tell git to preserve the file modification time in a
> checked out copy? It is useful when managing web files, where mtime is
> tested by spiders for download decisions.
You may find the script "git-set-file-times" in the GitWiki
useful:
ExampleScripts - GitWiki
Setting the timestamps of the files to the commit timestamp
of the commit which last touched them
<http://git.or.cz/gitwiki/ExampleScripts#head-a57deb2b4ab1e2de80ab5fd3c681a6055a9d3247>
You should of course pay attention to advice about (and
against) doing stuff like this, both in the description of that
script and in other postings on this list. But as you are
using Git to manage web files and you (probably) don't care
about build systems such as "make", you should be pretty safe.
About the script: I think it originally was made by Eric Wong
(= normalperson) who is also on this list. I have just made a
tiny, tiny modification to it (adding " or s/\0$//" to the
elsif test).
I've also thought about adding a --prefix option to the script.
This would enable it to be used together with git-archive,
leaving the working directory alone and affecting the files in
the directory where the archive is extracted instead. In this
way, you would distinguish between your working directory and
your "live" directory, and the command sequence
git archive --prefix=foo/ HEAD | (cd /var/www/ && tar xf -)
git-set-file-times --prefix=/var/www/foo/
would be part of the build system, publishing your working
directory to your "live" directory (in this case
/var/www/foo/).
--
Erik Warendorph <erik@warendorph.org>
^ permalink raw reply
* Re: [PATCH] user-manual.txt: fix a few mistakes
From: Sergei Organov @ 2007-11-16 11:34 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: git, gitster
In-Reply-To: <20071116035416.GF18909@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> writes:
> On Thu, Nov 15, 2007 at 01:36:40PM +0300, Sergei Organov wrote:
>> "J. Bruce Fields" <bfields@fieldses.org> writes:
[...]
>> >> @@ -1567,8 +1567,8 @@ old history using, for example,
>> >> $ git log master@{1}
>> >> -------------------------------------------------
>> >>
>> >> -This lists the commits reachable from the previous version of the head.
>> >> -This syntax can be used to with any git command that accepts a commit,
>> >
>> > I actually prefer "head" here. On something like:
>> >
>> > A--B--C
>> > /
>> > o--o--o
>> > \
>> > o--o--o
>> >
>> >
>> > The term "branch" could be used to refer to the whole line of
>> > development consisting of A, B, and C. The term "head", on the other
>> > hand, refers to either C or a ref that points to it. We also use the
>> > terms "branch head" or just "branch" for that case, but I think "head"
>> > is more precise.
>>
>> Then I'd suggest to be precise here, e.g.:
>>
>> "This lists the commits reachable from the previous version of the
>> "master" branch head."
>
> That sounds sensible to me, sure.
OK, I've just submitted patch for that.
--
Sergei.
^ permalink raw reply
* [PATCH] user-manual.txt: minor clarification.
From: Sergei Organov @ 2007-11-16 11:28 UTC (permalink / raw)
To: git; +Cc: gitster
Signed-off-by: Sergei Organov <osv@javad.com>
---
Documentation/user-manual.txt | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index c7cfbbc..518b7b5 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1567,9 +1567,9 @@ old history using, for example,
$ git log master@{1}
-------------------------------------------------
-This lists the commits reachable from the previous version of the head.
-This syntax can be used with any git command that accepts a commit,
-not just with git log. Some other examples:
+This lists the commits reachable from the previous version of the
+"master" branch head. This syntax can be used with any git command
+that accepts a commit, not just with git log. Some other examples:
-------------------------------------------------
$ git show master@{2} # See where the branch pointed 2,
--
1.5.3.4
^ permalink raw reply related
* Re: [BUG] encoding problem with format-patch + send-email
From: Uwe Kleine-König @ 2007-11-16 11:14 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, git, Brian Swetland, Russell King - ARM Linux,
Nicolas Pitre
In-Reply-To: <20071116104907.GA13087@sigill.intra.peff.net>
Hello Jeff,
> sub unquote_rfc2047 {
> local ($_) = @_;
> - if (s/=\?utf-8\?q\?(.*)\?=/$1/g) {
> + my $encoding;
> + if (s/=\?([^?]+)\?q\?(.*)\?=/$2/g) {
> + $encoding = $1;
> s/_/ /g;
> s/=([0-9A-F]{2})/chr(hex($1))/eg;
> }
> - return "$_";
> + return wantarray ? ($_, $encoding) : $_;
> }
I don't know perl very well, but that wantarray seems hacky. (Something
in my head wants to have it always return ($_, $encoding) and fix all
callers. :-)
> [...]
> @@ -756,6 +769,21 @@ foreach my $t (@files) {
>
> if (defined $author) {
> $message = "From: $author\n\n$message";
> + if (defined $author_encoding) {
> + if ($has_content_type) {
> + if ($body_encoding eq $author_encoding) {
> + # ok, we already have the right encoding
> + }
> + else {
> + # uh oh, we should re-encode
IMHO we should bail here or do the recoding (and bail if that fails).
OTH this patch improves send-emails behaviour because currently it
doesn't bother at all and with this patch it could at least fix the
common cases.
So
Acked-by: Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
but note I only read the code, I didn't run it.
> + }
> + }
> + else {
> + push @xh,
> + 'MIME-Version: 1.0',
> + "Content-Type: text/plain; charset=$author_encoding";
> + }
> + }
> }
Best regards
Uwe
--
Uwe Kleine-König, Software Engineer
Digi International GmbH Branch Breisach, Küferstrasse 8, 79206 Breisach, Germany
Tax: 315/5781/0242 / VAT: DE153662976 / Reg. Amtsgericht Dortmund HRB 13962
^ permalink raw reply
* Re: [BUG] t9101 (master) busted on Leopard
From: Wincent Colaiuta @ 2007-11-16 11:00 UTC (permalink / raw)
To: Benoit Sigoure; +Cc: Git Mailing List, Väinö Järvelä
In-Reply-To: <1D7CC3C0-46C1-40D9-AAD5-B9ADFF99B58A@lrde.epita.fr>
El 15/11/2007, a las 22:13, Benoit Sigoure escribió:
> On Nov 15, 2007, at 5:11 PM, Wincent Colaiuta wrote:
>
>> El 15/11/2007, a las 17:04, Brian Gernhardt escribió:
>>
>>> On Nov 15, 2007, at 8:46 AM, Wincent Colaiuta wrote:
>>>
>>>> Was just running the test suite against the master branch and saw
>>>> that t9101 is currently failing on Leopard, and a review with git-
>>>> bisect indicates that it has been ever since it was first
>>>> introduced (in commit 15153451). Not sure if this problem is
>>>> Leopard-specific or not as I only have one machine.
>>>
>>> It is not a Leopard specific problem, as far as I can tell. I
>>> just ran the test and had no errors on my Leopard machine. So
>>> perhaps it's some other detail of your setup?
>>>
>>>> I'm not a git-svn user myself, but if there's anything I can do
>>>> to help diagnose this problem further on Leopard please let me
>>>> know.
>>>
>>> I just tested it using svn from fink and (after discovering it
>>> exists) from Leopard. No problems. Do you have an old svn
>>> package (client, admin, or perl binding) installed from Darwin
>>> Ports or Fink perhaps?
>>
>> I don't use Darwin Ports or Fink, and this is a clean Leopard
>> install (ie. nothing installed in /usr/local apart from git and a
>> very small number of other tools that aren't related to Subversion).
>>
>> This is the output of "/usr/bin/svn --version":
>>
>> svn, version 1.4.4 (r25188)
>> compiled Sep 23 2007, 22:32:34
>>
>> Perhaps then it is something in the environment.
>
> Hi Wincent,
> Can you reproduce this deterministically? If yes, can you re-run
> the test with the --verbose flag and post the gzipped output (or
> send it to me if the list doesn't like this sort of attachment).
Inspecting the output of --verbose has allowed me to the point where
things are failing; look at the very first test in t9101-git-svn-
props.sh and witness the following:
- before the test we are at revision 1
- there are 3 "svn commits" in the test
- but it looks like only 2 of the commits proceed
- so the revision number goes up to 2 then 3, when it should be 4
- as a result, in one of the later tests we fail because the test
expects revision 8 but we only have revision 7
Checked out revision 1.
* ok 1: checkout working copy from svn
* expecting success: cd test_wc &&
echo Greetings >> kw.c &&
poke kw.c &&
svn commit -m "Not yet an Id" &&
echo Hello world >> kw.c &&
poke kw.c &&
svn commit -m "Modified file, but still not yet an Id" &&
svn propset svn:keywords Id kw.c &&
poke kw.c &&
svn commit -m "Propset Id" &&
cd ..
Sending kw.c
Transmitting file data .
Committed revision 2.
Sending kw.c
Transmitting file data .
Committed revision 3.
property 'svn:keywords' set on 'kw.c'
* ok 2: setup some commits to svn
That last commit is a no-op because, for some reason, the svn propset
before it is also a no-op:
svn propset svn:keywords Id kw.c
In other words, it echos "property 'svn:keyword' set on 'kw.c'" but if
I insert an "svn status" as the next command then I get no output at
all. If I run the exact same commands manually from the terminal then
they work (ie. it is not a no-op and "svn status" shows that the file
is modified).
Actually, it's not really a no-op, because if I insert an "svn
proplist -v kw.c" I get:
Properties on 'kw.c':
svn:keywords : Id
So the property is being set, it's just that "svn commit" and "svn
status" don't recognize the file as being modified. The "poke" in the
test has no effect (file still shows up as unmodified) and only
modifying the actual content (ie. appending to it by inserting another
"echo" statement) is enough to make that commit actually happen.
So now we know a bit more about *what* is happening, but I still don't
know *why*. I'd start to suspect some kind of weird filesystem issue
if it weren't for the fact that these same commands work when executed
by hand outside of the test script.
Cheers,
Wincent
^ permalink raw reply
* Re: [BUG] encoding problem with format-patch + send-email
From: Jeff King @ 2007-11-16 10:49 UTC (permalink / raw)
To: Uwe Kleine-König, Junio C Hamano
Cc: git, Brian Swetland, Russell King - ARM Linux, Nicolas Pitre
In-Reply-To: <20071115105726.GA18555@bre-cln-ukleine.digi.com>
On Thu, Nov 15, 2007 at 11:57:26AM +0100, Uwe Kleine-König wrote:
> send-email adds "From: A. U. Thor <author@tld>" to the body if sender
> and From: in the patch to send differ.
>
> Both is just fine, but if the author has some non-ascii characters in
> her name but the body is ascii-only the resulting mail is broken.
I posted an untested fix to this and discussed the issue in
http://article.gmane.org/gmane.comp.version-control.git/64426
http://article.gmane.org/gmane.comp.version-control.git/64436
but nobody seems to have been interested after that (I don't even use
git-send-email myself).
Below is an updated patch (there was a typo in one of the regexes in the
original) that meets my limited testing for the all-utf8 case (I don't
know how people actually use alternate encodings with git, if at all, so
I don't know that I can put together a good test case). My test case was
something like:
git-clone git test && cd test
echo junk >>Makefile
git-commit -m junk --author 'Uwe Kleine-König <peff@peff.net>' -a
git-format-patch HEAD^
git-send-email 0001-junk.patch
> What about adding the Content-Type and Content-Transfer-Encoding headers
> in any case?
You could probably add them unconditionally, but it would be nice to
have them match the encoding, so you'd still want to pick them out of
the rfc2047 encoding in the from header.
-Peff
-- >8 --
git-send-email: add charset header if we add encoded 'From'
We sometimes pick out the original rfc822 'From' header and
include it in the body of the message. If the original
author's name needs encoding, then we should specify that in
the content-type header.
If we already had a content-type header in the mail, then we
may need to re-encode. The logic is there to detect
this case, but it doesn't actually do the re-encoding.
Signed-off-by: Jeff King <peff@peff.net>
---
git-send-email.perl | 34 +++++++++++++++++++++++++++++++---
1 files changed, 31 insertions(+), 3 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index f9bd2e5..fd0a4ad 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -514,11 +514,13 @@ $time = time - scalar $#files;
sub unquote_rfc2047 {
local ($_) = @_;
- if (s/=\?utf-8\?q\?(.*)\?=/$1/g) {
+ my $encoding;
+ if (s/=\?([^?]+)\?q\?(.*)\?=/$2/g) {
+ $encoding = $1;
s/_/ /g;
s/=([0-9A-F]{2})/chr(hex($1))/eg;
}
- return "$_";
+ return wantarray ? ($_, $encoding) : $_;
}
# use the simplest quoting being able to handle the recipient
@@ -667,6 +669,9 @@ foreach my $t (@files) {
open(F,"<",$t) or die "can't open file $t";
my $author = undef;
+ my $author_encoding;
+ my $has_content_type;
+ my $body_encoding;
@cc = @initial_cc;
@xh = ();
my $input_format = undef;
@@ -692,12 +697,20 @@ foreach my $t (@files) {
next if ($suppress_from);
}
elsif ($1 eq 'From') {
- $author = unquote_rfc2047($2);
+ ($author, $author_encoding)
+ = unquote_rfc2047($2);
}
printf("(mbox) Adding cc: %s from line '%s'\n",
$2, $_) unless $quiet;
push @cc, $2;
}
+ elsif (/^Content-type:/i) {
+ $has_content_type = 1;
+ if (/charset="?[^ "]+/) {
+ $body_encoding = $1;
+ }
+ push @xh, $_;
+ }
elsif (!/^Date:\s/ && /^[-A-Za-z]+:\s+\S/) {
push @xh, $_;
}
@@ -756,6 +769,21 @@ foreach my $t (@files) {
if (defined $author) {
$message = "From: $author\n\n$message";
+ if (defined $author_encoding) {
+ if ($has_content_type) {
+ if ($body_encoding eq $author_encoding) {
+ # ok, we already have the right encoding
+ }
+ else {
+ # uh oh, we should re-encode
+ }
+ }
+ else {
+ push @xh,
+ 'MIME-Version: 1.0',
+ "Content-Type: text/plain; charset=$author_encoding";
+ }
+ }
}
send_message();
--
1.5.3.1.47.g88b7d-dirty
^ permalink raw reply related
* Re: preserving mtime
From: Junio C Hamano @ 2007-11-16 10:21 UTC (permalink / raw)
To: Fabrizio Pollastri; +Cc: git
In-Reply-To: <473D63F9.4010201@inrim.it>
Fabrizio Pollastri <f.pollastri@inrim.it> writes:
> is it possible to tell git to preserve the file modification time in a
> checked out copy? It is useful when managing web files, where mtime is
> tested by spiders for download decisions.
"git checkout branchA" after "git checkout branchB" would not
touch "file" if "file" are identical between two branches, so
the modification time is already preserved.
If the contents of "file" from the version you would want to
check out is different from the version you previously checked
out, and you still want to keep the old timestamp, then you are
trying to do something that a normal SCM user would actively not
want (e.g. doing so would screw up the build systems such as
"make"). Such a specialized need usually is addressed by the
build and install procedure of the application (in your case, a
website management). Maybe your current build procedure may
blindly copy when installing:
install: web.html
$(install) web.html $(dest)/var/www/web.html
but you may want to ignore certain classes of changes and avoid
re-installing to help crawlers. You would do:
install = ./myinstall.sh
install: web.html
$(install) web.html $(dest)/var/www/web.html
and then ./myinstall.sh might look like:
#!/bin/sh
test -f "$2" &&
compare-ignoring-minor-changes "$1" "$2" && exit 0
install "$1" "$2"
^ permalink raw reply
* Re: preserving mtime
From: Jakub Narebski @ 2007-11-16 10:19 UTC (permalink / raw)
To: git
In-Reply-To: <473D63F9.4010201@inrim.it>
Fabrizio Pollastri wrote:
> is it possible to tell git to preserve the file modification time in a
> checked out copy? It is useful when managing web files, where mtime is
> tested by spiders for download decisions.
I don't quite understand. When git checks out copy, or switch branches,
or resets it does update only files which changed.
Git does not store mtime of files in tree object.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [BUG] t9101 (master) busted on Leopard
From: Wincent Colaiuta @ 2007-11-16 10:17 UTC (permalink / raw)
To: Väinö Järvelä; +Cc: Brian Gernhardt, Git Mailing List
In-Reply-To: <4207CF02-36BD-4733-9861-17B0C4DB9D94@pp.inet.fi>
El 16/11/2007, a las 9:59, Väinö Järvelä escribió:
> On Nov 16, 2007, at 10:37, Wincent Colaiuta wrote:
>
>> Strange. I've looked in the environment and there is nothing
>> suspicious; in fact, running the tests with a totally clean
>> environment (env -i ./t9101-git-svn-props.sh) produces exactly the
>> same result.
>>
>> This was with commit 039bc64e (HEAD of master yesterday). I just
>> tested the commit you mention (HEAD of next) and get the same
>> failure; this is the procedure I'm using to test:
>>
>> git fetch
>> git checkout -b next_test origin/next
>> git describe # (v1.5.3.5-1780-gca2b71c)
>> git clean
>> make clean && make
>> cd t
>> env -i ./t9101-git-svn-props.sh
>>
>> So really, not sure what could be causing this.
>
> Did you forget to install the newly compiled version? Or does the
> test system use git from the source tree?
I didn't install the newly compiled version because, as far as know,
the test system uses the built copy in the source tree (I can't
actually recall *any* Makefile-based open source projects that didn't
work like that).
$ git --version
git version 1.5.3.5
$ /usr/local/bin/git --version
git version 1.5.3.5
$ ./git --version # (from inside the source tree)
git version 1.5.3.5.1780.gca2b
$ env -i git --version
env: git: No such file or directory
So the test run above *must* be using the just-built copy in the
source tree otherwise *none* of the tests would pass.
Cheers,
Wincent
^ permalink raw reply
* Re: preserving mtime
From: Andreas Ericsson @ 2007-11-16 10:15 UTC (permalink / raw)
To: Fabrizio Pollastri; +Cc: git
In-Reply-To: <473D63F9.4010201@inrim.it>
Fabrizio Pollastri wrote:
> Hi all,
> is it possible to tell git to preserve the file modification time in a
> checked out copy? It is useful when managing web files, where mtime is
> tested by spiders for download decisions.
No. Doing so would seriously break build-systems. If you want you can
have a post-checkout hook that sets the mtime on all the files though.
You should be able to parse the time the commit being checked out was
made from HEAD.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* preserving mtime
From: Fabrizio Pollastri @ 2007-11-16 9:33 UTC (permalink / raw)
To: git
Hi all,
is it possible to tell git to preserve the file modification time in a
checked out copy? It is useful when managing web files, where mtime is
tested by spiders for download decisions.
Thank you, for any help.
--
Cheers,
F. Pollastri
^ permalink raw reply
* Re: [BUG] t9101 (master) busted on Leopard
From: Väinö Järvelä @ 2007-11-16 8:59 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Brian Gernhardt, Git Mailing List
In-Reply-To: <E20C625B-100C-44B0-9AF3-7342DAF9B2A7@wincent.com>
On Nov 16, 2007, at 10:37, Wincent Colaiuta wrote:
> El 16/11/2007, a las 5:25, Väinö Järvelä escribió:
>
>> On Nov 15, 2007, at 18:11, Wincent Colaiuta wrote:
>>
>>> I don't use Darwin Ports or Fink, and this is a clean Leopard
>>> install (ie. nothing installed in /usr/local apart from git and a
>>> very small number of other tools that aren't related to Subversion).
>>>
>>> This is the output of "/usr/bin/svn --version":
>>>
>>> svn, version 1.4.4 (r25188)
>>> compiled Sep 23 2007, 22:32:34
>>>
>>> Perhaps then it is something in the environment.
>>
>> I cannot reproduce this on Leopard (not yet updated to 10.5.1). I
>> tested this with self-compiled GIT from commit id ca2b71c
>>
>> svn version is the same as yours, I do use Fink, and I have used
>> Fink to install Perl SVN bindings.
>
> Strange. I've looked in the environment and there is nothing
> suspicious; in fact, running the tests with a totally clean
> environment (env -i ./t9101-git-svn-props.sh) produces exactly the
> same result.
>
> This was with commit 039bc64e (HEAD of master yesterday). I just
> tested the commit you mention (HEAD of next) and get the same
> failure; this is the procedure I'm using to test:
>
> git fetch
> git checkout -b next_test origin/next
> git describe # (v1.5.3.5-1780-gca2b71c)
> git clean
> make clean && make
> cd t
> env -i ./t9101-git-svn-props.sh
>
> So really, not sure what could be causing this.
Did you forget to install the newly compiled version? Or does the test
system use git from the source tree?
--
Väinö
^ permalink raw reply
* Fix per-directory exclude handing for "git add"
From: Junio C Hamano @ 2007-11-16 9:15 UTC (permalink / raw)
To: Bruce Stephens; +Cc: Linus Torvalds, git
In-Reply-To: <7vir4341ok.fsf@gitster.siamese.dyndns.org>
In "dir_struct", each exclusion element in the exclusion stack records a
base string (pointer to the beginning with length) so that we can tell
where it came from, but this pointer is just pointing at the parameter
that is given by the caller to the push_exclude_per_directory()
function.
While read_directory_recursive() runs, calls to excluded() makes use
the data in the exclusion elements, including this base string. The
caller of read_directory_recursive() is not supposed to free the
buffer it gave to push_exclude_per_directory() earlier, until it
returns.
The test case Bruce Stephens gave in the mailing list discussion
was simplified and added to the t3700 test.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Junio C Hamano <gitster@pobox.com> writes:
> Here is a tentative patch. I do not think the patch is broken
> but I call it tentative because:
>
> - It is ugly -- I never get this "walking path delimited by
> slashes" loop right;
>
> - It leaks the path buffer given to push(), but it is inherent
> in the design of "push/pop exclude per-directory" API.
It turns out that a minimally invasive fix was a lot simpler
than I thought.
This still does not fix the other codepaths in ls-files that does not
use read_directory() but walks the cache.
dir.c | 6 ++++--
t/t3700-add.sh | 24 ++++++++++++++++++++++++
2 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/dir.c b/dir.c
index fa9f902..225fdfb 100644
--- a/dir.c
+++ b/dir.c
@@ -654,6 +654,7 @@ static void free_simplify(struct path_simplify *simplify)
int read_directory(struct dir_struct *dir, const char *path, const char *base, int baselen, const char **pathspec)
{
struct path_simplify *simplify = create_simplify(pathspec);
+ char *pp = NULL;
/*
* Make sure to do the per-directory exclude for all the
@@ -661,7 +662,8 @@ int read_directory(struct dir_struct *dir, const char *path, const char *base, i
*/
if (baselen) {
if (dir->exclude_per_dir) {
- char *p, *pp = xmalloc(baselen+1);
+ char *p;
+ pp = xmalloc(baselen+1);
memcpy(pp, base, baselen+1);
p = pp;
while (1) {
@@ -677,12 +679,12 @@ int read_directory(struct dir_struct *dir, const char *path, const char *base, i
else
p = pp + baselen;
}
- free(pp);
}
}
read_directory_recursive(dir, path, base, baselen, 0, simplify);
free_simplify(simplify);
+ free(pp);
qsort(dir->entries, dir->nr, sizeof(struct dir_entry *), cmp_name);
qsort(dir->ignored, dir->ignored_nr, sizeof(struct dir_entry *), cmp_name);
return dir->nr;
diff --git a/t/t3700-add.sh b/t/t3700-add.sh
index a328bf5..287e058 100755
--- a/t/t3700-add.sh
+++ b/t/t3700-add.sh
@@ -104,9 +104,33 @@ test_expect_success 'add ignored ones with -f' '
git ls-files --error-unmatch d.ig/d.if d.ig/d.ig
'
+test_expect_success 'add ignored ones with -f' '
+ rm -f .git/index &&
+ git add -f d.?? &&
+ git ls-files --error-unmatch d.ig/d.if d.ig/d.ig
+'
+
+test_expect_success '.gitignore with subdirectory' '
+
+ rm -f .git/index &&
+ mkdir -p sub/dir &&
+ echo "!dir/a.*" >sub/.gitignore &&
+ >sub/a.ig &&
+ >sub/dir/a.ig &&
+ git add sub/dir &&
+ git ls-files --error-unmatch sub/dir/a.ig &&
+ rm -f .git/index &&
+ (
+ cd sub/dir &&
+ git add .
+ ) &&
+ git ls-files --error-unmatch sub/dir/a.ig
+'
+
mkdir 1 1/2 1/3
touch 1/2/a 1/3/b 1/2/c
test_expect_success 'check correct prefix detection' '
+ rm -f .git/index &&
git add 1/2/a 1/3/b 1/2/c
'
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox