* Re: gmail smtp server and git-send-mail. Is this combination working?
From: Jason Sewall @ 2008-01-08 18:16 UTC (permalink / raw)
To: Paolo Ciarrocchi, git
In-Reply-To: <4d8e3fd30801080858h5f109b47v87abc6b315fcfa08@mail.gmail.com>
I've had luck with msmtp: http://msmtp.sourceforge.net/; it's
basically a drop-in replacement for sendmail that supports the
authentication gmail requires.
A quick prayer to the Gods of Google portended this blog entry, which
spells out how to configure it for gmail pretty plainly:
http://typo.onxen.info/articles/2006/06/27/activemailer-sending-via-gmail
Then you just need to specify --smtp-serve /path/to/msmtp to
send-email and you're all set.
Jason
On Jan 8, 2008 11:58 AM, Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> wrote:
> Hi all,
> as I previously wrote I would like to use git-send-email to send out a series
> of patches.
> While I was looking for documentation I saw the following statement in the
> git wiki:
>
> " Mailing off a set of patches to a mailing list can be quite neatly
> done by git-send-email.
> One of the problems you may encounter there is figuring out which machine
> is going to send your mail.
> I tried smtp.gmail.com, but that one requires tls and a password,
> and git-send-email could not handle that "
>
> From http://git.or.cz/gitwiki/GitTips.
>
> Is this statemant still correct ?
> Is msmtp the only solution for using git-send-mail with gmail? (tls +
> autentication).
>
> Thanks.
>
> regards,
> --
> Paolo
> http://paolo.ciarrocchi.googlepages.com/
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Junio C Hamano @ 2008-01-08 18:07 UTC (permalink / raw)
To: public-prohaska-wjoc1KHpMeg
Cc: J. Bruce Fields, Johannes Schindelin, Robin Rosenberg, Jeff King,
Peter Karlsson, Git Mailing List,
public-msysgit-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <CE10C08D-AAF1-44B5-89B5-9A16A4AB70EA@zib.de>
Steffen Prohaska <prohaska-wjoc1KHpMeg@public.gmane.org> writes:
> msysgit installs plain git. core.autocrlf is unset. Whatever plain
> git's default is, this is msysgit's default, too.
That sounds like a mistake if you are installing a port to a
platform whose native line ending convention is different from
where plain git natively runs on (i.e. UNIX).
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Junio C Hamano @ 2008-01-08 18:07 UTC (permalink / raw)
To: public-prohaska-wjoc1KHpMeg
Cc: J. Bruce Fields, Johannes Schindelin, Robin Rosenberg, Jeff King,
Peter Karlsson, Git Mailing List,
public-msysgit-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <CE10C08D-AAF1-44B5-89B5-9A16A4AB70EA@zib.de>
Steffen Prohaska <prohaska-wjoc1KHpMeg@public.gmane.org> writes:
> msysgit installs plain git. core.autocrlf is unset. Whatever plain
> git's default is, this is msysgit's default, too.
That sounds like a mistake if you are installing a port to a
platform whose native line ending convention is different from
where plain git natively runs on (i.e. UNIX).
^ permalink raw reply
* Re: An interaction with ce_match_stat_basic() and autocrlf
From: Junio C Hamano @ 2008-01-08 18:04 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.1.00.0801080748080.3148@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Tue, 8 Jan 2008, Junio C Hamano wrote:
>>
>> This is caused partly by the breakage in size_only codepath of
>> diff.c::diff_populate_filespec().
>
> Only partially.
Agreed. That's why it is "just a half of the story".
> The more fundamental behaviour (that of git update-index) is caused by
> ie_modified() thinking that when DATA_CHANGED is true, it cannot possibly
> need to call "ce_modified_check_fs()":
> ...
> Similarly, I think that the problem with "diff" not realizing they might
> be the same comes from ie_match_stat(), which has a similar problem in not
> realizing that DATA_CHANGED could possibly still mean that it's the same.
Yes, I think your patch to ie_modified() should take care of the
issue from the diff-files front-end side, which is the right
approach. The optimization diffcore_populate_filespec() makes
when asked to do size_only, which predates the addition of
convert_to_git(), needs to be updated regardless, though. The
size field in diffcore_filespec is never about on-filesystem
size.
> This patch should fix it, but I suspect we should think hard about that
> change to ie_modified(), and see what the performance issues are (ie that
> code has tried to avoid doing the more expensive ce_modified_check_fs()
> for a reason).
I think the reason was I simply avoided doing any unnecessary
operation that goes to the filesystem. We did not even have
that modified_check_fs() code before the racy-git safety, and
when I added it I do not think I benched it with a real-life
workload; the logic there was simply a valid optimization back
then.
It is not anymore. Addition of convert_to_git() made cached
stat info essentially ineffective in the sense that:
(1) if a user changes the work tree files in such a way that
does not change convert_to_git() output, the index will say
"file contents in external representation has definitely
changed, the sizes no longer match". We need to actually
go to the data to find out that there is no change at the
canonical level.
(2) if a user changes the crlf setting (or .gitattributes)
without touching the work tree files, the index will say
"unchanged and do not have to compare". We need to
actually go to the data to find out that they do not match
anymore.
The latter is an opposite issue of what I brought up in this
thread. I personally do not want to "fix" it --- it means
destroying one of the most important optimizations. The use
case is essentially a one-shot operation for a user to "fix" a
broken crlf setting, and having to re-checkout everything is a
small cost to pay to maintain it.
But the former is something we should be able to deal with
sanely.
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Steffen Prohaska @ 2008-01-08 17:56 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Johannes Schindelin, Robin Rosenberg, Jeff King, Peter Karlsson,
Git Mailing List, msysgit-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20080108172957.GG22155-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
On Jan 8, 2008, at 6:29 PM, J. Bruce Fields wrote:
> On Mon, Jan 07, 2008 at 10:40:56PM +0100, Steffen Prohaska wrote:
>> Eventually I gave in and even voted for "Git does not modify
>> content unless explicitly requested otherwise".
>>
>> Here's the full discussion:
>>
>> http://code.google.com/p/msysgit/issues/detail?id=21
>>
>> I believe the main question is which type of projects we would like
>> to support by our default. For real cross-platform projects that
>> will
>> be checked out on Windows and Unix we should choose
>> "core.autocrlf true" as our default. But if our default are native
>> Windows projects that will never be checked out on Unix, then we
>> should not set core.autocrlf by default.
>
> If the policy really depends on the project, then surely the default
> behavior should be determined by information carried in the project
> itself (e.g., the .gitattributes)?
Unfortunately it depends on the project _and_ the platform. A
cross-platform project should have core.autocrlf=input on Unix and
core.autocrlf=true on Windows. I don't think I can represent this
with the current .gitattributes.
Do you suggest to add this kind of magic to .gitattributes? Such as
to have .gitattributes containing
--- SNIP ---
* crlf=autonative
--- SNIP ---
which would tell git to act as if core.autocrlf=input was set on Unix
and core.autocrlf=true was set on Windows.
> For that reason it strikes me as a mistake to ignore the crlf
> attribute
> by default (assuming that is indeed the current behavior; apologies
> for
> not checking). If crlf is set then I think it should be assumed that
> crlf conversion should be done unless that has been explicitly turned
> off somehow.
I don't understand this comment.
msysgit installs plain git. core.autocrlf is unset. Whatever plain
git's default is, this is msysgit's default, too.
Steffen
^ permalink raw reply
* Re: [PATCH 1/2] sideband.c: Use xmalloc() instead of variable-sized arrays.
From: Junio C Hamano @ 2008-01-08 17:41 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git Mailing List
In-Reply-To: <4783A3B2.3060801@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> From: Johannes Sixt <johannes.sixt@telecom.at>
>
> How come we got along with this not very portable construct for so long?
> Probably because the array sizes were computed from the results of
> strlen() of string constants. Anyway, a follow-up patch will make the
> lengths really non-constant.
>
> Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
> ---
> sideband.c | 14 ++++++++++++--
> 1 files changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/sideband.c b/sideband.c
> index 756bbc2..513d7b3 100644
> --- a/sideband.c
> +++ b/sideband.c
> @@ -19,7 +19,10 @@ int recv_sideband(const char *me, int in_stream, int out, int err)
> {
> unsigned pf = strlen(PREFIX);
> unsigned sf = strlen(SUFFIX);
> - char buf[pf + LARGE_PACKET_MAX + sf + 1];
> + char *buf, *save;
> +
> + save = xmalloc(sf);
> + buf = xmalloc(pf + LARGE_PACKET_MAX + sf + 1);
I have to wonder if the malloc() overhead is small enough
compared to the network bandwidth to make a two malloc-free
pairs per packet a non-issue...
^ permalink raw reply
* Re: An interaction with ce_match_stat_basic() and autocrlf
From: Linus Torvalds @ 2008-01-08 17:30 UTC (permalink / raw)
To: Pēteris Kļaviņš; +Cc: git
In-Reply-To: <fm0au5$i65$1@ger.gmane.org>
On Tue, 8 Jan 2008, Pēteris Kļaviņš wrote:
>
> In summary, it irks me that autocrlf true mode is a second cousin of autocrlf
> false and I think that there *should* be an acceptable deterministic solution
> to this.
Well, I think the real issue is simply that most the main git developers
do development on architectures where CRLF just isn't an issue.
So it's not that autocrlf is a "second cousin", it's that
- CRLF is stupid to begin with, and slightly anathemical to the git
worldview of trying to be as exact as possible.
- ..and almost nobody in the git community is actually affected, so
people don't even notice when it's an issue.
People who actually care and use crlf are probably best off sending in
test-cases for particular behaviour they notice.
Linus
^ permalink raw reply
* Re: Odd number of elements in anonymous hash
From: Dennis Schridde @ 2008-01-08 17:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eric Wong, git
In-Reply-To: <7vbq7wteq4.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1165 bytes --]
Am Dienstag, 8. Januar 2008 18:21:55 schrieb Junio C Hamano:
> Dennis Schridde <devurandom@gmx.net> writes:
> > Hello!
> >
> > I am getting "Odd number of elements in anonymous hash at
> > /usr/bin/git-svn line 1760." (normal output, no warning/error) during
> > git-svn-clone. I am using git version 1.5.4.rc2.
> >
> > Line 1760 is this (with context, marked with '!!'):
> > # see if we have it in our config, first:
> > eval {
> > my $section = "svn-remote.$self->{repo_id}";
> > !! $svnsync = {
> > url => tmp_config('--get', "$section.svnsync-url"),
> > uuid => tmp_config('--get', "$section.svnsync-uuid"),
> > }
> > };
> >
> > The commandline was "git svn
> > clone --authors-file=/var/git/org.gna.warzone.git/authors
> > --use-svnsync-props --stdlayout file:///var/svn/warzone2100/
> > org.gna.warzone.git/"
> >
> > I assume this is some kind of bug?
>
> More than one svn-remote.$your_repo.svnsync-{url,uuid}?
PS: It doesn't happen for every revision and the folders (and thus config)
were empty before. The config doesn't list any "svnsync-*" during the import
process.
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: J. Bruce Fields @ 2008-01-08 17:29 UTC (permalink / raw)
To: Steffen Prohaska
Cc: Johannes Schindelin, Robin Rosenberg, Jeff King, Peter Karlsson,
Git Mailing List, msysgit-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <3B08AC4C-A807-4155-8AD7-DC6A6D0FE134-wjoc1KHpMeg@public.gmane.org>
On Mon, Jan 07, 2008 at 10:40:56PM +0100, Steffen Prohaska wrote:
> Eventually I gave in and even voted for "Git does not modify
> content unless explicitly requested otherwise".
>
> Here's the full discussion:
>
> http://code.google.com/p/msysgit/issues/detail?id=21
>
> I believe the main question is which type of projects we would like
> to support by our default. For real cross-platform projects that will
> be checked out on Windows and Unix we should choose
> "core.autocrlf true" as our default. But if our default are native
> Windows projects that will never be checked out on Unix, then we
> should not set core.autocrlf by default.
If the policy really depends on the project, then surely the default
behavior should be determined by information carried in the project
itself (e.g., the .gitattributes)?
For that reason it strikes me as a mistake to ignore the crlf attribute
by default (assuming that is indeed the current behavior; apologies for
not checking). If crlf is set then I think it should be assumed that
crlf conversion should be done unless that has been explicitly turned
off somehow.
--b.
^ permalink raw reply
* Re: Odd number of elements in anonymous hash
From: Junio C Hamano @ 2008-01-08 17:21 UTC (permalink / raw)
To: Dennis Schridde, Eric Wong; +Cc: git
In-Reply-To: <200801081738.56624.devurandom@gmx.net>
Dennis Schridde <devurandom@gmx.net> writes:
> Hello!
>
> I am getting "Odd number of elements in anonymous hash at /usr/bin/git-svn
> line 1760." (normal output, no warning/error) during git-svn-clone.
> I am using git version 1.5.4.rc2.
>
> Line 1760 is this (with context, marked with '!!'):
> # see if we have it in our config, first:
> eval {
> my $section = "svn-remote.$self->{repo_id}";
> !! $svnsync = {
> url => tmp_config('--get', "$section.svnsync-url"),
> uuid => tmp_config('--get', "$section.svnsync-uuid"),
> }
> };
>
> The commandline was "git svn
> clone --authors-file=/var/git/org.gna.warzone.git/authors --use-svnsync-props --stdlayout
> file:///var/svn/warzone2100/ org.gna.warzone.git/"
>
> I assume this is some kind of bug?
More than one svn-remote.$your_repo.svnsync-{url,uuid}?
(Eric CC'ed).
^ permalink raw reply
* Re: An interaction with ce_match_stat_basic() and autocrlf
From: Pēteris Kļaviņš @ 2008-01-08 17:12 UTC (permalink / raw)
To: git
In-Reply-To: <7vfxx8tt1z.fsf@gitster.siamese.dyndns.org>
> At this point, the index records a blob with LF line ending,
> while the work tree file has the same content with CRLF line
> ending.
I think this needs more than just sleeping on.
There are two separate problems related to crlf treatment in git that
manifest themselves in the quirks you see in the current implementation:
(1) The fact that the index may be misaligned with the work tree. Junio's
example demonstrates this well. I have resorted to
$ rm -rf *
$ git reset --hard
in the past to get a work tree that passes
$ git status
without false positives after changing the value of autocrlf.
(2) The fact that repository content may be mangled in an indeterminate way
because of the current work tree <-> repository transformation algorithm.
While criticism in the past has mainly been levelled at not knowing whether
a truly binary file will be correctly determined as such, content can be
lost in the round trip work tree -> repository -> work tree much more
simply:
$ git init
$ git config core.autocrlf true
$ echo ab | tr ab \\r\\n >a.txt
$ od -t a a.txt
0000000 cr nl nl
0000003
$ git add a.txt
$ git commit
$ rm a.txt
$ git reset --hard
$ od -t a a.txt
0000000 cr nl cr nl
0000004
In summary, it irks me that autocrlf true mode is a second cousin of
autocrlf false and I think that there *should* be an acceptable
deterministic solution to this.
The solution to (2) seems easier than (1): could the transformation
algorithm be made deterministic and changed to something like "convert all
crlf pairs to lf if and only if no singleton cr or lf exist in the file
before conversion"? If a binary file gets mangled in error, it would be an
easy transformation with standard tools to get the file back again. If an
otherwise text file has mixed lf and crlf endings, or additional cr or lf
sprinkled randomly through it, the file is not transformed.
Given a deterministic transformation algorithm, the solution to (1) boils
down to recording for each file in the work tree whether the transformation
algorithm was used or not in arriving at the file's current contents,
together with a way of telling git to force the use of the transformation
algorithm or not for a particular file. It seems to me the place that this
information *should* be recorded is the index, given that both .git/config
and .gitattributes can be changed independently of the work tree. Recording
the information in the index would mean that both autocrlf true and autocrlf
false clones of the same repository would produce equally valid work trees
with no loss of information. I am however not well versed enough in git
internals at the moment to know whether this is an acceptable solution or
not.
^ permalink raw reply
* Re: [PATCH 1/2] sideband.c: Use xmalloc() instead of variable-sized arrays.
From: Nicolas Pitre @ 2008-01-08 17:01 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <4783A3B2.3060801@viscovery.net>
On Tue, 8 Jan 2008, Johannes Sixt wrote:
> From: Johannes Sixt <johannes.sixt@telecom.at>
>
> How come we got along with this not very portable construct for so long?
> Probably because the array sizes were computed from the results of
> strlen() of string constants.
Maybe because it isn't not so unportable anymore? I doubt that
compilers that don't know about automatic arrays would be smart enough
to notice the variable was actually a constant due to the strlen() of a
constant string and just do like if there wasn't any variable for the
array size.
> Anyway, a follow-up patch will make the
> lengths really non-constant.
Fair enough.
Nicolas
^ permalink raw reply
* gmail smtp server and git-send-mail. Is this combination working?
From: Paolo Ciarrocchi @ 2008-01-08 16:58 UTC (permalink / raw)
To: Git Mailing List
Hi all,
as I previously wrote I would like to use git-send-email to send out a series
of patches.
While I was looking for documentation I saw the following statement in the
git wiki:
" Mailing off a set of patches to a mailing list can be quite neatly
done by git-send-email.
One of the problems you may encounter there is figuring out which machine
is going to send your mail.
I tried smtp.gmail.com, but that one requires tls and a password,
and git-send-email could not handle that "
>From http://git.or.cz/gitwiki/GitTips.
Is this statemant still correct ?
Is msmtp the only solution for using git-send-mail with gmail? (tls +
autentication).
Thanks.
regards,
--
Paolo
http://paolo.ciarrocchi.googlepages.com/
^ permalink raw reply
* Odd number of elements in anonymous hash
From: Dennis Schridde @ 2008-01-08 16:38 UTC (permalink / raw)
To: git
Hello!
I am getting "Odd number of elements in anonymous hash at /usr/bin/git-svn
line 1760." (normal output, no warning/error) during git-svn-clone.
I am using git version 1.5.4.rc2.
Line 1760 is this (with context, marked with '!!'):
# see if we have it in our config, first:
eval {
my $section = "svn-remote.$self->{repo_id}";
!! $svnsync = {
url => tmp_config('--get', "$section.svnsync-url"),
uuid => tmp_config('--get', "$section.svnsync-uuid"),
}
};
The commandline was "git svn
clone --authors-file=/var/git/org.gna.warzone.git/authors --use-svnsync-props --stdlayout
file:///var/svn/warzone2100/ org.gna.warzone.git/"
I assume this is some kind of bug?
--Dennis
^ permalink raw reply
* [PATCH 2/2] recv_sideband: Do not use ANSI escape sequence on dumb terminals.
From: Johannes Sixt @ 2008-01-08 16:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
From: Johannes Sixt <johannes.sixt@telecom.at>
The "clear to end of line" sequence is used to nicely output the progress
indicator without leaving garbage on the terminal. However, this works
only on ANSI capable terminals. We use the same check as in color.c to
find out whether the terminal supports this feature and use a workaround
(a few spaces in a row) if it does not.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
sideband.c | 13 ++++++++++---
1 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/sideband.c b/sideband.c
index 513d7b3..0873e69 100644
--- a/sideband.c
+++ b/sideband.c
@@ -13,15 +13,22 @@
*/
#define PREFIX "remote:"
-#define SUFFIX "\033[K" /* change to " " if ANSI sequences don't work */
int recv_sideband(const char *me, int in_stream, int out, int err)
{
unsigned pf = strlen(PREFIX);
- unsigned sf = strlen(SUFFIX);
+ unsigned sf;
char *buf, *save;
+ char *suffix, *term;
+ term = getenv("TERM");
+ if (term && strcmp(term, "dumb"))
+ suffix = "\033[K";
+ else
+ suffix = " ";
+ sf = strlen(suffix);
save = xmalloc(sf);
+
buf = xmalloc(pf + LARGE_PACKET_MAX + sf + 1);
memcpy(buf, PREFIX, pf);
while (1) {
@@ -68,7 +75,7 @@ int recv_sideband(const char *me, int in_stream, int out, int err)
if (brk > pf+1 + 1) {
memcpy(save, buf + brk, sf);
buf[brk + sf - 1] = buf[brk - 1];
- memcpy(buf + brk - 1, SUFFIX, sf);
+ memcpy(buf + brk - 1, suffix, sf);
safe_write(err, buf, brk + sf);
memcpy(buf + brk, save, sf);
} else
--
1.5.4.rc2.815.g2f849-dirty
^ permalink raw reply related
* [PATCH 1/2] sideband.c: Use xmalloc() instead of variable-sized arrays.
From: Johannes Sixt @ 2008-01-08 16:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
From: Johannes Sixt <johannes.sixt@telecom.at>
How come we got along with this not very portable construct for so long?
Probably because the array sizes were computed from the results of
strlen() of string constants. Anyway, a follow-up patch will make the
lengths really non-constant.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
sideband.c | 14 ++++++++++++--
1 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/sideband.c b/sideband.c
index 756bbc2..513d7b3 100644
--- a/sideband.c
+++ b/sideband.c
@@ -19,7 +19,10 @@ int recv_sideband(const char *me, int in_stream, int out, int err)
{
unsigned pf = strlen(PREFIX);
unsigned sf = strlen(SUFFIX);
- char buf[pf + LARGE_PACKET_MAX + sf + 1];
+ char *buf, *save;
+
+ save = xmalloc(sf);
+ buf = xmalloc(pf + LARGE_PACKET_MAX + sf + 1);
memcpy(buf, PREFIX, pf);
while (1) {
int band, len;
@@ -29,6 +32,8 @@ int recv_sideband(const char *me, int in_stream, int out, int err)
if (len < 1) {
len = sprintf(buf, "%s: protocol error: no band designator\n", me);
safe_write(err, buf, len);
+ free(buf);
+ free(save);
return SIDEBAND_PROTOCOL_ERROR;
}
band = buf[pf] & 0xff;
@@ -38,6 +43,8 @@ int recv_sideband(const char *me, int in_stream, int out, int err)
buf[pf] = ' ';
buf[pf+1+len] = '\n';
safe_write(err, buf, pf+1+len+1);
+ free(buf);
+ free(save);
return SIDEBAND_REMOTE_ERROR;
case 2:
buf[pf] = ' ';
@@ -59,7 +66,6 @@ int recv_sideband(const char *me, int in_stream, int out, int err)
* line data actually contains something.
*/
if (brk > pf+1 + 1) {
- char save[sf];
memcpy(save, buf + brk, sf);
buf[brk + sf - 1] = buf[brk - 1];
memcpy(buf + brk - 1, SUFFIX, sf);
@@ -83,9 +89,13 @@ int recv_sideband(const char *me, int in_stream, int out, int err)
"%s: protocol error: bad band #%d\n",
me, band);
safe_write(err, buf, len);
+ free(buf);
+ free(save);
return SIDEBAND_PROTOCOL_ERROR;
}
}
+ free(buf);
+ free(save);
return 0;
}
--
1.5.4.rc2.815.g2f849-dirty
^ permalink raw reply related
* Re: An interaction with ce_match_stat_basic() and autocrlf
From: Linus Torvalds @ 2008-01-08 16:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfxx8tt1z.fsf@gitster.siamese.dyndns.org>
On Tue, 8 Jan 2008, Junio C Hamano wrote:
>
> This is caused partly by the breakage in size_only codepath of
> diff.c::diff_populate_filespec().
Only partially.
The more fundamental behaviour (that of git update-index) is caused by
ie_modified() thinking that when DATA_CHANGED is true, it cannot possibly
need to call "ce_modified_check_fs()":
>From ie_modified():
/* Immediately after read-tree or update-index --cacheinfo,
* the length field is zero. For other cases the ce_size
* should match the SHA1 recorded in the index entry.
*/
if ((changed & DATA_CHANGED) && ce->ce_size != htonl(0))
return changed;
and that DATA_CHANGED comes from ce_match_stat_basic() which notices that
the size has changed.
Similarly, I think that the problem with "diff" not realizing they might
be the same comes from ie_match_stat(), which has a similar problem in not
realizing that DATA_CHANGED could possibly still mean that it's the same.
This patch should fix it, but I suspect we should think hard about that
change to ie_modified(), and see what the performance issues are (ie that
code has tried to avoid doing the more expensive ce_modified_check_fs()
for a reason).
The change to diff.c is similarly interesting. It is logically wrong to
use the worktree_file there (since we have to read the object anyway), but
since "reuse_worktree_file" is also tied into the whole refresh logic, I
think the diff.c change is correct.
I dunno. This is not meant to be applied, it is meant to be thought about.
Linus
---
diff.c | 2 +-
read-cache.c | 2 ++
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/diff.c b/diff.c
index b18c140..9f699b7 100644
--- a/diff.c
+++ b/diff.c
@@ -1512,7 +1512,7 @@ static int reuse_worktree_file(const char *name, const unsigned char *sha1, int
ce = active_cache[pos];
if ((lstat(name, &st) < 0) ||
!S_ISREG(st.st_mode) || /* careful! */
- ce_match_stat(ce, &st, 0) ||
+ ce_modified(ce, &st, 0) ||
hashcmp(sha1, ce->sha1))
return 0;
/* we return 1 only when we can stat, it is a regular file,
diff --git a/read-cache.c b/read-cache.c
index 7db5588..e1fc880 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -253,12 +253,14 @@ int ie_modified(struct index_state *istate,
if (changed & (MODE_CHANGED | TYPE_CHANGED))
return changed;
+#if 0
/* Immediately after read-tree or update-index --cacheinfo,
* the length field is zero. For other cases the ce_size
* should match the SHA1 recorded in the index entry.
*/
if ((changed & DATA_CHANGED) && ce->ce_size != htonl(0))
return changed;
+#endif
changed_fs = ce_modified_check_fs(ce, st);
if (changed_fs)
^ permalink raw reply related
* Re: CRLF problems with Git on Win32
From: Kelvie Wong @ 2008-01-08 15:58 UTC (permalink / raw)
To: Peter Harris; +Cc: Peter Karlsson, git
In-Reply-To: <eaa105840801080507j1b748fy6fdff8b240cf8c33@mail.gmail.com>
On Jan 8, 2008 5:07 AM, Peter Harris <peter@peter.is-a-geek.org> wrote:
> On Jan 8, 2008 5:56 AM, Peter Karlsson <peter@softwolves.pp.se> wrote:
> > Thomas Neumann:
> >
> > > as a user, I expect a SCM to only modify a file when I have
> > > explicitly asked it to do so.
> >
> > As a user, I exepect things to just work. With RCS/CVS/Subversion, it
> > does, because it differentiates between text files (internally encoding
> > NLs with "LF", but I couldn't care less what it uses there) and binary
> > files (which it doesn't change). With git it currently doesn't since it
> > treats everything as binary files.
>
> Actually, Subversion does the Right Thing, and treats everything as a
> binary file until and unless you explicitly set the svn:eol-style
> property on each file that you want it to mangle.
>
> Maybe you set up Subversion auto-props and forgot about it? That would
> be almost (but not really) like setting autocrlf=true in your global
> git config.
>
> Peter Harris
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
I'd actually like a feature like this. On the internal subversion
tree I'm working on (using git-svn), there are quite a bit of files
that have CRLF endings -- we are a cross platform development group.
The solution to this in subversion was that everyone had the same
.subversion/config with a bunch of autoprops set; i.e.:
[auto-props]
*.H = svn:eol-style=native
*.h = svn:eol-style=native
*.CPP = svn:eol-style=native
*.cpp = svn:eol-style=native
and I can't do the same using git-svn. Thankfully emacs detects CRLFs
and adjusts accordingly, and that's my workaround for it, but it would
be nice to have some kind of gitattribute that allows you to set the
autocrlf according to a filter.
--
Kelvie Wong
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Peter Karlsson @ 2008-01-08 15:20 UTC (permalink / raw)
To: Peter Harris; +Cc: git
In-Reply-To: <eaa105840801080507j1b748fy6fdff8b240cf8c33@mail.gmail.com>
Peter Harris:
> Actually, Subversion does the Right Thing, and treats everything as a
> binary file until and unless you explicitly set the svn:eol-style
> property on each file that you want it to mangle.
>
> Maybe you set up Subversion auto-props and forgot about it? That would
> be almost (but not really) like setting autocrlf=true in your global
> git config.
Actually, I've never actively set up a Subversion server myself, nor
created any projects in Subversion (I have checked out some Subversion
repos, though). I started using RCS and CVS, and now I'm migrating at
least parts of that to Git (not all). Since Git is better than CVS in
many ways, I would like it to be better than CVS in this one as well.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: git and unicode
From: Remi Vanicat @ 2008-01-08 15:09 UTC (permalink / raw)
To: Gonzalo Garramuño; +Cc: git
In-Reply-To: <47835A02.80404@advancedsl.com.ar>
Gonzalo Garramuño <ggarra@advancedsl.com.ar> writes:
> Forking a little from the recent CR/LF thread, I was wondering how
> does git deal with unicode files?
>
> Most scripting languages (ruby, python, etc) are now allowing their
> source code to be written in unicode (UTF-8, usually). Will git
> incorrectly categorize those source files as "binary"?
>
>
> --
> Gonzalo Garramuño
> ggarra@advancedsl.com.ar
>
> AMD4400 - ASUS48N-E
> GeForce7300GT
> Xubuntu Gutsy
--
Rémi Vanicat
^ permalink raw reply
* Re: Importing merges when converting repos from SVN to Git (fusing grafts in the Git history)
From: Johannes Sixt @ 2008-01-08 15:13 UTC (permalink / raw)
To: Benoit Sigoure; +Cc: Git Mailing List
In-Reply-To: <744EF0AD-4773-4A35-B772-94621E9ADA10@lrde.epita.fr>
Benoit Sigoure schrieb:
> I'm going to import the repositories with `git-svn' and then I'd like to
> rewrite the entire history to take these merges in account in the Git
> repo, if possible. This will probably help us merging the (former) SVN
> branches in our new Git repo. I know I can simulate a merge with a
> graft and I think it will be fairly easy to write a small script that
> parses the log and generates the corresponding graft file. Now the
> question is: how to make these grafts part of the *real* history so that
> we don't have to depend on the graft file anymore?
>
> I know this issue has already been raised on the ML (the "how to include
> grafts are real merges in the history" thing) but I couldn't find the
> corresponding posts and can't remember the conclusion...
git-filter-branch --tag-name-filter=cat --all
should do it. It rewrites nothing but the parenthood, so you will find
that the rewritten history shares everything with the original history up
to the first merge(s).
You better run this on a "cp -al" copy of the original converted
repository because it *overwrites* the tags.
-- Hannes
^ permalink raw reply
* git config file for sending email using gmail smpt server [was: Cover letter]
From: Paolo Ciarrocchi @ 2008-01-08 15:09 UTC (permalink / raw)
To: Git Mailing List
On Jan 8, 2008 2:13 PM, Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> wrote:
>
> On Jan 8, 2008 2:09 PM, Gustaf Hendeby <hendeby@isy.liu.se> wrote:
> > > This is working fine but since I'm going to push out a queue of patches
> > > it would be nicer to script everything with git-send-email.
BTW, would anybody so kind to post the configuration lines needed for
git-send-email to work with gmail's smtp server?
I guess a lot of people are using it so it would be nice to add a sample
conf file in the wiki.
Thanks.
Ciao,
--
Paolo
http://paolo.ciarrocchi.googlepages.com/
^ permalink raw reply
* Importing merges when converting repos from SVN to Git (fusing grafts in the Git history)
From: Benoit Sigoure @ 2008-01-08 14:48 UTC (permalink / raw)
To: Git Mailing List
Hi list,
I'm in the processing of converting the SVN repos of my company to
Git. We have been using scripts to handle the merge hell with SVN
and these scripts always mentioned what was merged where in the
commit message. The first line is typically: merge -r FROM:TO
https://svn.fake-company.com/svn/project/{trunk,branches/branch-name}
I'm going to import the repositories with `git-svn' and then I'd like
to rewrite the entire history to take these merges in account in the
Git repo, if possible. This will probably help us merging the
(former) SVN branches in our new Git repo. I know I can simulate a
merge with a graft and I think it will be fairly easy to write a
small script that parses the log and generates the corresponding
graft file. Now the question is: how to make these grafts part of
the *real* history so that we don't have to depend on the graft file
anymore?
I know this issue has already been raised on the ML (the "how to
include grafts are real merges in the history" thing) but I couldn't
find the corresponding posts and can't remember the conclusion...
Thanks!
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
^ permalink raw reply
* [PATCH] gitk: fix "Key bindings" message
From: Michele Ballabio @ 2008-01-08 13:37 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
Fix string substitution. Now the "Key bindings" message under the
"Help" menu is ready for translation.
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
---
gitk | 32 ++++++++++++++++----------------
1 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/gitk b/gitk
index 4a923af..871a006 100755
--- a/gitk
+++ b/gitk
@@ -1309,7 +1309,7 @@ proc keys {} {
message $w.m -text [mc "
Gitk key bindings:
-<$M1T-Q> Quit
+<%s-Q> Quit
<Home> Move to first commit
<End> Move to last commit
<Up>, p, i Move up one commit
@@ -1318,12 +1318,12 @@ Gitk key bindings:
<Right>, x, l Go forward in history list
<PageUp> Move up one page in commit list
<PageDown> Move down one page in commit list
-<$M1T-Home> Scroll to top of commit list
-<$M1T-End> Scroll to bottom of commit list
-<$M1T-Up> Scroll commit list up one line
-<$M1T-Down> Scroll commit list down one line
-<$M1T-PageUp> Scroll commit list up one page
-<$M1T-PageDown> Scroll commit list down one page
+<%s-Home> Scroll to top of commit list
+<%s-End> Scroll to bottom of commit list
+<%s-Up> Scroll commit list up one line
+<%s-Down> Scroll commit list down one line
+<%s-PageUp> Scroll commit list up one page
+<%s-PageDown> Scroll commit list down one page
<Shift-Up> Find backwards (upwards, later commits)
<Shift-Down> Find forwards (downwards, earlier commits)
<Delete>, b Scroll diff view up one page
@@ -1331,20 +1331,20 @@ Gitk key bindings:
<Space> Scroll diff view down one page
u Scroll diff view up 18 lines
d Scroll diff view down 18 lines
-<$M1T-F> Find
-<$M1T-G> Move to next find hit
+<%s-F> Find
+<%s-G> Move to next find hit
<Return> Move to next find hit
/ Move to next find hit, or redo find
? Move to previous find hit
f Scroll diff view to next file
-<$M1T-S> Search for next hit in diff view
-<$M1T-R> Search for previous hit in diff view
-<$M1T-KP+> Increase font size
-<$M1T-plus> Increase font size
-<$M1T-KP-> Decrease font size
-<$M1T-minus> Decrease font size
+<%s-S> Search for next hit in diff view
+<%s-R> Search for previous hit in diff view
+<%s-KP+> Increase font size
+<%s-plus> Increase font size
+<%s-KP-> Decrease font size
+<%s-minus> Decrease font size
<F5> Update
-"] \
+" $M1T $M1T $M1T $M1T $M1T $M1T $M1T $M1T $M1T $M1T $M1T $M1T $M1T $M1T $M1T ] \
-justify left -bg white -border 2 -relief groove
pack $w.m -side top -fill both -padx 2 -pady 2
button $w.ok -text [mc "Close"] -command "destroy $w" -default active
--
1.5.3.5
^ permalink raw reply related
* [PATCH 3/3] git.el: Make status refresh faster.
From: Alexandre Julliard @ 2008-01-08 13:49 UTC (permalink / raw)
To: git
Don't set the needs-refresh flag when inserting a new file info, since
ewoc refreshes it upon insert already; this makes a full refresh twice
as fast.
Also make git-fileinfo-prettyprint a little faster by not retrieving
permission values twice.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
contrib/emacs/git.el | 24 +++++++++++++-----------
1 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index 825b1e9..8f39ebe 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -538,10 +538,10 @@ and returns the process output as a string."
('ignored (propertize "Ignored " 'face 'git-ignored-face))
(t "? ")))
-(defun git-file-type-as-string (info)
- "Return a string describing the file type of INFO."
- (let* ((old-type (lsh (or (git-fileinfo->old-perm info) 0) -9))
- (new-type (lsh (or (git-fileinfo->new-perm info) 0) -9))
+(defun git-file-type-as-string (old-perm new-perm)
+ "Return a string describing the file type based on its permissions."
+ (let* ((old-type (lsh (or old-perm 0) -9))
+ (new-type (lsh (or new-perm 0) -9))
(str (case new-type
(?\100 ;; file
(case old-type
@@ -590,12 +590,14 @@ and returns the process output as a string."
(defun git-fileinfo-prettyprint (info)
"Pretty-printer for the git-fileinfo structure."
- (insert (concat " " (if (git-fileinfo->marked info) (propertize "*" 'face 'git-mark-face) " ")
- " " (git-status-code-as-string (git-fileinfo->state info))
- " " (git-permissions-as-string (git-fileinfo->old-perm info) (git-fileinfo->new-perm info))
- " " (git-escape-file-name (git-fileinfo->name info))
- (git-file-type-as-string info)
- (git-rename-as-string info))))
+ (let ((old-perm (git-fileinfo->old-perm info))
+ (new-perm (git-fileinfo->new-perm info)))
+ (insert (concat " " (if (git-fileinfo->marked info) (propertize "*" 'face 'git-mark-face) " ")
+ " " (git-status-code-as-string (git-fileinfo->state info))
+ " " (git-permissions-as-string old-perm new-perm)
+ " " (git-escape-file-name (git-fileinfo->name info))
+ (git-file-type-as-string old-perm new-perm)
+ (git-rename-as-string info)))))
(defun git-insert-info-list (status infolist)
"Insert a list of file infos in the status buffer, replacing existing ones if any."
@@ -606,7 +608,6 @@ and returns the process output as a string."
(let ((info (pop infolist))
(node (ewoc-nth status 0)))
(while info
- (setf (git-fileinfo->needs-refresh info) t)
(cond ((not node)
(setq node (ewoc-enter-last status info))
(setq info (pop infolist)))
@@ -617,6 +618,7 @@ and returns the process output as a string."
(git-fileinfo->name info))
;; preserve the marked flag
(setf (git-fileinfo->marked info) (git-fileinfo->marked (ewoc-data node)))
+ (setf (git-fileinfo->needs-refresh info) t)
(setf (ewoc-data node) info)
(setq info (pop infolist)))
(t
--
1.5.4.rc2.71.ge10a9
--
Alexandre Julliard
julliard@winehq.org
^ 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