Re: Recording the current branch on each commit?

From: James Denholm <nod.helm@gmail.com>
Date: Apr 29, 2014, 01:29 UTC
Message-ID: <CAHYYfeGBLXGgK-cTQLEreFXJakp1jBE829=LrhmKR3MttBiw+A@mail.gmail.com>
In-Reply-To: <535edfb9baa4a_4c5c11c92f0bc@nysa.notmuch>

Felipe Contreras <felipe.contreras@gmail.com> wrote:

Show 6 quoted lines

> James Denholm wrote:
>> It's not anybody else's job to take your patches and drizzle them in the
>> honey of respectable discourse.
>
> It's nobody's job to do anything. This a collaborative effort and in a
> collaborative effort everbody chimes in to do different things.

No, true, but my point was more related to that it's ones own "task", perhaps being the better term than job, to debate the merits of one's own work when the merits are currently unknown to the rest of a community.

Show 5 quoted lines

> It's not Jeff's patches, they are our patches, they are part of the project.
> And it's not unusual for multiple people working on a patch series; oneperson
> doing most of the work, another adding tests, another cleaning updocumentation.
> It's also no unheard of from a person picking up a patch series somebody else
> stopped working on.

This, of course, would be the _other_ case where a proposal's merits are already known and accepted by the community. Different situation.

Note that I here specify a proposal's merits are known and accepted, rather than the issue at hand. I'd be very, very surprised if there was even a few cases in human history where a community was able to collaboratively work, efficiently and successfully, on a proposal where the merits were still hotly discussed (barring, of course, exploratory works).

Show 5 quoted lines

> If a patch series is event considered to be merged upstream, that means it
> doesn't just benefit the person sending it (e.g. me), it benefits all Git
> users.
>
> So "my" patches where by the project and for the project.

And yes, of course, but you misinterpret my use of "one's patches" to describe ownership or who benefits from those patches. I merely discuss authorship and seek not to imply anything more.

Show 11 quoted lines

>> > The fact of the matter is that the tone doesn't matter, the patches don't
>> > get in because change is not welcome. Period.
>>
>> You neglect the possibility that your personal view of what git should
>> be differs from other people's.
>
> Except that in this case virtually everyone agreed the default was wrong. I
> already said that.
>
> Clarly you didn't read the relevant discussions where everyone, including Linus
> Torvalds, agreed. Did you?

I'm talking about the general case, not a _specific_ patch or set thereof authored by you or any one person.

Again, though, recall that even if a community has agreed that the current state is non-ideal, that doesn't mean that they agree that a _specific proposal_ is the right one. If A and B agree that they are starving to death, and B proposes they engage in hunting to resolve this, A might disagree because he'd rather just go across the street and buy a loaf of bread.

Although as I write this it seems Junio has described this exact thing in a following mail, and on the following debate:

A patch relates to more than a personal view of what a project shouldn't be. Even if it's solving an acknowledged problem, it by it's nature relates to a view of what the solution should be.

Ergo, in the specific case, your view of what the solution should have been did not match the community's view of the same, even if the overall problem was acknowledged by the entire community.

The default may be wrong, you and I might agree that the default is wrong, Junio and Torvalds and RMS and The Queen of England might all agree that the default is wrong... But if we all live across from a bread shop, it's going to be a difficult task for you to convince us to go hunting.

Sincerely and analogically yours, James Denholm.