On Fri, Apr 04, 2014 at 03:28:48PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > We could convert OFS_DELTA to REF_DELTA on the fly. That _may_ have a
> > performance impact. Right now, we are basically doing the equivalent of
> > sendfile(), and conversion would involve iterating throu
Junio C Hamano writes:
> Christian Couder writes:
> ...
>>> Why support both '=' and ':'? Using just one would make it easier to
>>> grep through scripts to see who is adding signoffs.
>>
>> That was already discussed previously.
>
> I do recall it was discussed previously, but given that a new
Christian Couder writes:
> "The following features are planned but not yet implemented:
> - add more tests related to commands
> - add examples in documentation
> - integration with "git commit""
I was planning to merge the series to 'next', but perhaps we should
wait at
Jeff King writes:
> We could convert OFS_DELTA to REF_DELTA on the fly. That _may_ have a
> performance impact. Right now, we are basically doing the equivalent of
> sendfile(), and conversion would involve iterating through each object
> and examining the header. I think that's probably not too
On Wed, Apr 02, 2014 at 10:39:13AM -0700, Junio C Hamano wrote:
> > However, it's possible that the other side cannot read our
> > packfile verbatim. For example, we may have objects stored
> > as OFS_DELTA, but the client is an antique version of git
> > that only understands REF_DELTA. We negoti
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
More topics merged to 'master', some of which are fallouts from GSoC
microprojects, some are updates to docs. C/C++ funcname pattern
update is
Jonathan Nieder writes:
> 140 patches worth of churn once every couple of years is not terrible,
> but I really don't want to see this becoming a pattern. :/
Likewise.
> And I don't see how the upside in this example warrants it.
Paraphrasing http://article.gmane.org/gmane.linux.kernel/943020
Marat Radchenko writes:
> Drop NO_PERL_MAKEMAKER from config.mak.uname for the MSVC platform.
>
> MakeMaker is available on Windows Perl implementations and
> installs modules to correct location, unlike NO_PERL_MAKEMAKER Makefile.
>
> Signed-off-by: Marat Radchenko
> ---
As nobody seems to obj
Jakub Narębski writes:
> W dniu 2014-04-03 23:44, Junio C Hamano pisze:
>> René Scharfe writes:
>>
>>> With that approach you depend on the hunk header and apparently need
>>> to add XDL_EMIT_MOREFUNCNAMES and XDL_EMIT_MOREHUNKHEADS to improve
>>> the results. This approach feels fragile.
>>>
>
Kirill Smelkov writes:
> +extern
> +struct combine_diff_path *diff_tree_paths(
These two on the same line, please.
> + struct combine_diff_path *p, const unsigned char *sha1,
> + const unsigned char **parent_sha1, int nparent,
> + struct strbuf *base, struct diff_options *opt);
> e
Matthieu Moy wrote:
> Jonathan Nieder writes:
>> If the script is "obviously correct" enough then there is no need
>> to manually go through 140 files after that point.
>
> The script cannot be "obviously correct", as there are a lot of
> potential corner-cases (nested `, nesting ` within ", comm
Jonathan Nieder writes:
> If the script is "obviously correct" enough then there is no need
> to manually go through 140 files after that point.
The script cannot be "obviously correct", as there are a lot of
potential corner-cases (nested `, nesting ` within ", comments, ...).
> If the only wa
Hi,
Elia Pinto wrote:
> This patch series contain the
>
> use the $( ... ) construct for command substitution
>
> patches not already merged in ep/shell-command-substitution
> in the mantainer repository.
Thanks for working on this. The $() form is less error-prone
than ``, so in that sense it
This patch series contain the
use the $( ... ) construct for command substitution
patches not already merged in ep/shell-command-substitution
in the mantainer repository. It is the version 3 of the
patch series.
I changed the commit message in accordance with those approved,
and I have rebased
Good day,
I'm not sure if it a real bug or just a functionality fix but this is my issue.
What I wanted to do :
Stash non committed change, but forgot to close a file that had uncommitted
change and was write lock.
What I did :
Git stash
What happen
Git stash created the stash and try to rem
W dniu 2014-03-27 19:50, David A. Dalrymple (and Bhushan G. Lodha) pisze:
+test_expect_success setup '
+ echo "* diff=cpp" > .gitattributes
+
+ >file &&
+ git add file &&
+ test_tick &&
+ git commit -m initial &&
+
+ printf "int main(){\n\treturn 0;\n}\n" >> f
W dniu 2014-04-03 23:44, Junio C Hamano pisze:
René Scharfe writes:
With that approach you depend on the hunk header and apparently need
to add XDL_EMIT_MOREFUNCNAMES and XDL_EMIT_MOREHUNKHEADS to improve
the results. This approach feels fragile.
Would it perhaps be more robust to not base t
W dniu 2014-03-27 19:50, David A. Dalrymple (and Bhushan G. Lodha) pisze:
From: "Bhushan G. Lodha & David A. Dalrymple"
This function type previously accepted separate regex_t and kwset_t
parameters, which conceptually go together. Here we create a struct to
encapsulate them, in anticipation of
18 matches
Mail list logo
