Re: [PATCH v2] git-merge: ignore space support

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 25, 2010, 17:55 UTC
Message-ID: <7vy6bushjx.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4C753BFD.5060807@cockos.com>

Justin Frankel <justin@cockos.com> writes:

Show 23 quoted lines

> The only danger is that ll_merge()'s signature didn't change in such a
> way to break compilation, i.e:
>
> int ll_merge(mmbuffer_t *result_buf,
>             const char *path,
>             mmfile_t *ancestor, const char *ancestor_label,
>             mmfile_t *ours, const char *our_label,
>             mmfile_t *theirs, const char *their_label,
>             int flag);
>
> becomes:
>
> int ll_merge(mmbuffer_t *result_buf,
>             const char *path,
>             mmfile_t *ancestor, const char *ancestor_label,
>             mmfile_t *ours, const char *our_label,
>             mmfile_t *theirs, const char *their_label,
>             struct whatever *conf);
>
> In this case, passing 0 as the last parameter will compile either way.
>
> Sure, we can grep all of the source, but who knows when something else
> will get merged in...

That is technically a valid concern but I suspect it does not matter in this particular case, where integer 0 used to mean "use the default" and the new API uses NULL to mean the same.

If an existing call site used to pass 0 and the patch forgot to update it, it will look ugly (we encourage to spell a NULL pointer "NULL", not "0", in our codebase) but no harm is done. If an existing call site asked for a non-default behaviour by passing a non-zero integer flag, and the patch forgot to update it, the compiler would have caught it. Merging a side branch is the same deal; if it adds a call with a non-zero argument to ask for a non-default behaviour, that will be done via an expression over some integer variables or constants, and that won't be casted silently to a pointer to "struct whatever", no?