From: David Kastrup <hidden> Date: 2016-06-15 23:00:52
Felipe Contreras [off-list ref] writes:
Jeremy Morton wrote:
quoted
Sounds like the default behaviour of "git pull" might not be ideal if
it easily causes these problems.
It's not idea. Virtually everyone agrees with that, even Linus
Torvalds, and we have the patches to fix it, but it's not going to
change.
The Git project doesn't welcome change.
I can think of a few other things that "the Git project" or actually
pretty much everybody doesn't welcome.
It becomes easier to actually change things when communicating in a less
abrasive and destructive manner.
At any rate, releases involve time plans and testing periods.
Personally I think that the automerging behavior of "git pull" is one of
the most stupid traps Git has available for beginning contributors to
make a royal mess of their contributions. It's unbelievable that this
has not been defused a decade ago already.
But it hasn't, and such a change is no longer in a useful time frame for
a 2.0 release. Unless one wants to push back the 2.0 release
considerably for this alone. But then everybody will have a favorite
pet peeve, some likely more justified, some less, that he wants to get
into 2.0. I mean, I just sped up git-blame for serious use cases by a
factor of 3 or so at least, and there will be _no_ API changes and
user-visible consequences with that change.
So what?
If the thing has been important enough to get into 2.0, it has been
important enough to push for it _timely_ so that it had a chance at
considerable testing exposure.
That's what has been done with the "git push" changes. They were put in
timely, with quite a bit of warning about what will change and what
people are supposed to be doing about it. Again: bad enough that it
took as long as that to fix this insanely reckless default. The scale
of the git-pull problem is small in comparison as it only messes up a
single local branch instead of a whole set of upstream branches.
--
David Kastrup
From: Felipe Contreras <hidden> Date: 2016-06-15 23:00:53
David Kastrup wrote:
Felipe Contreras [off-list ref] writes:
quoted
Jeremy Morton wrote:
quoted
Sounds like the default behaviour of "git pull" might not be ideal if
it easily causes these problems.
It's not idea. Virtually everyone agrees with that, even Linus
Torvalds, and we have the patches to fix it, but it's not going to
change.
The Git project doesn't welcome change.
I can think of a few other things that "the Git project" or actually
pretty much everybody doesn't welcome.
It becomes easier to actually change things when communicating in a less
abrasive and destructive manner.
That would make sense if I was the only one with the itch. But I wasn't the
only one, so anybody could take the patches and send them in a less abrasive
maner.
In fact I have been contacted a couple of times privately suggesting me to use
a softer tone in order to get my patches applied, in every time I issue a
challenge. You send the patches, and you follow up the discussion in whatever
tone you see fit, if they get in, I'll accept I'm wrong and use softer tone in
the future. The fact of the matter is that the tone doesn't matter, the patches
don't get in because change is not welcome. Period.
But it hasn't, and such a change is no longer in a useful time frame for
a 2.0 release.
I sent the last version of the series in Octoboer 2013, there was more than
enough time to merge them, or somebody else with more political traction to
pick and finish whatever changes where needed (none).
Unless one wants to push back the 2.0 release considerably for this alone.
Why does it need to be pushed back? Have you looked at the patches? If so, what
is the risk that there will be any problem with them?
I mean, I just sped up git-blame for serious use cases by a factor of 3 or so
at least, and there will be _no_ API changes and user-visible consequences
with that change.
I bet this could get into 2.0, but the big patch has to be split into smaller
patches in order for them to be reviewed properly, and maybe merge a few of
them at a time.
If the thing has been important enough to get into 2.0, it has been
important enough to push for it _timely_ so that it had a chance at
considerable testing exposure.
Really? What important changes does 2.0 have? There's literally nothing of
interest to most users, maybe push.default = simple, but that's it.
--
Felipe Contreras
From: James Denholm <hidden> Date: 2016-06-15 23:00:54
Felipe Contreras [off-list ref] wrote:
David Kastrup wrote:
quoted
It becomes easier to actually change things when communicating in a
less
quoted
abrasive and destructive manner.
That would make sense if I was the only one with the itch. But I wasn't
the
only one, so anybody could take the patches and send them in a less
abrasive
maner.
It's not anybody else's job to take your patches and drizzle them in the
honey of respectable discourse. They're your patches, nobody else is
going to champion them for you.
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. One's views and values aren't correct
just on the virtue of that person having them, and you are no different,
Felipe.
From: Felipe Contreras <hidden> Date: 2016-06-15 23:00:54
James Denholm wrote:
Felipe Contreras [off-list ref] wrote:
quoted
David Kastrup wrote:
quoted
It becomes easier to actually change things when communicating in a less
abrasive and destructive manner.
That would make sense if I was the only one with the itch. But I wasn't the
only one, so anybody could take the patches and send them in a less
abrasive maner.
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.
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; one person
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.
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.
quoted
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?
--
Felipe Contreras
From: James Denholm <hidden> Date: 2016-06-15 23:00:54
Felipe Contreras [off-list ref] wrote:
James Denholm wrote:
quoted
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.
quoted
quoted
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.
From: Felipe Contreras <hidden> Date: 2016-06-15 23:00:54
James Denholm wrote:
Felipe Contreras [off-list ref] wrote:
quoted
James Denholm wrote:
quoted
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",
It's still the same thing. Nobody gets assigned any tasks; people choose their
own tasks, and they might choose tasks that other people were doing.
quoted
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.
No. John might have sent a patch series X, and maybe he didn't explain
correctly how it would benefit the project. Later on Mark finds out how those
patches would be useful for himself and takes upon himself to get them merged,
so he cleans them up and send an updated version with a clear explanation of
how they would be useful.
It's still the same proposal X, but a different person and a different strategy
to get them merged.
In other words, the fact that the community has not yet accepted the merits of
an approach doesn't mean that another person cannot champion it.
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.
It doesn't matter if you want to go hunting and I want to buy bread, either one
of those is better than starving to death.
In the Git project though, we choose to starve to death. Neither were my
patches picked, nor did anybody else step up with a different proposal, we just
did nothing, which is what we always do.
--
Felipe Contreras
From: James Denholm <hidden> Date: 2016-06-15 23:00:54
On 29 April 2014 13:32:29 GMT+10:00, Felipe Contreras [off-list ref] wrote:
James Denholm wrote:
quoted
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 still the same thing. Nobody gets assigned any tasks; people
choose their
own tasks, and they might choose tasks that other people were doing.
Right. Instead of bashing about in the haberdashery of
misinterpretation, allow me to explicitly restate my original
point.
You cannot expect that anybody but yourself is willing to propose,
debate the merits of and otherwise defend patches that you
have authored (herein "your patches", implying
authorship, not ownership).
Some people *may*, but if they do not or do not successfully,
that does not imply the stagnation of the project.
Ultimately, the only person who can ensure that a patch is
championed, and the only person who need feel a
responsibility to, is the author, and that responsibility
is only ever to themselves.
TL,DR: Champion your own patches, don't ask others to.
quoted
quoted
It's not Jeff's patches, they are our patches, they are part of the
project.
quoted
quoted
And it's not unusual for multiple people working on a patch series;
oneperson
quoted
quoted
doing most of the work, another adding tests, another cleaning
updocumentation.
quoted
quoted
It's also no unheard of from a person picking up a patch series
somebody else
quoted
quoted
stopped working on.
This, of course, would be the _other_ case where a proposal's
merits are already known and accepted by the community.
No. John might have sent a patch series X, and maybe he didn't explain
correctly how it would benefit the project. Later on Mark finds out how
those
patches would be useful for himself and takes upon himself to get them
merged,
so he cleans them up and send an updated version with a clear
explanation of
how they would be useful.
It's still the same proposal X, but a different person and a different
strategy
to get them merged.
In other words, the fact that the community has not yet accepted the
merits of
an approach doesn't mean that another person cannot champion it.
As addressed above.
quoted
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
quoted
from a bread shop, it's going to be a difficult task for you to
convince
quoted
us to go hunting.
It doesn't matter if you want to go hunting and I want to buy bread,
either one
of those is better than starving to death.
In the Git project though, we choose to starve to death. Neither were
my
patches picked, nor did anybody else step up with a different proposal,
we just
did nothing, which is what we always do.
Not at all. Hunting may necessitate a negative side
effect, such as betraying vegetarianism, having to go out
into the jungle for five days, risk life and limb, and (worse
yet) sleep in a tent. This is an especially poor decision if we
honestly would prefer a loaf of bread, and we just need to find
a way across the street.
And again, I'm referring to the general case here, but of your
views of what the solution should be clash with what the
community view is, you're not going to be able to convince
the community to go hunting. To tie in with the above, you
sure aren't going to be able to if you don't engage in logical,
calm, reasonable discourse.
Regards,
James.
From: Robin Rosenberg <hidden> Date: 2016-06-15 23:00:54
----- Ursprungligt meddelande -----
Från: "Felipe Contreras" [off-list ref]
Till: "James Denholm" [off-list ref], "Felipe Contreras" [off-list ref]
Kopia: "David Kastrup" [off-list ref], "Jeremy Morton" [off-list ref], "Johan Herland" [off-list ref],
"Git mailing list" [off-list ref]
Skickat: tisdag, 29 apr 2014 5:32:29
Ämne: Re: Recording the current branch on each commit?
James Denholm wrote:
quoted
Felipe Contreras [off-list ref] wrote:
quoted
James Denholm wrote:
quoted
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.
[...]
In the Git project though, we choose to starve to death. Neither were my
patches picked, nor did anybody else step up with a different proposal, we
just
did nothing, which is what we always do.
Just because you are starving, the others may not be. I'll skip dinner today.
Not all people view the world the same way you do. Sometimes they don't "see it"
because they don't share your experience. A year later other people may have come to the
same conclusion as you (or not) and whatever the idea you had may come
from someone else, when the world is ready.
Whining won't help, it will just reduce your credibility, perhaps to the point
that people won't even read a improved proposal if you come up with one.
Remember this is a high volume list, so you don't get much time to explain an idea. It's
a matter of karma.
-- robin
From: Felipe Contreras <hidden> Date: 2016-06-15 23:00:54
James Denholm wrote:
You cannot expect that anybody but yourself is willing to propose,
debate the merits of and otherwise defend patches that you have
authored (herein "your patches", implying authorship, not
ownership).
This is the original comment:
David Kastrup wrote:
quoted
It becomes easier to actually change things when communicating in
a less abrasive and destructive manner.
Which is demonstrably false, as I already explained nobody else could
get these patches in, regarldless of the abrasiveness, or lack
thereof.
My point was that my abrasiveness is not an excuse not to do the
changes, as somebody else could get them in (or a similar proposal).
But they couldn't, because it's a change.
Your point about me not expecting somebody else to defend my patches
is irrelevant; it doesn't have anything to do with the topic, and it's
not relevant in general either.
I didn't ask or expect anybody to defend my patches, my point was that
David Kastrup was wrong; it wouldn't be easier to change things;
because change is simply not welcome.
Ultimately, the only person who can ensure that a patch is
championed, and the only person who need feel a responsibility to,
is the author, and that responsibility is only ever to themselves.
Contributors don't have any responsibility to champion their patches.
It is pro bono work.
I should champion my patches because I want to improve Git, not
because I have a responsibility. And nobody else has any
responsibility either, but if somebody else want to improve Git as
well, they should chamption the patches (or others of their own) as
well.
In the meantime the problem still remains.
quoted
It doesn't matter if you want to go hunting and I want to buy
bread, either one of those is better than starving to death.
Not at all. Hunting may necessitate a negative side effect, such as
betraying vegetarianism, having to go out into the jungle for five
days, risk life and limb, and (worse yet) sleep in a tent. This is
an especially poor decision if we honestly would prefer a loaf of
bread, and we just need to find a way across the street.
You obviously didn't read what I said.
And again, I'm referring to the general case here, but of your
views of what the solution should be clash with what the
community view is, you're not going to be able to convince
the community to go hunting.
I'm not going to convince them to buy bread either.
The community wants to starve to death, and you couldn't convince them
otherwise either.
--
Felipe Contreras