Jeff King writes:
> On Wed, Jan 14, 2015 at 09:22:52AM -0800, Junio C Hamano wrote:
> ...
>> And the result should merge just fine to 'maint'.
>
> Are we in agreement then that the resulting code with the helper is
> actually easier to read? I think replacing the straight ?: lines is, but
> I am
On Wed, Jan 14, 2015 at 09:22:52AM -0800, Junio C Hamano wrote:
> Lukas Fleischer writes:
>
> >> [1/5]: git-compat-util: add xstrdup_or_null helper
> >> [2/5]: builtin/apply.c: use xstrdup_or_null instead of null_strdup
> >> [3/5]: builtin/commit.c: use xstrdup_or_null instead of envdup
>
Lukas Fleischer writes:
>> [1/5]: git-compat-util: add xstrdup_or_null helper
>> [2/5]: builtin/apply.c: use xstrdup_or_null instead of null_strdup
>> [3/5]: builtin/commit.c: use xstrdup_or_null instead of envdup
>> [4/5]: use xstrdup_or_null to replace ternary conditionals
>> [5/5]: b
On Tue, 13 Jan 2015 at 02:54:27, Jeff King wrote:
> On Mon, Jan 12, 2015 at 04:11:06PM -0800, Junio C Hamano wrote:
>
> > Jeff King writes:
> >
> > > As an aside, I have often been tempted to have xstrdup silently
> > > propagate a NULL. It would have been the right thing to do here, but
> > > m
On Mon, Jan 12, 2015 at 04:11:06PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > As an aside, I have often been tempted to have xstrdup silently
> > propagate a NULL. It would have been the right thing to do here, but
> > maybe there are cases where the segfault is preferable for catchi
Jeff King writes:
> As an aside, I have often been tempted to have xstrdup silently
> propagate a NULL. It would have been the right thing to do here, but
> maybe there are cases where the segfault is preferable for catching a
> mistake early (otherwise you might store the NULL and then segfault
On Mon, 12 Jan 2015 at 23:55:30, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Lukas Fleischer writes:
> >
> >> The helper functions prepare_final() and prepare_initial() return a
> >> pointer to a string that is a member of an object in the revs->pending
> >> array. This array is later r
On Mon, Jan 12, 2015 at 02:55:30PM -0800, Junio C Hamano wrote:
> With the patch applied on top of 1da1e07c (or the result merged to
> 'next' for that matter), I see test breakages in many places "git
> blame" is used, e.g. t7010. Did you run the test suite?
>
> This is because it is perfectly n
Junio C Hamano writes:
> Lukas Fleischer writes:
>
>> The helper functions prepare_final() and prepare_initial() return a
>> pointer to a string that is a member of an object in the revs->pending
>> array. This array is later rebuilt when running prepare_revision_walk()
>> which potentially tran
On Mon, Jan 12, 2015 at 11:08:26AM -0800, Junio C Hamano wrote:
> Lukas Fleischer writes:
>
> > The helper functions prepare_final() and prepare_initial() return a
> > pointer to a string that is a member of an object in the revs->pending
> > array. This array is later rebuilt when running prepa
Lukas Fleischer writes:
> The helper functions prepare_final() and prepare_initial() return a
> pointer to a string that is a member of an object in the revs->pending
> array. This array is later rebuilt when running prepare_revision_walk()
> which potentially transforms the pointer target into a
The helper functions prepare_final() and prepare_initial() return a
pointer to a string that is a member of an object in the revs->pending
array. This array is later rebuilt when running prepare_revision_walk()
which potentially transforms the pointer target into a bogus string. Fix
this by maintai
12 matches
Mail list logo
