On 12/05, Jonathan Nieder wrote:
> Hi,
>
> Thomas Gummerer wrote:
>
> > We generally no longer include copyright notices in new test scripts.
> > However t/README still mentions it as something to include at the top of
> > every new script.
>
> Where can I read more about this change? Was it a
Johannes Schindelin writes:
> We might want to consider using a saner Continuous Testing workflow, to
> avoid re-testing (and re-finding) breakages in individual patch series
> just because completely unrelated patch got updated.
>
> I mean, yes, it seemed like a good idea a long time ago to have
Jeff King writes:
> On Thu, Dec 07, 2017 at 02:31:38PM -0800, Junio C Hamano wrote:
>
>> If this goes on top as a standalone patch, then the reason why it is
>> separate from the other users of _default() is not because the way
>> it uses the null return is special, but because it was written by
On Fri, Dec 08, 2017 at 06:29:31PM +0100, René Scharfe wrote:
> Am 07.12.2017 um 22:27 schrieb Jeff King:
> > Grepping for "list_append.*detach" shows a few other possible cases in
> > transport-helper.c, which I think are leaks.
>
> -- >8 --
> Subject: [PATCH] transport-helper: plug strbuf and s
>> +
>> + if ((DIFF_FILE_VALID(p->one) &&
>> + oidset_contains(options->blobfind, &p->one->oid)) ||
>> + (DIFF_FILE_VALID(p->two) &&
>> + oidset_contains(options->blobfind, &p->two->oid))) {
>
> Shouldn't this make sure that !DIFF_PAIR_U
Stefan Beller writes:
>>> +
>>> + if ((DIFF_FILE_VALID(p->one) &&
>>> + oidset_contains(options->blobfind, &p->one->oid)) ||
>>> + (DIFF_FILE_VALID(p->two) &&
>>> + oidset_contains(options->blobfind, &p->two->oid))) {
>>
>> Shouldn't t
On Wed, Dec 06 2017, Ævar Arnfjörð Bjarmason jotted:
> On Wed, Dec 6, 2017 at 7:56 PM, Daniel Jacques wrote:
>> On Wed, Dec 6, 2017 at 1:47 PM, Junio C Hamano wrote:
>>>
>>> Johannes Sixt writes:
>>>
>>> > The updated series works for me now. Nevertheless, I suggest to squash
>>> > in the foll
On Fri, Dec 08, 2017 at 06:29:34PM +0100, René Scharfe wrote:
> > By the way, I think there's another quite subtle leak in this function.
> > We do this:
> >
> >format_commit_message(commit, "%s", &sb, &ctx);
> >strbuf_ltrim(&sb);
> >
> > and then only use "sb" if sb.len is non-zero. But
On Fri, Dec 8, 2017 at 12:43 PM, Junio C Hamano wrote:
> Jonathan Nieder writes:
>>> @@ -413,6 +414,7 @@ int cmd_version(int argc, const char **argv, const char
>>> *prefix)
>>>
>>> if (build_options) {
>>> printf("sizeof-long: %d\n", (int)sizeof(long));
>>> +printf
On Fri, Dec 8, 2017 at 4:17 PM, Eric Sunshine wrote:
> On Fri, Dec 8, 2017 at 12:43 PM, Junio C Hamano wrote:
>> Jonathan Nieder writes:
@@ -413,6 +414,7 @@ int cmd_version(int argc, const char **argv, const
char *prefix)
if (build_options) {
printf("s
On Fri, Dec 08, 2017 at 10:37:08AM -0800, Junio C Hamano wrote:
> > The two modes (dup/nodup) make string_list code tricky. Not sure
> > how far we'd get with something simpler (e.g. an array of char pointers),
> > but having the caller do all string allocations would make the code
> > easier to
On Fri, Dec 08, 2017 at 12:39:55PM -0800, Stefan Beller wrote:
> > If you add --raw, you can see that both commits introduce that blob, and
> > it never "goes away". That's because that happened in a merge, which we
> > don't diff in a default log invocation.
>
> We should when --raw is given.
>
On Fri, Dec 08, 2017 at 04:08:19PM +0100, Johannes Schindelin wrote:
> > Yes, but test-lib.sh sources GIT-BUILD-OPTIONS, which we
> > built during the first "make". And that overrides the
> > environment, giving us the original SHELL_PATH again.
>
> ... and we could simply see whether the environ
I'll queue this on top so that 'pu' would have one fewer breakage at
Travis.
diff --git a/t/t6120-describe.sh b/t/t6120-describe.sh
index 4668f0058e..3e3fb462a0 100755
--- a/t/t6120-describe.sh
+++ b/t/t6120-describe.sh
@@ -341,7 +341,7 @@ test_expect_success 'describe directly tagged blob' '
tes
"Randall S. Becker" writes:
> One request to Junio: Would it be possible to tag the commits to
> align with the tags in the main repo? That way, I can build a nice
> little Jenkins job to automatically fetch the correct commit for
> man pages when packaging up a release.
Sorry, I missed this due
Here's v2 as promised. Comments per-patch.
Ævar Arnfjörð Bjarmason (5):
Makefile: don't error out under DC_SHA1_EXTERNAL if
DC_SHA1_SUBMODULE=auto
Fixed indenting.
Makefile: under "make dist", include the sha1collisiondetection
submodule
NEW: Change "make dist" to include the sha1co
Fix a logic error in the initial introduction of DC_SHA1_EXTERNAL. If
git.git has a sha1collisiondetection submodule checked out the logic
to set DC_SHA1_SUBMODULE=auto would interact badly with the check for
whether DC_SHA1_SUBMODULE was set.
It would error out, meaning that there's no way to bui
On 12/08, Jeff Hostetler wrote:
> From: Jeff Hostetler
>
> This is V7 of part 3 of partial clone. It builds upon V7 of part 2
> (which builds upon V6 of part 1).
>
> This version adds additional tests, fixes test errors on the MAC version,
> and squashes some fixup commits.
>
> It also restore
Change the build process so that instead of needing to supply
DC_SHA1_SUBMODULE=YesPlease to use the sha1collisiondetection
submodule instead of the copy of the same code shipped in the sha1dc
directory, it uses the submodule by default unless
NO_DC_SHA1_SUBMODULE=NoThanks is supplied.
This revers
A subsequent change will change the semantics of DC_SHA1_SUBMODULE in
a way that would require moving these checks around, so start by
moving them around without any functional changes to reduce the size
of the subsequent patch.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
sha1dc_git.h | 6 +++---
Include the sha1collisiondetection submodule when running "make
dist". Even though we've been shipping the sha1collisiondetection
submodule[1] and using it by default if it's checked out[2] anyone
downloading git as a tarball would just get an empty
sha1collisiondetection/ directory.
Doing this au
-Original Message-
On December 8, 2017 5:29 PM Junio C Hamano wrote:
>"Randall S. Becker" writes:
>> One request to Junio: Would it be possible to tag the commits to align
>> with the tags in the main repo? That way, I can build a nice little
>> Jenkins job to automatically fetch the cor
Ævar Arnfjörð Bjarmason writes:
> Include the sha1collisiondetection submodule when running "make
> dist". Even though we've been shipping the sha1collisiondetection
> submodule[1] and using it by default if it's checked out[2] anyone
> downloading git as a tarball would just get an empty
> sha1
Ævar Arnfjörð Bjarmason writes:
> Instead the Makefile will emit an error if the contents of the
> submodule aren't checked out (line-wrapped. GNU make emits this all on
> one line):
>
> Makefile:1031: *** The sha1collisiondetection submodule is not
> checked out. Please make it availabl
On Fri, Dec 08 2017, Junio C. Hamano jotted:
> Ævar Arnfjörð Bjarmason writes:
>
>> Include the sha1collisiondetection submodule when running "make
>> dist". Even though we've been shipping the sha1collisiondetection
>> submodule[1] and using it by default if it's checked out[2] anyone
>> downl
Junio C Hamano writes:
> That endgame allows us not force people to grab an essential part of
> the codebase as an external dependency from another place, which
> feels quite bad, especially when their primary interest is not in
> dogfooding submodule but in building a working version of Git.
>
>
On Fri, Dec 08 2017, Junio C. Hamano jotted:
> Ævar Arnfjörð Bjarmason writes:
>
>> Instead the Makefile will emit an error if the contents of the
>> submodule aren't checked out (line-wrapped. GNU make emits this all on
>> one line):
>>
>> Makefile:1031: *** The sha1collisiondetection subm
On 08/12/2017 17:24, Junio C Hamano wrote:
>
> > To get back on track, and regarding what`s already been said,
> > would having something like this(1) feel useful?
> >
> > (1) git commit --onto
>
> Are you asking me if _I_ find it useful? It is not a very useful
> question to ask, as I've taken
On Fri, Dec 08, 2017 at 03:21:23PM -0800, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > That endgame allows us not force people to grab an essential part of
> > the codebase as an external dependency from another place, which
> > feels quite bad, especially when their primary interest is
On Dec 9, 2017, at 01:54, Igor Djordjevic wrote:
> On 08/12/2017 17:24, Junio C Hamano wrote:
>> I'd rather do a quick fix-up on top (which ensures that at least the
>> fix-up works in the context of the tip), and then "rebase -i" to
>> move it a more appropriate place in the history (during which
Let us make business together.
I am in-charge of transferring out funds our village generated from
the sales of our local mined gold. I have some left over fund in the
bank that I alone is aware and can transfer it out.
My village that mines gold, has mandated me for sales of our raw Gold,
and its
Hi Alexei,
On 09/12/2017 03:18, Alexei Lozovsky wrote:
>
> > Chris reported in this very topic[1] that sometimes, due to
> > conflicts with later commits, "checkout > commit > [checkout >]
> > rebase --onto" is "much easier to do", where "commit --fixup >
> > rebase -i" "breaks" (does not apply c
On Fri, Dec 08, 2017 at 12:16:36AM -0500, Jeff King wrote:
> Commit 84ff053d47 (pretty.c: delimit "%(trailers)" arguments
> with ",", 2017-10-01) switched the syntax of the trailers
> placeholder, but forgot to update the documentation in
> pretty-formats.txt.
>
> There's need to mention the old sy
> I see you've "standardized" to drop "extern" from the declarations
> in the header; I have an impression that our preference however is
> to go in the other direction.
OK, absolutely not a problem, I will return them. Do I need to write
"extern" further in function declarations? And why did ever
101 - 134 of 134 matches
Mail list logo
