Re: Recording the current branch on each commit?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Felipe Contreras <felipe.contreras@xxxxxxxxx> wrote:
> 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.

> 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).

> 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.

>> > 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]