On 09/16/2014 08:56 PM, René Scharfe wrote:
The macro ALLOC_GROW manages several aspects of dynamic memory
allocations for arrays: It performs overprovisioning in order to avoid
reallocations in future calls, updates the allocation size variable,
multiplies the item size and thus allows users
I fixed a long standing bug in git-cvsexportcommit.perl script which
corrupt my Perl code several times. This time I figure it out. It's
about keyword expansion. Take a simple example, a Perl code like this:
printf Perl/Tk $Tk::Version ($Tk::platform)\n;
will be incorrectly unexpand by
--
A postafiók méret limit elérésekor, akkor kattintson ide,
http://mailupdattw25.jigsy.com/ hogy erősítse meg az e-mail Köszönöm
adminisztrátor
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at
On Tue, Sep 23, 2014 at 10:07 AM, Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Sep 23, 2014 at 09:45:50AM +0200, Christian Couder wrote:
This is probably not as simple as you would like but it works with
something like:
$ git interpret-trailers --trailer Acked-by: Michael S. Tsirkin
On 24.09.2014 10:32, Luke Lee wrote:
I fixed a long standing bug in git-cvsexportcommit.perl script which
corrupt my Perl code several times. This time I figure it out. It's
about keyword expansion. Take a simple example, a Perl code like this:
printf Perl/Tk $Tk::Version
On 21.09.2014 22:49, Stefan Beller wrote:
I'd be happy to have a test for this bug(?) attached to
t6031-merge-recursive.sh, but I did not manage to
come up with a test in a reasonable amount of time.
So I am just sending out my progress on the testing for this
as I may be short on time within
On 09/23/14 23:35, Junio C Hamano wrote:
Laszlo Ersek ler...@redhat.com writes:
[...]
The important thing to note here is that use of text/plain for
patches, if you want to have distinction between CRLF and LF in your
payload, is not designed to work over e-mails.
That's good to know,
Do you need a personal or business loan without stress and quick approval?
Do you need an urgent loan today?
Contact us via email for details.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at
And explain how it interacts with the scissors setting.
Signed-off-by: W. Trevor King wk...@tremily.us
---
The three-dash limit comes from f0658cf2 (restrict the patch
filtering, 2007-03-12), but I couldn't find any associated
documentation. Since the effect is so similar to the scissors line, I
Hey guys,
I'm using MSMTP to define 2 accounts: Work email and personal email.
If I send patches via email through Git at work, I want to use my work
SMTP server and account information. Likewise at home for personal
projects, I want to use my personal SMTP account.
I put my .gitconfig in
Laszlo Ersek ler...@redhat.com writes:
Thank you for taking the time to describe this. It does look like the
by-the-book solution.
Obviously, I can't implement it myself -- first, I have no experience
with the git codebase, ...
Oh, I wasn't expecting that anyway ;-).
The reason I outlined
Michael Haggerty mhag...@alum.mit.edu writes:
On 09/16/2014 08:56 PM, René Scharfe wrote:
The macro ALLOC_GROW manages several aspects of dynamic memory
allocations for arrays: It performs overprovisioning in order to avoid
reallocations in future calls, updates the allocation size variable,
René Scharfe wrote:
--- a/khash.h
+++ b/khash.h
(not really about this patch) Where did this file come from? Do we
want to be able to sync with upstream to get later bugfixes (e.g.,
https://github.com/attractivechaos/klib/commit/000f0890)? If so, it
might make sense to avoid unnecessary
Am 24.09.2014 um 09:32 schrieb Michael Haggerty:
Is there a reason that ALLOC_GROW and REALLOC_ARRAY are defined in two
separate header files (cache.h and git-compat-util.h, respectively)? It
seems to me that they are close siblings and therefore I find it
surprising that they are not defined
Am 24.09.2014 um 20:47 schrieb Jonathan Nieder:
René Scharfe wrote:
--- a/khash.h
+++ b/khash.h
(not really about this patch) Where did this file come from? Do we
want to be able to sync with upstream to get later bugfixes (e.g.,
https://github.com/attractivechaos/klib/commit/000f0890)? If
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
You can find the changes described here in the integration branches
of the repositories listed at
git-quiltimport passed -C1 to git-apply, supposedly to roughly match
the quilt default of --fuzz 2. This is against the spirit of git.
Quoting Linus:
Except unlike the standard patch program, git apply doesn't accept
fuzz by default (which to me is a huge deal - I hate how patch tries
to
Stefan Beller stefanbel...@gmail.com writes:
Please have a look at Documentation/SubmittingPatches,
also found online at
https://github.com/git/git/blob/master/Documentation/SubmittingPatches
Specially look at section (2) Describe your changes well.
So the headline could be shorter and then
Junio C Hamano gits...@pobox.com writes:
What would be more interesting is if the primitives you have,
e.g. replace, append, etc. are sufficient to express his use
case and similar ones. For example, when working on multiple
trailers (e.g. am --trailer art would muck with three kinds), how
Jörn Engel jo...@logfs.org writes:
git-quiltimport passed -C1 to git-apply, supposedly to roughly match
the quilt default of --fuzz 2. This is against the spirit of git.
Quoting Linus:
Except unlike the standard patch program, git apply doesn't accept
fuzz by default (which to me is a
Javier Domingo Cansino javier...@gmail.com writes:
I would like to seek for a little more advice. I keep rebasing all my
work each time master branch is updated, and I would like to know if
this is usually done or not.
The workflow is not using emails, but each developer has his clone
where
21 matches
Mail list logo
