Hi,
Nit: In subject, patch should be like [PATCH v2] for each increasing order
of revision.
Also, after the --- (three dashes), you can write what you changed with each
patch revision. Also to link the previous patches if you can.
So the corrected mail subject header will look something like thi
http://stackoverflow.com/questions/22585091/git-hooks-pre-push-script-does-not-receive-input-via-stdin
Is this a bug in git? Or am I just a shell noob?
Thanks in advance,
David
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.or
On Thu, Mar 20, 2014 at 7:13 PM, Justin Lebar wrote:
> Thanks for the quick reply.
>
> When I send a new patch, should I fold these changes into the original
> commit, or should I send them as a separate commit?
>
>>> diff --git a/builtin/apply.c b/builtin/apply.c
>>> index b0d0986..6013e19 100644
Mustafa Orkun Acar writes:
> I reviewed all functions using memcmp(). It generally makes code more
> understandable. But here it might be used for the sake of simplicity.
>
> Signed-off-by: Mustafa Orkun Acar
> ---
> I applied to GSoC 2014. I expect your feedbacks and comments!
> strbuf.c | 2
Hi,
This does not seam correct to me.
The memcmp function could have returned 3 relevant values (zero,
positive and negative) and a non-zero result would have been returned
by the if statement.
With you modification, you replace a negative value from memcmp with a
positive one.
Best regards,
Alex
I reviewed all functions using memcmp(). It generally makes code more
understandable. But here it might be used for the sake of simplicity.
Signed-off-by: Mustafa Orkun Acar
---
I applied to GSoC 2014. I expect your feedbacks and comments!
strbuf.c | 2 +-
1 file changed, 1 insertion(+), 1 dele
Reduce code duplication by introducing test_log_icase() that runs the
same test with both --regexp-ignore-case and -i. The specification of
the four basic test scenarios (matching/nomatching combined with case
sensitive/insensitive) becomes easier to read and write.
Signed-off-by: Rene Scharfe
-
This series allows the options -i/--regexp-ignore-case, --pickaxe-regex,
and -S to be used together and work as expected to perform a pickaxe
search using case-insensitive regular expression matching. Its first
half refactors the test script and extends test coverage a bit while
we're at it. The
ade4 (pickaxe: allow -i to search in patch case-insensitively)
allowed case-insenitive matching for -G and -S, but for the latter
only if fixed string matching is used. Allow it for -S and regular
expression matching as well to make the support complete.
Signed-off-by: Rene Scharfe
---
diff
Also add tests for non-matching cases.
Signed-off-by: Rene Scharfe
---
t/t4209-log-pickaxe.sh | 18 --
1 file changed, 4 insertions(+), 14 deletions(-)
diff --git a/t/t4209-log-pickaxe.sh b/t/t4209-log-pickaxe.sh
index dd911c2..873a10e 100755
--- a/t/t4209-log-pickaxe.sh
+++ b/t
Inlining the variable "found" actually makes the code shorter and
easier to read.
Signed-off-by: Rene Scharfe
---
diffcore-pickaxe.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/diffcore-pickaxe.c b/diffcore-pickaxe.c
index 70753d0..185f86b 100644
--- a/diffcore-pic
Instead of creating an expect file for each test, build three files with
the possible valid values during setup and use them in the tests. This
shortens the test code and saves nine calls to git rev-parse.
Signed-off-by: Rene Scharfe
---
t/t4209-log-pickaxe.sh | 64 -
We need to determine the search term's length only when fixed-string
matching is used; regular expression compilation takes a NUL-terminated
string directly. Only call strlen() in the former case.
Signed-off-by: Rene Scharfe
---
diffcore-pickaxe.c | 3 +--
1 file changed, 1 insertion(+), 2 dele
diffcore_pickaxe_count() initializes the regular expression or kwset for
the search term, calls pickaxe() with the callback has_changes() and
cleans up afterwards. diffcore_pickaxe_grep() does the same, only it
doesn't support kwset and uses the callback diff_grep() instead. Merge
the two functio
Twelve tests in t4209 follow the same simple pattern for description,
git log call and checking. Extract that shared logic into a helper
function named test_log. Test specifications become a lot more
compact, new tests can be added more easily.
Signed-off-by: Rene Scharfe
---
t/t4209-log-picka
Also add tests for case sensitive and non-matching cases.
Signed-off-by: Rene Scharfe
---
t/t4209-log-pickaxe.sh | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/t/t4209-log-pickaxe.sh b/t/t4209-log-pickaxe.sh
index 873a10e..80aabe2 100755
--- a/t/t4209-log-picka
pickaxe() calls pickaxe_match(); moving the definition of the former
those after the latter allows us to do without an explicit function
declaration.
Signed-off-by: Rene Scharfe
---
diffcore-pickaxe.c | 79 ++
1 file changed, 38 insertions(+),
On 2014-03-21 23.32, Junio C Hamano wrote:
> Max Horn writes:
>
>> Hi Torsten,
>>
>> On 21.03.2014, at 21:47, Torsten Bögershausen wrote:
>>
>>> On 2014-03-21 12.36, Max Horn wrote:
>>> All tests passed :-),
>>
>> Excellent.
>>
>>> thanks from my side.
>>> comments inline, some are debatable
>>
Replace memcmp by skip_prefix as it serves the dual
purpose of checking the string for a prefix as well
as skipping that prefix.
Signed-off-by: Ashwin Jha
---
fsck.c | 25 ++---
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/fsck.c b/fsck.c
index 64bf279..0
Hello,
I use git version 1.9.1 . With
git clone git://github.com/pocoproject/poco.git
cd poco
git log --graph --color=always
and scrolling a bit, I see
http://mail.aegee.org/dpa/git-log-graph-color/git-log-graph-color.png .
My expectation is, that one branch keeps its color consistent
On Fri, Mar 21, 2014 at 07:58:55PM -0700, Siddharth Agarwal wrote:
> At Facebook we've found that fetch speed is a bottleneck for our Git repos,
> so we've been looking to deploy bitmaps to speed up fetches. We've been
> trying out git-next with the top two patches from
> https://github.com/peff/g
Jeff King peff.net> writes:
>
> So I think we'd be happy to see it converted to an iterative process
> (probably with a stack on the heap). In addition to name-rev, I believe
> that "tag --contains" will recurse down the longest history path, too (I
> think there may have been experimental patch
Built-in commands can specify names for option arguments when usage text
is generated for a command. sh based commands should be able to do the
same.
Option argument name hint is any text that comes after [*=?!] after the
argument name up to the first whitespace.
Signed-off-by: Ilya Bobyr
---
Am 24.02.2014 08:49, schrieb Jeff King:
Many code paths assume that show_date and show_ident_date
cannot return NULL. For the most part, we handle missing or
corrupt timestamps by showing the epoch time t=0.
However, we might still return NULL if gmtime rejects the
time_t we feed it, resulting i
On Sat, Mar 22, 2014 at 12:46 AM, Eric Sunshine wrote:
>
> Because it's unnecessary and invites confusion from people reading the
> code since they now have to wonder if there is something unusual and
> non-obvious going. Worse, the two loops immediately below the ones you
> changed, as well as th
On 2014-03-21 17.13, Matthias Beyer wrote:
> Hi,
>
> I struggled with a really nasty issue today (and yesterday):
>
> I work on a semester project paper which is written in latex and
> therefor version-controlled with git. We compile the document using
> pdflatex, we automate the compiling with m
26 matches
Mail list logo