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 use
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 git-
--
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 http://
On Tue, Sep 23, 2014 at 10:07 AM, Michael S. Tsirkin 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
>> " --tra
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 ($Tk::plat
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 withi
On 09/23/14 23:35, Junio C Hamano wrote:
> Laszlo Ersek 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, thanks!
> Now
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 http://vger.
And explain how it interacts with the scissors setting.
Signed-off-by: W. Trevor King
---
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
thought about ad
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 Dropbox
Laszlo Ersek 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 a possible ap
Michael Haggerty 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,
>> multiplies
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 cha
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 rig
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
http://git-blame.blogspot.com/p/git-publi
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
Stefan Beller 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 in the body of
Junio C Hamano 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
> should
Jörn Engel 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 huge d
Javier Domingo Cansino 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 he works, and
21 matches
Mail list logo
