Re: [PATCH 0/5] fc/transport-helper-sync-error-fix rebased

[Felipe Contreras <felipe.contreras@gmail.com>]

Junio C Hamano wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
> 
> > Junio C Hamano wrote:
> >> As I have said in the recent What's cooking reports, the original
> >> posted here were based on older codebase and needed to be rebased,
> >> but it had some conflicts and I wanted to see the result double
> >> checked by the original author before we can merge it to 'next',
> >> cooked there and hopefully merged to 'master' before tagging -rc1.
> >> 
> >> So here is the series that has been queued in 'pu' for the past
> >> several days.
> >> 
> >> Felipe, can you double check it?
> >
> > These patches don't help much,...
> 
> What do you mean by that, exactly?  As long as your "don't help
> much" is "would not hurt and will help some even for a small subset
> of audience", that would be OK, but I am puzzled.

I mean if purpose of these was for me to review the changes you did, it doesn't
help as much as an interdiff does.

> My reading of your responses to bug reports and the cover letter of
> the series has been that these were real fixes to a real problem
> without downsides, and that you consider that they are good changes
> to have in the upcoming release.
> 
> I am hoping that you did not mean that we shouldn't merge it to the
> 'next' and 'master' branches, but if that is what you meant, can we
> hear what the downsides of the series are?
> Are they more churn than they are worth without solving the real
> issue?  Do they regress for some repositories/workflows while
> improving for others?  I didn't get such an impression.

That's not what I meant. The patches are good.

> > ..., I did and interdiff with my own fixes and this is the result:
> > ...  I don't like it, but it's OK.
> 
> Correct.  Following the coding style of the project is not the
> matter for your liking or not liking.  It is part of being on the
> same codebase with other participant of this project.

There's nothing in Documentation/CodingGuidelines that says multiple piped
commands should be one on each line even if togther the line doesn't exceed 80
characters, nor does it says that file names should be between quotes, even if
the file name can't possibly have spaces.

These are just your arbitrary rules, not the guidelines of the project.

And BTW, the fact that something is a rule doesn't mean it's good; rules change.

-- 
Felipe Contreras