* Re: [BugReport] git tag -a / git show
From: Jeff King @ 2012-02-24 21:44 UTC (permalink / raw)
To: Romain Vimont (®om); +Cc: Zbigniew Jędrzejewski-Szmek, git
In-Reply-To: <1330119763.2727.10.camel@rom-laptop>
On Fri, Feb 24, 2012 at 10:42:43PM +0100, Romain Vimont (®om) wrote:
> Thank you, I didn't know this '^' thing ;-)
You might find the "Specifying Revisions" section of "git help
rev-parse" enlightening. :)
-Peff
^ permalink raw reply
* Re: FW: question about merge in 1.7.10
From: Junio C Hamano @ 2012-02-24 21:55 UTC (permalink / raw)
To: Marlene Cote; +Cc: Zbigniew Jędrzejewski-Szmek, git@vger.kernel.org
In-Reply-To: <1F026B57884A5841B330471696849DE911450B9B@MBX021-W4-CA-5.exch021.domain.local>
Marlene Cote <Marlene_Cote@affirmednetworks.com> writes:
> Sorry. You are correct. You said it would open an editor session.
Whew. I was really worried that we may be sending a wrong message and
making users needlessly afraid of changes.
Thanks for a prompt response.
^ permalink raw reply
* [PATCHv2 1/3] teach convert_to_git a "dry run" mode
From: Jeff King @ 2012-02-24 22:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20120224211913.GA30942@sigill.intra.peff.net>
Some callers may want to know whether convert_to_git will
actually do anything before performing the conversion
itself (e.g., to decide whether to stream or handle blobs
in-core). This patch lets callers specify the dry run mode
by passing a NULL destination buffer. The return value,
instead of indicating whether conversion happened, will
indicate whether conversion would occur.
For readability, we also include a wrapper function which
makes it more obvious we are not actually performing the
conversion.
Signed-off-by: Jeff King <peff@peff.net>
---
This splits the 1/2 from the first series into two patches. This part
handles the dry-run aspect. Unlike the previous version, it uses a NULL
destination, rather than a NULL source to indicate the dry-run mode.
Which just makes more sense, and means that the "don't bother doing
source analysis" bit is split off.
No callers introduced in this series actually want to do a dry-run with
a non-NULL source buffer, so that feature is of dubious value. But it's
not any extra code to do it this way, and the resulting commits are much
easier to read, I think.
convert.c | 17 +++++++++++++++--
convert.h | 5 +++++
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/convert.c b/convert.c
index 12868ed..65fa9d5 100644
--- a/convert.c
+++ b/convert.c
@@ -231,6 +231,13 @@ static int crlf_to_git(const char *path, const char *src, size_t len,
if (!stats.cr)
return 0;
+ /*
+ * At this point all of our source analysis is done, and we are sure we
+ * would convert. If we are in dry-run mode, we can give an answer.
+ */
+ if (!buf)
+ return 1;
+
/* only grow if not in place */
if (strbuf_avail(buf) + buf->len < len)
strbuf_grow(buf, len - buf->len);
@@ -391,6 +398,9 @@ static int apply_filter(const char *path, const char *src, size_t len,
if (!cmd)
return 0;
+ if (!dst)
+ return 1;
+
memset(&async, 0, sizeof(async));
async.proc = filter_buffer;
async.data = ¶ms;
@@ -525,6 +535,9 @@ static int ident_to_git(const char *path, const char *src, size_t len,
if (!ident || !count_ident(src, len))
return 0;
+ if (!buf)
+ return 1;
+
/* only grow if not in place */
if (strbuf_avail(buf) + buf->len < len)
strbuf_grow(buf, len - buf->len);
@@ -754,13 +767,13 @@ int convert_to_git(const char *path, const char *src, size_t len,
filter = ca.drv->clean;
ret |= apply_filter(path, src, len, dst, filter);
- if (ret) {
+ if (ret && dst) {
src = dst->buf;
len = dst->len;
}
ca.crlf_action = input_crlf_action(ca.crlf_action, ca.eol_attr);
ret |= crlf_to_git(path, src, len, dst, ca.crlf_action, checksafe);
- if (ret) {
+ if (ret && dst) {
src = dst->buf;
len = dst->len;
}
diff --git a/convert.h b/convert.h
index d799a16..ec5fd69 100644
--- a/convert.h
+++ b/convert.h
@@ -40,6 +40,11 @@ extern int convert_to_working_tree(const char *path, const char *src,
size_t len, struct strbuf *dst);
extern int renormalize_buffer(const char *path, const char *src, size_t len,
struct strbuf *dst);
+static inline int would_convert_to_git(const char *path, const char *src,
+ size_t len, enum safe_crlf checksafe)
+{
+ return convert_to_git(path, src, len, NULL, checksafe);
+}
/*****************************************************************
*
--
1.7.9.11.gca600
^ permalink raw reply related
* [PATCHv2 2/3] teach dry-run convert_to_git not to require a src buffer
From: Jeff King @ 2012-02-24 22:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20120224211913.GA30942@sigill.intra.peff.net>
When we call convert_to_git in dry-run mode, it may still
want to look at the source buffer, because some CRLF
conversion modes depend on analyzing the source to determine
whether it is in fact convertible CRLF text.
However, the main motivation for convert_to_git's dry-run
mode is that we would decide which method to use to acquire
the blob's data (streaming versus in-core). Requiring this
source analysis creates a chicken-and-egg problem. We are
better off simply guessing that anything we can't analyze
will end up needing conversion.
This patch lets a caller specify a NULL src buffer when
using dry-run mode (and only dry-run mode). A non-zero
return value goes from "we would convert" to "we might
convert"; a zero return value remains "we would definitely
not convert".
Signed-off-by: Jeff King <peff@peff.net>
---
And this is the second half of v1's patch 1/2.
By splitting this off, I think it makes it much more obvious if we want
to re-visit the pessimism later (e.g., to optimistically assume that
missing src buffers should be assumed to be binary if they are large).
convert.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/convert.c b/convert.c
index 65fa9d5..aa7f72d 100644
--- a/convert.c
+++ b/convert.c
@@ -195,9 +195,17 @@ static int crlf_to_git(const char *path, const char *src, size_t len,
char *dst;
if (crlf_action == CRLF_BINARY ||
- (crlf_action == CRLF_GUESS && auto_crlf == AUTO_CRLF_FALSE) || !len)
+ (crlf_action == CRLF_GUESS && auto_crlf == AUTO_CRLF_FALSE) ||
+ (src && !len))
return 0;
+ /*
+ * If we are doing a dry-run and have no source buffer, there is
+ * nothing to analyze; we must assume we would convert.
+ */
+ if (!buf && !src)
+ return 1;
+
gather_stats(src, len, &stats);
if (crlf_action == CRLF_AUTO || crlf_action == CRLF_GUESS) {
@@ -532,7 +540,7 @@ static int ident_to_git(const char *path, const char *src, size_t len,
{
char *dst, *dollar;
- if (!ident || !count_ident(src, len))
+ if (!ident || (src && !count_ident(src, len)))
return 0;
if (!buf)
--
1.7.9.11.gca600
^ permalink raw reply related
* Re: git compiled on same distro, different versions
From: Junio C Hamano @ 2012-02-24 22:08 UTC (permalink / raw)
To: Neal Kreitzinger; +Cc: git
In-Reply-To: <ji8u2f$gml$1@dough.gmane.org>
"Neal Kreitzinger" <neal@rsss.com> writes:
> If I only test a new git version (compiled from git.git source) on RHEL6
> before I put it on the RHEL5 box is that sufficient for validation? Should
> git behave the same on both? If not, why?
I somehow find this a strange question to ask to Git people; you may have
better luck asking the question to RHEL folks.
Having said that, one of the reasons the result may not work, off the top
of my head, is that the binary you compiled would expect to link with the
system libraries that are available on your RHEL6 installation. If your
RHEL5 installation does not have a matching and ABI compatible library to
any of them, the resulting binary would obviously not work there.
^ permalink raw reply
* [PATCHv2 3/3] do not stream large files to pack when filters are in use
From: Jeff King @ 2012-02-24 22:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20120224211913.GA30942@sigill.intra.peff.net>
Because git's object format requires us to specify the
number of bytes in the object in its header, we must know
the size before streaming a blob into the object database.
This is not a problem when adding a regular file, as we can
get the size from stat(). However, when filters are in use
(such as autocrlf, or the ident, filter, or eol
gitattributes), we have no idea what the ultimate size will
be.
The current code just punts on the whole issue and ignores
filter configuration entirely for files larger than
core.bigfilethreshold. This can generate confusing results
if you use filters for large binary files, as the filter
will suddenly stop working as the file goes over a certain
size. Rather than try to handle unknown input sizes with
streaming, this patch just turns off the streaming
optimization when filters are in use.
This has a slight performance regression in a very specific
case: if you have autocrlf on, but no gitattributes, a large
binary file will avoid the streaming code path because we
don't know beforehand whether it will need conversion or
not. But if you are handling large binary files, you should
be marking them as such via attributes (or at least not
using autocrlf, and instead marking your text files as
such). And the flip side is that if you have a large
_non_-binary file, there is a correctness improvement;
before we did not apply the conversion at all.
The first half of the new t1051 script covers these failures
on input. The second half tests the matching output code
paths. These already work correctly, and do not need any
adjustment.
Signed-off-by: Jeff King <peff@peff.net>
---
This patches patch 2/2 from v1 of the series. The changes are:
- use the new would_convert_to_git macro
- only check filters if we have a path, which handles "hash-object
--stdin". It actually seems to me that one could have autocrlf on,
and would expect hash-object to do automatic conversion even without
a path with which to look up attributes. But this is the same test
that index_mem uses, so we are matching the behavior there.
- update the comment above index_stream. I have no idea how I
previously missed this giant comment explaining the exact situation
I was testing.
sha1_file.c | 14 ++++---
t/t1051-large-conversion.sh | 86 +++++++++++++++++++++++++++++++++++++++++++
2 files changed, 95 insertions(+), 5 deletions(-)
create mode 100755 t/t1051-large-conversion.sh
diff --git a/sha1_file.c b/sha1_file.c
index f9f8d5e..4f06a0e 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -2700,10 +2700,13 @@ static int index_core(unsigned char *sha1, int fd, size_t size,
* This also bypasses the usual "convert-to-git" dance, and that is on
* purpose. We could write a streaming version of the converting
* functions and insert that before feeding the data to fast-import
- * (or equivalent in-core API described above), but the primary
- * motivation for trying to stream from the working tree file and to
- * avoid mmaping it in core is to deal with large binary blobs, and
- * by definition they do _not_ want to get any conversion.
+ * (or equivalent in-core API described above). However, that is
+ * somewhat complicated, as we do not know the size of the filter
+ * result, which we need to know beforehand when writing a git object.
+ * Since the primary motivation for trying to stream from the working
+ * tree file and to avoid mmaping it in core is to deal with large
+ * binary blobs, they generally do not want to get any conversion, and
+ * callers should avoid this code path when filters are requested.
*/
static int index_stream(unsigned char *sha1, int fd, size_t size,
enum object_type type, const char *path,
@@ -2720,7 +2723,8 @@ int index_fd(unsigned char *sha1, int fd, struct stat *st,
if (!S_ISREG(st->st_mode))
ret = index_pipe(sha1, fd, type, path, flags);
- else if (size <= big_file_threshold || type != OBJ_BLOB)
+ else if (size <= big_file_threshold || type != OBJ_BLOB ||
+ (path && would_convert_to_git(path, NULL, 0, 0)))
ret = index_core(sha1, fd, size, type, path, flags);
else
ret = index_stream(sha1, fd, size, type, path, flags);
diff --git a/t/t1051-large-conversion.sh b/t/t1051-large-conversion.sh
new file mode 100755
index 0000000..8b7640b
--- /dev/null
+++ b/t/t1051-large-conversion.sh
@@ -0,0 +1,86 @@
+#!/bin/sh
+
+test_description='test conversion filters on large files'
+. ./test-lib.sh
+
+set_attr() {
+ test_when_finished 'rm -f .gitattributes' &&
+ echo "* $*" >.gitattributes
+}
+
+check_input() {
+ git read-tree --empty &&
+ git add small large &&
+ git cat-file blob :small >small.index &&
+ git cat-file blob :large | head -n 1 >large.index &&
+ test_cmp small.index large.index
+}
+
+check_output() {
+ rm -f small large &&
+ git checkout small large &&
+ head -n 1 large >large.head &&
+ test_cmp small large.head
+}
+
+test_expect_success 'setup input tests' '
+ printf "\$Id: foo\$\\r\\n" >small &&
+ cat small small >large &&
+ git config core.bigfilethreshold 20 &&
+ git config filter.test.clean "sed s/.*/CLEAN/"
+'
+
+test_expect_success 'autocrlf=true converts on input' '
+ test_config core.autocrlf true &&
+ check_input
+'
+
+test_expect_success 'eol=crlf converts on input' '
+ set_attr eol=crlf &&
+ check_input
+'
+
+test_expect_success 'ident converts on input' '
+ set_attr ident &&
+ check_input
+'
+
+test_expect_success 'user-defined filters convert on input' '
+ set_attr filter=test &&
+ check_input
+'
+
+test_expect_success 'setup output tests' '
+ echo "\$Id\$" >small &&
+ cat small small >large &&
+ git add small large &&
+ git config core.bigfilethreshold 7 &&
+ git config filter.test.smudge "sed s/.*/SMUDGE/"
+'
+
+test_expect_success 'autocrlf=true converts on output' '
+ test_config core.autocrlf true &&
+ check_output
+'
+
+test_expect_success 'eol=crlf converts on output' '
+ set_attr eol=crlf &&
+ check_output
+'
+
+test_expect_success 'user-defined filters convert on output' '
+ set_attr filter=test &&
+ check_output
+'
+
+test_expect_success 'ident converts on output' '
+ set_attr ident &&
+ rm -f small large &&
+ git checkout small large &&
+ sed -n "s/Id: .*/Id: SHA/p" <small >small.clean &&
+ head -n 1 large >large.head &&
+ sed -n "s/Id: .*/Id: SHA/p" <large.head >large.clean &&
+ test_cmp small.clean large.clean
+'
+
+test_done
--
1.7.9.11.gca600
^ permalink raw reply related
* Re: git log -z doesn't separate commits with NULs
From: Jakub Narebski @ 2012-02-24 22:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Nikolaj Shurkaev, git
In-Reply-To: <7vk43cx7c2.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > True. That is also a slightly dangerous thing to do, though, because you
> > are omitting full patches in the middle that touch the same paths as the
> > patches you include....
> > ... So
> > perhaps we are better off to refer the user to git-log(1), say that
> > commit limiting options in general would work, but be careful with
> > sending a partial result.
>
> You seem to have spelled out everything I originally wrote in my reply
> that I later deleted before sending it out, and I think the reason that
> brought you to the three-line conclusion is the same one that made me I
> delete them ;-).
>
> Using a partial patch essentially has the same risk as cherry-picking a
> commit into different context, and it is a more generic issue that this
> particular manual page should not waste tons of space to teach readers
> about. I think "Be careful and clueful" is sufficient and the best we can
> do without writing a textbook on distributed software development
> disciplines.
Perhaps git-format-patch should mention that it was created with
path-limited patch in some email pseudo-header like X-Pathspec:
or something, don't you think?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: git log -z doesn't separate commits with NULs
From: Junio C Hamano @ 2012-02-24 22:27 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Jeff King, Nikolaj Shurkaev, git
In-Reply-To: <201202242311.04787.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Perhaps git-format-patch should mention that it was created with
> path-limited patch in some email pseudo-header like X-Pathspec:
> or something, don't you think?
What kind of workflow are you assuming, and who would benefit from such a
header under that assumption?
It obviously would not help the person who is running format-patch, as he
is very well aware that he is giving a pathspec when he runs the command.
If the result is used privately to prepare a starting point of possibly
unrelated work, it does not matter.
If you are assuming a workflow that involves a public review of mailed
patches, it is very likely that such a header will be lost unless you are
using git-send-email, as we strongly discourage copying and pasting the
entire thing in the message body. Anybody sitting on the receiving end
worth her salt would judge the submission by looking at the log message,
diffstat and the patch, and the sender having used pathspec to format the
patch would not be a reason for rejection at all---the quality of the
submission is.
So offhand, I do not know under what workflow such an extra header would
benefit people in what position in the workflow.
^ permalink raw reply
* Re: [PATCH 2/2] do not stream large files to pack when filters are in use
From: Junio C Hamano @ 2012-02-24 22:42 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20120224211913.GA30942@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I'll post the fixed series in a minute (with this fix, and the improved
> convert_to_git wrapper).
Thanks.
The exclusion of path==NULL case was something I didn't think much about,
but I think your solution is the right one.
^ permalink raw reply
* Re: [Not A BugReport] git tag -a / git show
From: Andreas Schwab @ 2012-02-24 23:14 UTC (permalink / raw)
To: Romain Vimont (®om); +Cc: Junio C Hamano, git
In-Reply-To: <1330113528.2727.5.camel@rom-laptop>
Romain Vimont "(®om)" <rom@rom1v.com> writes:
> To what other type of object can you apply a tag ?
Any. Take a look at the junio-gpg-pub tag in git's repository, or the
v2.6.11-tree tag in Linus's kernel repository.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* [PATCH] Makefile: add thread-utils.h to LIB_H
From: Dmitry V. Levin @ 2012-02-24 23:42 UTC (permalink / raw)
To: git; +Cc: gitster
Starting with commit v1.7.8-165-g0579f91, grep.h includes
thread-utils.h, so the latter has to be added to LIB_H.
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
---
Makefile | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index 99a7a2b..e4f8e0e 100644
--- a/Makefile
+++ b/Makefile
@@ -615,6 +615,7 @@ LIB_H += streaming.h
LIB_H += string-list.h
LIB_H += submodule.h
LIB_H += tag.h
+LIB_H += thread-utils.h
LIB_H += transport.h
LIB_H += tree.h
LIB_H += tree-walk.h
--
ldv
^ permalink raw reply related
* Re: git-subtree Ready #2
From: Avery Pennarun @ 2012-02-24 23:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, David A. Greene, git
In-Reply-To: <7vobsox84l.fsf@alter.siamese.dyndns.org>
On Fri, Feb 24, 2012 at 3:56 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Avery Pennarun <apenwarr@gmail.com> writes:
>> Overall I agree that there's little benefit in preserving the history,
>> at least as far as I can see, *except* that some code changes were
>> submitted by people other than me and squashing those changes might
>> conceivably cause licensing confusion down the road.
>
> That is a good point, and it sounds like a good enough justification to
> merge with history, at least for me.
Should we filter-branch or rebase the history first, or just leave it as is?
Like I said, since I don't expect there to be any more back-and-forth
development, rebasing should be pretty harmless.
Avery
^ permalink raw reply
* Re: git compiled on same distro, different versions
From: Neal Kreitzinger @ 2012-02-25 0:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Neal Kreitzinger, git
In-Reply-To: <7vboonhoko.fsf@alter.siamese.dyndns.org>
On 2/24/2012 4:08 PM, Junio C Hamano wrote:
> "Neal Kreitzinger"<neal@rsss.com> writes:
>
>> If I only test a new git version (compiled from git.git source) on RHEL6
>> before I put it on the RHEL5 box is that sufficient for validation? Should
>> git behave the same on both? If not, why?
>
> I somehow find this a strange question to ask to Git people; you may have
> better luck asking the question to RHEL folks.
>
> Having said that, one of the reasons the result may not work, off the top
> of my head, is that the binary you compiled would expect to link with the
> system libraries that are available on your RHEL6 installation. If your
> RHEL5 installation does not have a matching and ABI compatible library to
> any of them, the resulting binary would obviously not work there.
>
"high-level" question:
If I compile git 1.7.9.2 (from git.git source) on RHEL6 test-box and
test it and conclude that it "works right" is that sufficient for me to
then go ahead and compile git 1.7.9.2 on RHEL5 real-box and
expect/assume that it will also "work right"? IOW, will they produce
the same results? Because if not then I have just potentially broken
the real-box.
"low-level" question:
I suspect git calls linux commands alot. Git has "plumbing" commands
that are not supposed to "break" scripts. Does linux also have
"plumbing" commands that are not supposed to "break" scripts? Does git
only use linux "plumbing" commands? Because if git commands uses linux
"porcelain" then the linux "porcelain" change could cause git to change
(not necessarily "break"). Maybe git-porcelain only uses
linux-porcelain, and git-plumbing only uses linux-plumbing.
Definitely thanks in advance for any replies!
v/r,
neal
^ permalink raw reply
* Re: Announcing nntpgit
From: Andreas Schwab @ 2012-02-25 0:58 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: git
In-Reply-To: <20120224133942.49a7a420@dt>
How about generating an RSS/ATOM feed, that is converted to nntp through
gwene? :-)
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH 2/2] index-pack: reduce memory usage when the pack has large blobs
From: Nguyen Thai Ngoc Duy @ 2012-02-25 1:49 UTC (permalink / raw)
To: Ian Kumlien; +Cc: git
In-Reply-To: <20120224161613.GH9526@pomac.netswarm.net>
2012/2/24 Ian Kumlien <pomac@vapor.com>:
> Writing objects: 100% (1425/1425), 56.06 MiB | 4.62 MiB/s, done.
> Total 1425 (delta 790), reused 1425 (delta 790)
> fatal: Out of memory, malloc failed (tried to allocate 3310214315 bytes)
> fatal: Out of memory, malloc failed (tried to allocate 3310214315 bytes)
> fatal: Out of memory, malloc failed (tried to allocate 3310214315 bytes)
> fatal: Out of memory, malloc failed (tried to allocate 3310214315 bytes)
> To ../test_data/
> ! [remote rejected] master -> master (missing necessary objects)
> ! [remote rejected] origin/HEAD -> origin/HEAD (missing necessary objects)
> ! [remote rejected] origin/master -> origin/master (missing necessary objects)
> error: failed to push some refs to '../test_data/'
>
> So there are additional code paths to look at... =(
I can't say where that came from. Does this help? (Space damaged, may
need manual application)
-- 8< --
diff --git a/builtin/rev-list.c b/builtin/rev-list.c
index 264e3ae..6dc46eb 100644
--- a/builtin/rev-list.c
+++ b/builtin/rev-list.c
@@ -183,7 +183,8 @@ static void show_object(struct object *obj,
struct rev_list_info *info = cb_data;
finish_object(obj, path, component, cb_data);
- if (info->revs->verify_objects && !obj->parsed && obj->type !=
OBJ_COMMIT)
+ if (info->revs->verify_objects && !obj->parsed &&
+ obj->type != OBJ_COMMIT && obj->type != OBJ_BLOB)
parse_object(obj->sha1);
show_object_with_name(stdout, obj, path, component);
}
-- 8< --
If not, you might need to apply this to generate coredump, then look
and see where that failed malloc comes from
-- 8< --
diff --git a/wrapper.c b/wrapper.c
index 85f09df..03f423e 100644
--- a/wrapper.c
+++ b/wrapper.c
@@ -40,9 +40,11 @@ void *xmalloc(size_t size)
ret = malloc(size);
if (!ret && !size)
ret = malloc(1);
- if (!ret)
+ if (!ret) {
+ *(char*)0 = 1;
die("Out of memory, malloc failed (tried to
allocate %lu bytes)",
(unsigned long)size);
+ }
}
#ifdef XMALLOC_POISON
memset(ret, 0xA5, size);
-- 8< --
--
Duy
^ permalink raw reply related
* Re: git-subtree Ready #2
From: David A. Greene @ 2012-02-25 5:00 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Junio C Hamano, Jeff King, git
In-Reply-To: <CAHqTa-1fbi5W7R2fLu3bp7Yuv_ZB9nxhgjHkLGuU8-V4016+JA@mail.gmail.com>
Avery Pennarun <apenwarr@gmail.com> writes:
> On Fri, Feb 24, 2012 at 3:56 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Avery Pennarun <apenwarr@gmail.com> writes:
>>> Overall I agree that there's little benefit in preserving the history,
>>> at least as far as I can see, *except* that some code changes were
>>> submitted by people other than me and squashing those changes might
>>> conceivably cause licensing confusion down the road.
>>
>> That is a good point, and it sounds like a good enough justification to
>> merge with history, at least for me.
>
> Should we filter-branch or rebase the history first, or just leave it as is?
>
> Like I said, since I don't expect there to be any more back-and-forth
> development, rebasing should be pretty harmless.
Catching up on e-mail. :)
I'm happy to do either (rebase or filter-branch). Just let me know.
I'm about the send the test-lib.sh patch separately as it's a prereq for
putting git-subtrees tests in contrib and I think it's generally useful
anyway.
-Dave
^ permalink raw reply
* send-email SMTP/TLS Debugging
From: David A. Greene @ 2012-02-25 5:54 UTC (permalink / raw)
To: git
Is there some way to turn on TLS authentication debugging using
git-send-mail? I'm trying to send a patch but git (or the mail server,
I suppose) keeps telling me I have "Incorrect authentication data."
I've checked the settings in .git/config multiple times and they look
correct. How can I debug this further?
Thanks!
-Dave
^ permalink raw reply
* [PATCH] pack-objects: Fix compilation with NO_PTHREDS
From: Michał Kiedrowicz @ 2012-02-25 8:16 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy, Michał Kiedrowicz
It looks like commit 99fb6e04 (pack-objects: convert to use
parse_options(), 2012-02-01) moved the #ifdef NO_PTHREDS around but
hasn't noticed that the 'arg' variable no longer is available.
Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com>
---
builtin/pack-objects.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index db09cf7..71af246 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -2449,7 +2449,7 @@ int cmd_pack_objects(int argc, const char **argv, const char *prefix)
die("bad pack compression level %d", pack_compression_level);
#ifdef NO_PTHREADS
if (delta_search_threads != 1)
- warning("no threads support, ignoring %s", arg);
+ warning("no threads support, ignoring --threads");
#endif
if (!pack_to_stdout && !pack_size_limit)
pack_size_limit = pack_size_limit_cfg;
--
1.7.8.4
^ permalink raw reply related
* Re: [PATCH 2/8] gitweb: Use print_diff_chunk() for both side-by-side and inline diffs
From: Michał Kiedrowicz @ 2012-02-25 9:00 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3k43ttlh9.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> wrote:
> BTW. I didn't examine the final code, but what happens for binary
> diffs that git supports? Is it handled outside print_diff_chunk()?
gitweb doesn't produce binary diffs at all except for "?a=patch", but
it isn't HTML'ed. So I don't think there anything I can do with it.
^ permalink raw reply
* Re: git-subtree Ready #2
From: Junio C Hamano @ 2012-02-25 9:00 UTC (permalink / raw)
To: David A. Greene; +Cc: Avery Pennarun, Jeff King, git
In-Reply-To: <87hayfv75y.fsf@smith.obbligato.org>
greened@obbligato.org (David A. Greene) writes:
> Avery Pennarun <apenwarr@gmail.com> writes:
>
>> Should we filter-branch or rebase the history first, or just leave it as is?
>>
>> Like I said, since I don't expect there to be any more back-and-forth
>> development, rebasing should be pretty harmless.
>
> Catching up on e-mail. :)
>
> I'm happy to do either (rebase or filter-branch). Just let me know.
I would understand Avery's "should we filter-branch/rebase, or is it OK
as-is?", but I do not understand what you mean by "either rebase or
filter-branch is fine".
> I'm about the send the test-lib.sh patch separately...
Thanks, this I understand and should not be a part of git-subtree topic.
^ permalink raw reply
* Re: [PATCH] pack-objects: Fix compilation with NO_PTHREDS
From: Junio C Hamano @ 2012-02-25 9:02 UTC (permalink / raw)
To: Michał Kiedrowicz; +Cc: git, Nguyễn Thái Ngọc Duy
In-Reply-To: <1330157769-7884-1-git-send-email-michal.kiedrowicz@gmail.com>
Michał Kiedrowicz <michal.kiedrowicz@gmail.com> writes:
> It looks like commit 99fb6e04 (pack-objects: convert to use
> parse_options(), 2012-02-01) moved the #ifdef NO_PTHREDS around but
> hasn't noticed that the 'arg' variable no longer is available.
>
> Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com>
Thanks. Nguyễn, a quick double-check and an Ack?
> ---
> builtin/pack-objects.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
> index db09cf7..71af246 100644
> --- a/builtin/pack-objects.c
> +++ b/builtin/pack-objects.c
> @@ -2449,7 +2449,7 @@ int cmd_pack_objects(int argc, const char **argv, const char *prefix)
> die("bad pack compression level %d", pack_compression_level);
> #ifdef NO_PTHREADS
> if (delta_search_threads != 1)
> - warning("no threads support, ignoring %s", arg);
> + warning("no threads support, ignoring --threads");
> #endif
> if (!pack_to_stdout && !pack_size_limit)
> pack_size_limit = pack_size_limit_cfg;
^ permalink raw reply
* [PATCH] grep -P: Fix matching ^ and $
From: Michał Kiedrowicz @ 2012-02-25 9:24 UTC (permalink / raw)
To: git; +Cc: Zbigniew Jędrzejewski-Szmek, Michał Kiedrowicz
When `git-grep` is run with -P/--perl-regexp, it doesn't match ^ and $ at
the beginning/end of the line. This is because PCRE normally matches ^
and $ at the beginning/end of the whole text, not for each line, and git-grep
firstly passes a large chunk of text (possibly containing many lines) to
pcre_exec() before it splits the text into lines. This makes `git-grep -P`
behave differently from `git-grep -E` and also from `grep -P` and `pcregrep`:
$ cat file
a
b
$ git --no-pager grep --no-index -P '^ ' file
$ git --no-pager grep --no-index -E '^ ' file
file: b
$ grep -c -P '^ ' file
b
$ pcregrep -c '^ ' file
b
Reported-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com>
---
grep.c | 2 +-
t/t7810-grep.sh | 23 +++++++++++++++++++++++
2 files changed, 24 insertions(+), 1 deletions(-)
diff --git a/grep.c b/grep.c
index 3821400..f492d26 100644
--- a/grep.c
+++ b/grep.c
@@ -79,7 +79,7 @@ static void compile_pcre_regexp(struct grep_pat *p, const struct grep_opt *opt)
{
const char *error;
int erroffset;
- int options = 0;
+ int options = PCRE_MULTILINE;
if (opt->ignore_case)
options |= PCRE_CASELESS;
diff --git a/t/t7810-grep.sh b/t/t7810-grep.sh
index 75f4716..dd6e6d5 100755
--- a/t/t7810-grep.sh
+++ b/t/t7810-grep.sh
@@ -47,6 +47,13 @@ test_expect_success setup '
echo vvv >t/v &&
mkdir t/a &&
echo vvv >t/a/v &&
+ {
+ echo "line without leading space1"
+ echo " line with leading space1"
+ echo " line with leading space2"
+ echo " line with leading space3"
+ echo "line without leading space2"
+ } >space &&
git add . &&
test_tick &&
git commit -m initial
@@ -893,4 +900,20 @@ test_expect_success 'mimic ack-grep --group' '
test_cmp expected actual
'
+cat >expected <<EOF
+space: line with leading space1
+space: line with leading space2
+space: line with leading space3
+EOF
+
+test_expect_success 'grep -E "^ "' '
+ git grep -E "^ " space >actual &&
+ test_cmp expected actual
+'
+
+test_expect_success "grep -P '^ '" '
+ git grep -P "^ " space >actual &&
+ test_cmp expected actual
+'
+
test_done
--
1.7.8.4
^ permalink raw reply related
* Re: [PATCH] pack-objects: Fix compilation with NO_PTHREDS
From: Nguyen Thai Ngoc Duy @ 2012-02-25 9:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michał Kiedrowicz, git
In-Reply-To: <7vty2fffpp.fsf@alter.siamese.dyndns.org>
2012/2/25 Junio C Hamano <gitster@pobox.com>:
> Michał Kiedrowicz <michal.kiedrowicz@gmail.com> writes:
>
>> It looks like commit 99fb6e04 (pack-objects: convert to use
>> parse_options(), 2012-02-01) moved the #ifdef NO_PTHREDS around but
>> hasn't noticed that the 'arg' variable no longer is available.
>>
>> Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com>
>
> Thanks. Nguyễn, a quick double-check and an Ack?
Tested and acked.
--
Duy
^ permalink raw reply
* Re: Improving merge messages for 1.7.10 and making "pull" easier
From: Ævar Arnfjörð Bjarmason @ 2012-02-25 9:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Thomas Rast, Linus Torvalds
In-Reply-To: <7vy5rsyq9w.fsf@alter.siamese.dyndns.org>
On Fri, Feb 24, 2012 at 20:39, Junio C Hamano <gitster@pobox.com> wrote:
> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
>> Firstly (and as a more general thing) I think we should add a mention
>> of "git merge --abort" to the message, just saving an empty file is
>> not sufficient to fully clear the merge state:
>
> Makes sense, but the new message does not quite parse.
>
>>> "Lines starting with '#' will be ignored, and an empty message followed\n"
>>> "by 'git merge --abort' the merge.\n");
>
> Perhaps s/the merge/aborts &/ or something.
Yeah, it needs better wording.
>> Additionally, perhaps it would be a good idea to:
>>
>> * Detect if the user didn't run this explicitly but implicitly from a
>> "git pull". We could pass some env var along or another option
>> (e.g. --internal-from-porcelain=pull) and add this:
>>
>> You've merged implicitly via a "git pull", if you're just
>> updating some local work in progress to keep up with upstream
>> you may want to use "git pull --rebase" instead (or set the
>> pull.rebase configuration variable) to rebase instead of merge.
>
> Won't this message be given to _all_ users of "git pull", even to the ones
> who already have decided correctly that "pull" is the right thing in their
> situation? With a new advice.* settings to squelch it, perhaps.
Yeah, I'm not sure it's a good idea to add it given that.
>> * Explicitly check if we're merging an updated upstream into the
>> work-in-progress topic,...
>
> It might be a worthy goal, but how would we detect it? A few examples
> that we shouldn't give an unhelpful advice with a false positive are
> merges into:
>
> - The 'master' branch used by people who use Git as an improved CVS, when
> they do an equivalent of 'cvs update'. Merging the updated 'master'
> from the central repository into their 'master' that contains their
> work that may or may not be ready to be pushed back is how their
> project works. It is a norm for them to make such a merge, even though
> more experienced people may prefer to see the history of their project
> kept cleaner by suggesting their project participants to use their own
> topic branches.
>
> - Integration branches like my 'next', when it gets a merge from
> 'master'. This is "merging an updated upstream" but is done in order to
> keep the promise that 'next' would contain everything in 'master'.
>
> And what alternative would we offer? If we were to suggest "rebase", we
> would also need to consider the topic of the other a-couple-of-days-old
> thread to detect which part of history is no longer subject to rewrite.
>
>> I work with a lot of inexperienced git users and a lot of them are
>> going to be very confused by this change. I still think it's a good
>> change to make, but we could do a lot more to mitigate the inevitable
>> confusion.
>
> What exact change are you talking about with "this change"? Earlier you
> had a chance to edit the merge log only when it needed your help resolving
> (hence you did a separate "git commit" to record it) but you had to "git
> commit --amend" (or start with "git merge --no-commit") to edit the merge
> log if it did not need any help resolving conflicts, but now you do not
> have to. Is that the change you have in mind?
Yes, or more explicitly if you do:
git commit
<your upstream moves forward>
git pull
You'll now be presented with an editor asking you to enter a merge
message, whereas before it just silently created a merge commit.
> I would like to know how that would lead to an "inevitable confusion".
> Admittedly, the original without any "# Please do X" comment, the user may
> wonder what is being asked of him when he sees the editor for the first
> time, but I thought Thomas's patch took care of that issue.
I mean that people who use this babytalk subset of git and have been
doing so for months/years without having editor dialogs pop up every
time they pull are going to be confused when that suddenly starts
happening.
>> One thing that would help these users in particular would be to have
>> some easy to use replacement for their frequent use of "git
>> pull".
>
> After this part, I think you shifted into a different topic.
>
> I have mixed feelings about "rebase your unpublished work and keep it
> always a descendant of the upstream" workflow you seem to be advocating.
> It _might_ deserve a bit more visibility, but I do not think rewording
> this message done during "merge" is the place to do so.
Yeah, agreed.
>> They don't often commit their work (because of git inexperience) so
>> rebasing will error out because the tree is unclean.
>
> That is a *good* thing, isn't it? There lies the perfect opportunity for
> them to train their fingers to commit first and then rebase.
That's true, anyway I'll submit an improved patch for adding --abort
to the current message. I think the other suggestions either aren't
doable or weren't appropriate.
^ permalink raw reply
* Re: [PATCH] grep -P: Fix matching ^ and $
From: Michał Kiedrowicz @ 2012-02-25 9:30 UTC (permalink / raw)
To: git; +Cc: Michał Kiedrowicz, Zbigniew Jędrzejewski-Szmek
In-Reply-To: <1330161868-7954-1-git-send-email-michal.kiedrowicz@gmail.com>
Michał Kiedrowicz <michal.kiedrowicz@gmail.com> wrote:
> When `git-grep` is run with -P/--perl-regexp, it doesn't match ^ and $ at
> the beginning/end of the line. This is because PCRE normally matches ^
> and $ at the beginning/end of the whole text, not for each line, and git-grep
> firstly passes a large chunk of text (possibly containing many lines) to
> pcre_exec() before it splits the text into lines. This makes `git-grep -P`
> behave differently from `git-grep -E` and also from `grep -P` and `pcregrep`:
>
> $ cat file
> a
> b
> $ git --no-pager grep --no-index -P '^ ' file
> $ git --no-pager grep --no-index -E '^ ' file
> file: b
> $ grep -c -P '^ ' file
> b
> $ pcregrep -c '^ ' file
> b
>
Original report:
http://permalink.gmane.org/gmane.comp.version-control.git/190830
> Reported-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
> Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com>
> ---
> grep.c | 2 +-
> t/t7810-grep.sh | 23 +++++++++++++++++++++++
> 2 files changed, 24 insertions(+), 1 deletions(-)
>
> diff --git a/grep.c b/grep.c
> index 3821400..f492d26 100644
> --- a/grep.c
> +++ b/grep.c
> @@ -79,7 +79,7 @@ static void compile_pcre_regexp(struct grep_pat *p, const struct grep_opt *opt)
> {
> const char *error;
> int erroffset;
> - int options = 0;
> + int options = PCRE_MULTILINE;
>
> if (opt->ignore_case)
> options |= PCRE_CASELESS;
> diff --git a/t/t7810-grep.sh b/t/t7810-grep.sh
> index 75f4716..dd6e6d5 100755
> --- a/t/t7810-grep.sh
> +++ b/t/t7810-grep.sh
> @@ -47,6 +47,13 @@ test_expect_success setup '
> echo vvv >t/v &&
> mkdir t/a &&
> echo vvv >t/a/v &&
> + {
> + echo "line without leading space1"
> + echo " line with leading space1"
> + echo " line with leading space2"
> + echo " line with leading space3"
> + echo "line without leading space2"
> + } >space &&
> git add . &&
> test_tick &&
> git commit -m initial
> @@ -893,4 +900,20 @@ test_expect_success 'mimic ack-grep --group' '
> test_cmp expected actual
> '
>
> +cat >expected <<EOF
> +space: line with leading space1
> +space: line with leading space2
> +space: line with leading space3
> +EOF
> +
> +test_expect_success 'grep -E "^ "' '
> + git grep -E "^ " space >actual &&
> + test_cmp expected actual
> +'
> +
> +test_expect_success "grep -P '^ '" '
> + git grep -P "^ " space >actual &&
> + test_cmp expected actual
> +'
> +
> test_done
^ permalink raw reply
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