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

Justin Frankel [off-list ref] writes:

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?

Junio C Hamano wrote:

Justin Frankel [off-list ref] writes:

  

quoted

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?

  

Agreed, I was responding to Bert's email, in which he stated that he 
hadn't seen NULL-for-default anywhere else in git. Using NULL for 
default behavior is good in that it handles un-updated code and merges 
correctly (passing 0 uses defaults, passing nonzero fails compile).

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html