* git compiled on same distro, different versions
From: Neal Kreitzinger @ 2012-02-24 21:05 UTC (permalink / raw)
To: git
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?
We don't have any RHEL5 VM images so it would be much easier for me to test
on a RHEL6 VM. I would have to justify the building of a RHEL5 image just
for this purpose.
v/r,
neal
^ permalink raw reply
* Re: git log -z doesn't separate commits with NULs
From: Junio C Hamano @ 2012-02-24 21:14 UTC (permalink / raw)
To: Jeff King; +Cc: Nikolaj Shurkaev, Jakub Narebski, git
In-Reply-To: <20120224204615.GB21447@sigill.intra.peff.net>
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.
> ... I tend to think the
> commit-limiting options are the useful and working ones, which is why I
> suggested mentioning them explicitly above.
I think I agree that is a sane thing to do.
^ permalink raw reply
* Re: git log -z doesn't separate commits with NULs
From: Jeff King @ 2012-02-24 21:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nikolaj Shurkaev, Jakub Narebski, git
In-Reply-To: <7vk43cx7c2.fsf@alter.siamese.dyndns.org>
On Fri, Feb 24, 2012 at 01:14:05PM -0800, Junio C Hamano wrote:
> > 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 ;-).
OK, good. :)
Nikolaj, have you followed all of this? Do you want to try to improve
your patch in this direction?
-Peff
^ permalink raw reply
* Re: [PATCH 2/2] do not stream large files to pack when filters are in use
From: Jeff King @ 2012-02-24 21:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20120224204810.GC21447@sigill.intra.peff.net>
On Fri, Feb 24, 2012 at 03:48:10PM -0500, Jeff King wrote:
> > By the way, I tried this with the tip of 'pu' as of last night, and the
> > result segfaults on me in t1050 (hash-object -w) ;-).
>
> Eek. I ran through "make test" on my finished series without a problem,
> but it may be a bad interaction with something in "pu", or maybe a
> heisenbug. I'll investigate.
Or maybe I'm just an idiot, and apparently didn't actually run the test
suite correctly. Because it is very reproducible, and is because
hash-object --stdin passes a NULL for the path.
I'll post the fixed series in a minute (with this fix, and the improved
convert_to_git wrapper).
-Peff
^ 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 21:20 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20120224210134.GA22177@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Fri, Feb 24, 2012 at 03:48:10PM -0500, Jeff King wrote:
>
>> On Fri, Feb 24, 2012 at 12:03:17PM -0800, Junio C Hamano wrote:
>>
>> > > - else if (size <= big_file_threshold || type != OBJ_BLOB)
>> > > + else if (size <= big_file_threshold || type != OBJ_BLOB ||
>> > > + convert_to_git(path, NULL, 0, NULL, 0))
>> >
>> > Nice. It would be even nicer to give a readability macro whose name makes
>> > it clear that this is a query (unfortunately we cannot add '?' at the end
>> > of the function name) and not a conversion. Any name suggestions?
>> ...
> I.e., you could call it like this:
>
> convert_to_git(path, buf, len, NULL, 0);
>
> and find out the real answer, including inspecting buf, about whether
> we would convert. Or you could also use a NULL buffer to get the
> pessimistic "we might convert" case.
>
> I don't think it really matters that much, as I am introducing only one
> caller. I'm not sure if any other code paths would care about this
> speculative "maybe we would convert" question, so perhaps it is simply
> over-engineering.
I agree checking if dst is NULL makes a lot more sense than checking if
the src is NULL.
The reason I said "readability" macro was *NOT* because of these NULLs
looked unsightly. I wanted the function name to tell "We are *NOT*
actually converting anything here at this point" to the readers.
I am perfectly fine to keep the source side of the parameters in the
readability macro, even if this partcular caller may have to spell NULL
and 0 there.
Thanks.
^ permalink raw reply
* Re: FW: question about merge in 1.7.10
From: Junio C Hamano @ 2012-02-24 21:22 UTC (permalink / raw)
To: Marlene Cote; +Cc: Zbigniew Jędrzejewski-Szmek, git@vger.kernel.org
In-Reply-To: <1F026B57884A5841B330471696849DE9114508EC@MBX021-W4-CA-5.exch021.domain.local>
Marlene Cote <Marlene_Cote@affirmednetworks.com> writes:
> I know that the tree will be dirty. The change to git in 1.7.10 says
> that the merge will require a commit message when the command is run.
I do not think I ever said that.
"merge" will always start an editor when it auto-commits
is what I said.
Could you point me where you read that "will require a commit message", so
that it can be corrected?
^ permalink raw reply
* RE: FW: question about merge in 1.7.10
From: Marlene Cote @ 2012-02-24 21:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Zbigniew Jędrzejewski-Szmek, git@vger.kernel.org
In-Reply-To: <7vbooox6xy.fsf@alter.siamese.dyndns.org>
Sorry. You are correct. You said it would open an editor session.
-----Original Message-----
From: Junio C Hamano [mailto:gitster@pobox.com]
Sent: Friday, February 24, 2012 4:23 PM
To: Marlene Cote
Cc: Zbigniew Jędrzejewski-Szmek; git@vger.kernel.org
Subject: Re: FW: question about merge in 1.7.10
Marlene Cote <Marlene_Cote@affirmednetworks.com> writes:
> I know that the tree will be dirty. The change to git in 1.7.10 says
> that the merge will require a commit message when the command is run.
I do not think I ever said that.
"merge" will always start an editor when it auto-commits
is what I said.
Could you point me where you read that "will require a commit message", so that it can be corrected?
^ permalink raw reply
* Re: Announcing nntpgit
From: Junio C Hamano @ 2012-02-24 21:38 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: git
In-Reply-To: <20120224133942.49a7a420@dt>
Jonathan Corbet <corbet@lwn.net> writes:
> When kernel.org went down, it took the mainline kernel commits list with
> it. That had a fairly serious and unfortunate effect on my workflow,
> which, among other things, depends on knowing what's being merged. I
> hacked up various workarounds, but none of them were as useful or
> efficient.
>
> Eventually it occurred to me that what I *really* wanted was the commit
> stream as an NNTP feed so I could read it in gnus along with most of the
> other lists I follow. The result was nntpgit, a small Python3 program
> that tracks repository branches and makes new commits available as
> "articles" to all comers. I've been working with it for a few weeks now
> and I'm quite happy; it works better for me than the old list did.
>
> Should anybody wish to experiment with it, they can do so in two ways.
> First, the code is available (GPLv2) from:
>
> git://git.lwn.net/nntpgit.git
>
> Alternatively, it's running on port 8119 on git.lwn.net. There are
> currently two "newsgroups": lwn.mainline for mainline commits, and
> lwn.networking for davem's networking tree. I expect to add others over
> time.
Neat.
This is something I wanted to write (or see somebody write so that I can
use it ;-)) even before I became the maintainer of this project, as I
practically live inside GNUS, but never got around to go beyond the design
phase.
How do you handle message threading (References: and In-Reply-To:)?
Would a commit on the "mainline" (a rough approximation of it would be
"log --first-parent" starting from the tip) form the discussion starter
article, and any side branch that fork from them would be a discussion
thread starting at the commit?
^ permalink raw reply
* Re: Announcing nntpgit
From: Jonathan Corbet @ 2012-02-24 21:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v62evykrq.fsf@alter.siamese.dyndns.org>
On Fri, 24 Feb 2012 13:38:33 -0800
Junio C Hamano <gitster@pobox.com> wrote:
> How do you handle message threading (References: and In-Reply-To:)?
>
> Would a commit on the "mainline" (a rough approximation of it would be
> "log --first-parent" starting from the tip) form the discussion starter
> article, and any side branch that fork from them would be a discussion
> thread starting at the commit?
There's really no threading at all at this point; it's just a linear
series of commits-as-messages as provided by a vanilla "git log". I could
certainly see trying to do something fancier, if it were useful, but it's
not something I've thought about much yet.
Like I said, it's really young stuff :)
jon
^ permalink raw reply
* Re: [BugReport] git tag -a / git show
From: Romain Vimont (®om) @ 2012-02-24 21:42 UTC (permalink / raw)
To: Jeff King; +Cc: Zbigniew Jędrzejewski-Szmek, git
In-Reply-To: <20120224205203.GA21780@sigill.intra.peff.net>
Thank you, I didn't know this '^' thing ;-)
Le vendredi 24 février 2012 à 15:52 -0500, Jeff King a écrit :
> On Fri, Feb 24, 2012 at 08:55:45PM +0100, Romain Vimont (®om) wrote:
>
> > Tonight, I just tried something which do exactly what I wanted to do
> > this morning:
> >
> > $ git checkout -b temp
> > $ git commit -a -m 'My config file with mock_data=true'
> > $ git tag -a v0.1 -m v0.1
> > $ git checkout master
> > $ git branch -D temp
>
> There is nothing at all wrong with the commands above, but you might be
> interested to know that you can do it without the temporary branch:
>
> $ git commit -a -m 'My config...'
> $ git tag -m v0.1 v0.1
> $ git reset HEAD^
>
> The final reset will rewind your branch tip and the index state to what
> it was before the commit, but will leave the files in the working tree
> untouched.
>
> -Peff
>
^ permalink raw reply
* 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
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