From: Thomas Rast <hidden> Date: 2016-06-15 22:56:51
Felipe Contreras [off-list ref] writes:
Clearly, that's the correct behavior. Why would anybody send a change
that does something other than the correct behavior?
Along the same lines, why would anyone write broken code? Nobody does,
right?
If anyone reads that commit message in more than a few weeks, then it's
because some of the code is *broken*. So the reader is investigating a
situation where there must be a flaw somewhere, and trying to pin down
the source. Having access to the thinking behind each commit means s/he
can more easily verify whether that thinking was correct and still
applies.
And your commit messages do nothing towards that end.
A cursory look^W^Wreview of the messages in fc/remote-hg:
remote-hg: fix bad file paths
Mercurial allows absolute file paths, and Git doesn't like that.
Only describes the problem; no reasoning as to what the chosen solution
is or why it is correct. (I can at least infer the former from the
code, but not the latter.)
remote-hg: show more proper errors
When cloning or pushing fails, we don't want to show a stack-trace.
So what do we show?
It also seems that you do not actually use the import you add, or do
you?
remote-hg: force remote push
Ideally we shouldn't do this, as it's not recommended in mercurial
documentation, but there's no other way to push multiple bookmarks (on
the same branch), which would be the behavior most similar to git.
At the same time, add a configuration option for the people that don't
want to risk creating new remote heads.
This one, for a change, says what it does but doesn't say what problem
it fixes.
I'll refrain from commenting on all the one-line messages, and just
point at this one:
remote-hg: trivial test cleanups
In $DAYJOB the advice is to avoid "trivial" (and similarly "obvious"):
either it *is* trivial, in which case you don't need to point that out,
or you're just trying to handwave over the fact that it's not. Like
this:
git_clone () {
- hg -R $1 bookmark -f -r tip master &&
git clone -q "hg::$PWD/$1" $2
}
Not knowing the code I can only conjecture, but surely there was a
reason that the hg call lived in a function called git_clone? And
surely there must be a good reason why it is no longer needed?
My personal favorite however is this one:
remote-bzr: improve tag handling
revision_history() is deprecated and doesn't do what we want (revno
instead of dotted_revno?).
I don't even know how to parse that question mark. Does it actually ask
a question? Does it mean to imply, by the intonation suggested by a
question mark, "how could anyone ever have been so silly as to use a
revno instead of a dotted_revno"?
By the way, it's easy to find similarly helpful messages in git.git in
the old days. One that I remember stumbling across was:
Add the --color-words option to the diff options family
With this option, the changed words are shown inline. For example,
if a file containing "This is foo" is changed to "This is bar", the diff
will now show "This is " in plain text, "foo" in red, and "bar" in green.
How could it not be obvious how it achieves this to anyone who has read
the ~170 lines of code it adds?
Luckily *that* code was correct and feature-complete right from the
start, so nobody ever had to actually read it to figure out what's going
on.
But that was back in 2006. I should think that git.git has improved
since; when I wrote my first patches in 2008, I was impressed with the
readable history and extensive reviews.
--
Thomas Rast
trast@{inf,student}.ethz.ch
From: Felipe Contreras <hidden> Date: 2016-06-15 22:56:52
On Tue, Apr 16, 2013 at 4:59 AM, Thomas Rast [off-list ref] wrote:
Felipe Contreras [off-list ref] writes:
quoted
Clearly, that's the correct behavior. Why would anybody send a change
that does something other than the correct behavior?
Along the same lines, why would anyone write broken code? Nobody does,
right?
Yes, I should change the subject to:
transport-helper: update remote helper namespace, because that's
exactly the thing we DON'T want to do, the purpose of this patch is to
mess up everything
Suree. I'm willing and knowingly introducing a change that goes
diametrically opposite to what we want.
If anyone reads that commit message in more than a few weeks, then it's
because some of the code is *broken*.
That is irrelevant. Junio said the correct behavior was not described,
when if fact it clearly is. Whether or not the patch has a bug in it
is irrelevant to the fact that the correct behavior is described or
not.
So the reader is investigating a
situation where there must be a flaw somewhere, and trying to pin down
the source. Having access to the thinking behind each commit means s/he
can more easily verify whether that thinking was correct and still
applies.
Sure, and where is the thinking not clear? The remote helper ref is
not updated, so we do update it. How is that not clear?
And your commit messages do nothing towards that end.
Oh, it does. You just don't understand how remote-helper works.
A cursory look^W^Wreview of the messages in fc/remote-hg:
[skipping irrelevant comments]
I'm sorry, did you actually hit an issue that required to look at the
commit message to understand where the issue came from? No? Then I
won't bother with hypotheticals.
If you want to waste your time, by all means, rewrite all my commit
messages with essays that nobody will ever read. I'm not going to do
that for some hypothetical case that will never happen. I'm not going
to waste my time.
Cheers.
--
Felipe Contreras
From: Phil Hord <hidden> Date: 2016-06-15 22:56:52
On Tue, Apr 16, 2013 at 3:04 PM, Felipe Contreras
[off-list ref] wrote:
On Tue, Apr 16, 2013 at 4:59 AM, Thomas Rast [off-list ref] wrote:
quoted
A cursory look^W^Wreview of the messages in fc/remote-hg:
[skipping irrelevant comments]
I'm sorry, did you actually hit an issue that required to look at the
commit message to understand where the issue came from? No? Then I
won't bother with hypotheticals.
If you want to waste your time, by all means, rewrite all my commit
messages with essays that nobody will ever read. I'm not going to do
that for some hypothetical case that will never happen. I'm not going
to waste my time.
This is not a hypothetical. Almost every time I bisect a regression
in git.git, I find the commit message tells me exactly why the commit
did what it did and what the expected result was. I find this to be
amazingly useful. Do I need to show you real instances of that
happening? No. I promise it did, though.
Of course, 99% of the commit messages may never be useful to me or
anyone else. But we do not eschew them altogether. The 1% I have to
rely on are nearly always helpful and clear, and that is the part I
care about.
If you will not waste your time to write a decent commit message, why
do you waste our time asking us to review and accept ill-defined
patches? Here, of course, I use the royal "us" as I do not review
your patches. I do not know why that is; I suppose you patch things
outside of my interests, but it may also be that your patches are
simply incomprehensible by design.
Phil
From: Felipe Contreras <hidden> Date: 2016-06-15 22:56:53
On Tue, Apr 16, 2013 at 5:45 PM, Phil Hord [off-list ref] wrote:
On Tue, Apr 16, 2013 at 3:04 PM, Felipe Contreras
[off-list ref] wrote:
quoted
On Tue, Apr 16, 2013 at 4:59 AM, Thomas Rast [off-list ref] wrote:
quoted
A cursory look^W^Wreview of the messages in fc/remote-hg:
[skipping irrelevant comments]
I'm sorry, did you actually hit an issue that required to look at the
commit message to understand where the issue came from? No? Then I
won't bother with hypotheticals.
If you want to waste your time, by all means, rewrite all my commit
messages with essays that nobody will ever read. I'm not going to do
that for some hypothetical case that will never happen. I'm not going
to waste my time.
This is not a hypothetical. Almost every time I bisect a regression
in git.git, I find the commit message tells me exactly why the commit
did what it did and what the expected result was. I find this to be
amazingly useful. Do I need to show you real instances of that
happening? No. I promise it did, though.
Yes please. Show me one of the instances where you hit a bisect with
any of the remote-hg commits mentioned above by Thomas Rast.
Of course, 99% of the commit messages may never be useful to me or
anyone else. But we do not eschew them altogether. The 1% I have to
rely on are nearly always helpful and clear, and that is the part I
care about.
And how do you know this will be part of the 1%? You don't. How many
times have you tracked regressions in transport helper's import/export
functionality? How many times in remote-hg? How many times has
*anybody* done so?
If you will not waste your time to write a decent commit message, why
do you waste our time asking us to review and accept ill-defined
patches?
Because it *fixes a problem*. And a commit essay doesn't fix any,
because nobody will ever go back in history and wonder, hey, what is
up with this commit. If somebody does, then I will accept that commit
essays are always a must. But it won't happen.
Here, of course, I use the royal "us" as I do not review
your patches. I do not know why that is; I suppose you patch things
outside of my interests, but it may also be that your patches are
simply incomprehensible by design.
Yeah, but that's the thing, if you don't understand the code the
patches are changing, then how can you know the commit message is
sufficient to figure things out when a regression is found? You don't.
You can't.
Let's face the truth, you are advocating for stopping progress on the
name that something might happen sometime in the feature, although
most likely won't. When in reality, it just won't.
And you are not saying "it would be nice to have full commit essay",
you are saying: "without a commit essay this patch should NOT be
merged", even more "without a commit essay this patch should NOT be
considered a cooking patch".
I think the commit message is fine, you don't. So YOU go ahead and
write the proper one. If you don't, all you are doing is being an
impediment to progress.
Cheers.
--
Felipe Contreras
I think the commit message is fine, you don't. So YOU go ahead and
write the proper one. If you don't, all you are doing is being an
impediment to progress.
Hey Felipe. Let's get a few things straightened out first:
- We all act in our selfish interests, and write code to scratch our
personal itches. I don't write code or commit messages for anyone
else, and neither should you.
- However, we're not working in isolation. We have this giant mailing
list where we all post our patches. It's like a bazaar where we
compete against other patches for developer attention and potential
reviewers. In other words, it's a free market, and we're selling our
product: if it fails to sell, will you blame the market or your
product? I write clear code and beautiful commit messages exactly for
this reason: I'm fighting for attention!
- We have to learn to interoperate with others' code and conventions,
if we want to be part of the community. That doesn't mean that we
drown out our individuality, but it means that a our patch series has
to conform to some minimal, loose, and evolving standard. Now, you
can argue that many of the existing conventions are outdated (I do it
all the time), but it cannot change overnight. Your influence on the
community will show up over an extended period of time.
- We are not an old enterprise who blame breakages on a few
individuals, and fire them. We're a community where all of us are
equally responsible for all parts of the code. I am as responsible
for the remote-hg code in master as you are, as I had every
opportunity to review it when the patch series came up on the list. I
might have chosen not to, but that doesn't relieve me of
responsibility.
- We don't practice division of labour. There are no managers,
"testing people", "documentation people", "code-writing people",
"commit-message writing people" etc. Everyone has to do some portion
of all these tasks, although we try to keep the boring work/ technical
debt to a minimum. Don't ask other people to write commit messages
for your code.
From: Felipe Contreras <hidden> Date: 2016-06-15 22:56:53
On Thu, Apr 18, 2013 at 4:19 AM, Ramkumar Ramachandra
[off-list ref] wrote:
Felipe Contreras wrote:
quoted
I think the commit message is fine, you don't. So YOU go ahead and
write the proper one. If you don't, all you are doing is being an
impediment to progress.
Hey Felipe. Let's get a few things straightened out first:
- We all act in our selfish interests, and write code to scratch our
personal itches. I don't write code or commit messages for anyone
else, and neither should you.
- However, we're not working in isolation. We have this giant mailing
list where we all post our patches. It's like a bazaar where we
compete against other patches for developer attention and potential
reviewers. In other words, it's a free market, and we're selling our
product: if it fails to sell, will you blame the market or your
product? I write clear code and beautiful commit messages exactly for
this reason: I'm fighting for attention!
Except the customers are not git developers, it's git users. Git
developers rejecting patches because of the commit message is akin to
distributors rejecting products because they don't like the
transportation packages; they are only hurting themselves, by hurting
their customers.
- We have to learn to interoperate with others' code and conventions,
if we want to be part of the community. That doesn't mean that we
drown out our individuality, but it means that a our patch series has
to conform to some minimal, loose, and evolving standard. Now, you
can argue that many of the existing conventions are outdated (I do it
all the time), but it cannot change overnight. Your influence on the
community will show up over an extended period of time.
And the only way it can change is by discussing.
The only one that gets bitten by fixes not getting merged are git
users, not me. So if a discussion of a commit message impedes the
merging of the commit, I don't get affected, but when we have agreed
to disagree on what constitutes a good message, and the patch is still
on hold, then there's a problem.
- We are not an old enterprise who blame breakages on a few
individuals, and fire them. We're a community where all of us are
equally responsible for all parts of the code. I am as responsible
for the remote-hg code in master as you are, as I had every
opportunity to review it when the patch series came up on the list. I
might have chosen not to, but that doesn't relieve me of
responsibility.
I don't think so. Unless you added your Signed-off-by, you are not.
- We don't practice division of labour. There are no managers,
"testing people", "documentation people", "code-writing people",
"commit-message writing people" etc. Everyone has to do some portion
of all these tasks, although we try to keep the boring work/ technical
debt to a minimum. Don't ask other people to write commit messages
for your code.
I am not. Neither should they ask me to write the commit messages they
want. They can make *suggestions*, and I can reject them.
When two persons have different ideas, often times both are wrong, and
the middle-ground is best, but sometimes a person reaches the
middle-ground, and sometimes one person was right from the start.
But when everyone shares the *assumption* that there is never a commit
message that is too long, you know the wrestling mat of ideas is
rigged. I wonder if I should write a commit message as long as a book
chapter for a one-liner, only to prove a point, but I'm honestly
afraid that it would be committed as is.
And remember what started the conversation; do you think a patch with
a possibly incomplete commit message should not be merged to pu
(proposed updates), shouldn't even be mentioned in the "what's
cooking" mail, and thus shouldn't even be considered "cooking"?
Cheers.
--
Felipe Contreras
Except the customers are not git developers, it's git users. Git
developers rejecting patches because of the commit message is akin to
distributors rejecting products because they don't like the
transportation packages; they are only hurting themselves, by hurting
their customers.
Huh? I certainly don't develop for some "git users" I don't even know
or care about. In this order of precedence, my customers are:
1. Me.
2. People who develop git.git, whom I have to cooperate with.
3. People who exercise git heavily like the linux.git community, as
opposed to some little projects that operate using pull requests on
GitHub.
...
137. People who incidentally choose to use git.
138. People who incidentally choose to use git, but aren't on Linux.
I don't know if Junio or the others share this view, but this is how I
personally operate and I'm very happy.
And nobody is hurting anyone else. Someone wrote some code, and
failed to sell it to the community. That's all happened.
The only one that gets bitten by fixes not getting merged are git
users, not me. So if a discussion of a commit message impedes the
merging of the commit, I don't get affected, but when we have agreed
to disagree on what constitutes a good message, and the patch is still
on hold, then there's a problem.
I think the whole issue of whether your commit message conforms to
some transcendental standard is orthogonal to the issue. Is your
patch getting attention? Has it attracted reviewers, and turned up on
the latest "What's cooking"?
I don't think so. Unless you added your Signed-off-by, you are not.
Okay, so your view differs.
I am not. Neither should they ask me to write the commit messages they
want. They can make *suggestions*, and I can reject them.
Ofcourse you have a right to reject suggestions. The question at the
end of the day doesn't change: did you manage to get people to read
your patch?
When two persons have different ideas, often times both are wrong, and
the middle-ground is best, but sometimes a person reaches the
middle-ground, and sometimes one person was right from the start.
But when everyone shares the *assumption* that there is never a commit
message that is too long, you know the wrestling mat of ideas is
rigged. I wonder if I should write a commit message as long as a book
chapter for a one-liner, only to prove a point, but I'm honestly
afraid that it would be committed as is.
I'm with you, and don't share that assumption. I'm not accusing you
of writing commit messages that don't conform to some "transcendental
standard" either: I didn't look at your patches in the first place,
because the simple Signed-off-by: one-liner in the body didn't really
make me want to read it.
And remember what started the conversation; do you think a patch with
a possibly incomplete commit message should not be merged to pu
(proposed updates), shouldn't even be mentioned in the "what's
cooking" mail, and thus shouldn't even be considered "cooking"?
It's irrelevant what I think or others think. The point is that it
wasn't mentioned. Now, why wasn't it mentioned? Is it because Junio
and the community hate you, and are conspiring against getting your
code merged? Or is it because it didn't catch anyone's eye, and Junio
was waiting for it to happen (as always)?
TL;DR version: Your goal in submitting a patch is to sell it to other
people in the community. If enough people like your patch, it gets
merged (but that is only the second step). Your goal is not to fix
problems for some unknown "users", or argue about some "transcendental
standard". Ofcourse the community shares some view about what a patch
should look like, but you can mould those expectations gradually.
From: Felipe Contreras <hidden> Date: 2016-06-15 22:56:53
On Thu, Apr 18, 2013 at 5:27 AM, Ramkumar Ramachandra
[off-list ref] wrote:
Felipe Contreras wrote:
quoted
Except the customers are not git developers, it's git users. Git
developers rejecting patches because of the commit message is akin to
distributors rejecting products because they don't like the
transportation packages; they are only hurting themselves, by hurting
their customers.
Huh? I certainly don't develop for some "git users" I don't even know
or care about. In this order of precedence, my customers are:
1. Me.
2. People who develop git.git, whom I have to cooperate with.
3. People who exercise git heavily like the linux.git community, as
opposed to some little projects that operate using pull requests on
GitHub.
...
137. People who incidentally choose to use git.
138. People who incidentally choose to use git, but aren't on Linux.
As they are for most open source developers on the planet, not me. I
believe a project is nothing without its users.
And nobody is hurting anyone else. Someone wrote some code, and
failed to sell it to the community. That's all happened.
If remote-hg wasn't available for users, they would be hurt; if stash
wasn't available, if rebase --interactive didn't exist, if there was
no msysgit, if it wasn't so fast, if the object model wasn't so simple
and extensible; users would be hurt. And if users didn't have all
these, there would be less users, and if there were less users, there
would be less developers, and mercurial might have been more popular,
and most repositories you have to work on would be in mercurial, and
you might be developing mercurial right now.
But I won't bother trying to convince you that no project is more
important than its users (in the words of Linus Torvalds), because
most people don't see the big picture.
quoted
I don't think so. Unless you added your Signed-off-by, you are not.
Okay, so your view differs.
quoted
I am not. Neither should they ask me to write the commit messages they
want. They can make *suggestions*, and I can reject them.
Ofcourse you have a right to reject suggestions. The question at the
end of the day doesn't change: did you manage to get people to read
your patch?
No, at the end of the day what matters is: did the users benefit from this?
The answer for this particular patch is no, and it's not my fault.
quoted
When two persons have different ideas, often times both are wrong, and
the middle-ground is best, but sometimes a person reaches the
middle-ground, and sometimes one person was right from the start.
Yeah, but I didn't claim that, I said sometimes one person was right
from the start, no middle-ground.
quoted
But when everyone shares the *assumption* that there is never a commit
message that is too long, you know the wrestling mat of ideas is
rigged. I wonder if I should write a commit message as long as a book
chapter for a one-liner, only to prove a point, but I'm honestly
afraid that it would be committed as is.
I'm with you, and don't share that assumption.
s/everyone/almost everyone/
I'm not accusing you
of writing commit messages that don't conform to some "transcendental
standard" either: I didn't look at your patches in the first place,
because the simple Signed-off-by: one-liner in the body didn't really
make me want to read it.
quoted
And remember what started the conversation; do you think a patch with
a possibly incomplete commit message should not be merged to pu
(proposed updates), shouldn't even be mentioned in the "what's
cooking" mail, and thus shouldn't even be considered "cooking"?
It's irrelevant what I think or others think. The point is that it
wasn't mentioned. Now, why wasn't it mentioned? Is it because Junio
and the community hate you, and are conspiring against getting your
code merged? Or is it because it didn't catch anyone's eye, and Junio
was waiting for it to happen (as always)?
My abridged version of the story is: because Jeff King pointed to an
area of improvement he wasn't even strongly attached to, I agreed to
resubmit, Junio saw that, then I changed my mind, Junio probably
didn't see that, and then he forgot about it.
Then, since it's taboo to suggest that a concise commit message is
fine, a discussion sprung.
TL;DR version: Your goal in submitting a patch is to sell it to other
people in the community.
I disagree.
If enough people like your patch, it gets
merged (but that is only the second step). Your goal is not to fix
problems for some unknown "users", or argue about some "transcendental
standard".
I disagree.
Ofcourse the community shares some view about what a patch
should look like, but you can mould those expectations gradually.
If experience is any guide, doesn't look like that. But I've noticed
that after many months that a patch has been sent people realize that
it's more important to get the damn issue fixed than to have a hugely
verbose commit message...
Cheers.
--
Felipe Contreras
Since you disagreed with the rest, I'll only respond to this part:
Felipe Contreras wrote:
But I won't bother trying to convince you that no project is more
important than its users (in the words of Linus Torvalds), because
most people don't see the big picture.
I didn't say otherwise. What I'm saying is: my personal incentive to
write code does not prioritize the supposed benefit of some unknown
"user" somewhere on the planet above everything else. My personal
incentive prioritizes me, and my immediate circle (ie. the git
community). The benefit propagates outwards to extended circles until
it reaches the people I care least about: incidental end-users.
That's how people are connected: how can I care about distant unknown
people I'm not connected to? The people in the outermost circles
benefit the least, because they didn't get a say in the development.
All they can do is write a rant about it on their blog, and hope that
it gets fixed someday.
You just ditched us, the inner circle of people who care about your
work the most, and are instead trying to convince us that we're
hurting some unknown hypothetical "users" by not merging your code
immediately.
If you think these users are more important to you than we are, then
why are you posting your code on this mailing list? Start your own
project that's focused on satisfying these users. It doesn't even
need to be open source or have a community of reviewers, because all
you care about are users.
Okay, one more segment needs to be responded to.
Felipe Contreras wrote:
If remote-hg wasn't available for users, they would be hurt; if stash
wasn't available, if rebase --interactive didn't exist, if there was
no msysgit, if it wasn't so fast, if the object model wasn't so simple
and extensible; users would be hurt. And if users didn't have all
these, there would be less users, and if there were less users, there
would be less developers, and mercurial might have been more popular,
and most repositories you have to work on would be in mercurial, and
you might be developing mercurial right now.
Flawed logic.
A large number of users doesn't automatically imply good software with
lots of features, or even a great development community. A great
development community leads to great software. And great software
leads to lots of users. Sure, there's a feedback loop pushing users
to become developers; but it doesn't start with users of vaporware,
leading to more developers joining the effort to turn that vaporware
into a great product.
Life doesn't begin with users.
From: Felipe Contreras <hidden> Date: 2016-06-15 22:56:53
On Thu, Apr 18, 2013 at 6:31 AM, Ramkumar Ramachandra
[off-list ref] wrote:
Since you disagreed with the rest, I'll only respond to this part:
Felipe Contreras wrote:
quoted
But I won't bother trying to convince you that no project is more
important than its users (in the words of Linus Torvalds), because
most people don't see the big picture.
I didn't say otherwise. What I'm saying is: my personal incentive to
write code does not prioritize the supposed benefit of some unknown
"user" somewhere on the planet above everything else. My personal
incentive prioritizes me, and my immediate circle (ie. the git
community). The benefit propagates outwards to extended circles until
it reaches the people I care least about: incidental end-users.
If the people that matter most are given the worst prioritization, it
means the prioritization is wrong.
That's how people are connected: how can I care about distant unknown
people I'm not connected to?
It's called empathy.
The people in the outermost circles
benefit the least, because they didn't get a say in the development.
All they can do is write a rant about it on their blog, and hope that
it gets fixed someday.
To the detriment of the project.
You just ditched us, the inner circle of people who care about your
work the most, and are instead trying to convince us that we're
hurting some unknown hypothetical "users" by not merging your code
immediately.
The users are real, the developers that will look retroatcively to the
commit message of this patch are not.
If you think these users are more important to you than we are, then
why are you posting your code on this mailing list?
What other way is there for this code to reach the users?
Start your own
project that's focused on satisfying these users.
Start a new project so I can include a patch that hasn't made it yet
into the "what's cooking" in one week? That's ridiculous.
It doesn't even
need to be open source or have a community of reviewers, because all
you care about are users.
Who said *all* that matters are the users? And even if somebody did,
ultimately a closed source proprietary software doesn't benefit the
users, so either way it has to be open and active to benefit the
users.
--
Felipe Contreras
From: Felipe Contreras <hidden> Date: 2016-06-15 22:56:53
On Thu, Apr 18, 2013 at 6:46 AM, Ramkumar Ramachandra
[off-list ref] wrote:
Okay, one more segment needs to be responded to.
Felipe Contreras wrote:
quoted
If remote-hg wasn't available for users, they would be hurt; if stash
wasn't available, if rebase --interactive didn't exist, if there was
no msysgit, if it wasn't so fast, if the object model wasn't so simple
and extensible; users would be hurt. And if users didn't have all
these, there would be less users, and if there were less users, there
would be less developers, and mercurial might have been more popular,
and most repositories you have to work on would be in mercurial, and
you might be developing mercurial right now.
Flawed logic.
A large number of users doesn't automatically imply good software with
lots of features, or even a great development community. A great
development community leads to great software. And great software
leads to lots of users. Sure, there's a feedback loop pushing users
to become developers; but it doesn't start with users of vaporware,
leading to more developers joining the effort to turn that vaporware
into a great product.
Life doesn't begin with users.
Nobody knows how life began, and it doesn't matter now, what matters
is how life evolves. It doesn't matter if the chicken was first, or
the egg, what matters is that if all the chickens and eggs are gone,
there won't be more.
Plenty of projects have died because they stopped caring about their
users, and without users there's no new developers, and the old
developers eventually move on, and all the literary quality of commit
messages have no eyes to see it.
I repeat: no project is more important than its users.
--
Felipe Contreras
From: Phil Hord <hidden> Date: 2016-06-15 22:56:54
On Wed, Apr 17, 2013 at 2:50 PM, Felipe Contreras
[off-list ref] wrote:
On Tue, Apr 16, 2013 at 5:45 PM, Phil Hord [off-list ref] wrote:
quoted
On Tue, Apr 16, 2013 at 3:04 PM, Felipe Contreras
quoted
quoted
If you want to waste your time, by all means, rewrite all my commit
messages with essays that nobody will ever read. I'm not going to do
that for some hypothetical case that will never happen. I'm not going
to waste my time.
This is not a hypothetical. Almost every time I bisect a regression
in git.git, I find the commit message tells me exactly why the commit
did what it did and what the expected result was. I find this to be
amazingly useful. Do I need to show you real instances of that
happening? No. I promise it did, though.
Yes please. Show me one of the instances where you hit a bisect with
any of the remote-hg commits mentioned above by Thomas Rast.
I made no such claim. In fact, I have never bisected to any
remote-hg-related commit. I fail to see the relevance of this
qualifier, though.
P
From: Felipe Contreras <hidden> Date: 2016-06-15 22:56:54
On Thu, Apr 18, 2013 at 3:06 PM, Phil Hord [off-list ref] wrote:
On Wed, Apr 17, 2013 at 2:50 PM, Felipe Contreras
quoted
Yes please. Show me one of the instances where you hit a bisect with
any of the remote-hg commits mentioned above by Thomas Rast.
I made no such claim. In fact, I have never bisected to any
remote-hg-related commit. I fail to see the relevance of this
qualifier, though.
Here, this is what you said:
You:
Me:
quoted
[skipping irrelevant comments]
I'm sorry, did you actually hit an issue that required to look at the
commit message to understand where the issue came from? No? Then I
won't bother with hypotheticals.
If you want to waste your time, by all means, rewrite all my commit
messages with essays that nobody will ever read. I'm not going to do
that for some hypothetical case that will never happen. I'm not going
to waste my time.
This is not a hypothetical.
If something is not hypothetical, it's real, which means it actually
happened, but then you said you never made the claim that it did. So
what is it? Either it did happen, or it didn't; you cannot have your
cake and eat it.
If you are going to change your claims on the fly, and deny you ever
made them, I don't see much point in discussing with you.
Cheers.
--
Felipe Contreras
From: Phil Hord <hidden> Date: 2016-06-15 22:56:55
On Thu, Apr 18, 2013 at 7:48 PM, Felipe Contreras
[off-list ref] wrote:
On Thu, Apr 18, 2013 at 3:06 PM, Phil Hord [off-list ref] wrote:
quoted
On Wed, Apr 17, 2013 at 2:50 PM, Felipe Contreras
quoted
quoted
Yes please. Show me one of the instances where you hit a bisect with
any of the remote-hg commits mentioned above by Thomas Rast.
I made no such claim. In fact, I have never bisected to any
remote-hg-related commit. I fail to see the relevance of this
qualifier, though.
Here, this is what you said:
You:
quoted
Me:
quoted
[skipping irrelevant comments]
I'm sorry, did you actually hit an issue that required to look at the
commit message to understand where the issue came from? No? Then I
won't bother with hypotheticals.
If you want to waste your time, by all means, rewrite all my commit
messages with essays that nobody will ever read. I'm not going to do
that for some hypothetical case that will never happen. I'm not going
to waste my time.
This is not a hypothetical.
If something is not hypothetical, it's real, which means it actually
happened, but then you said you never made the claim that it did. So
what is it?
My claim:
I bisected to a commit whose commit message helped me deduce its entirety.
Your fanciful interpretation, which I denied:
"Show me one of the instances where you hit a bisect with
any of the remote-hg commits mentioned above by Thomas Rast."
I have never bisected to any commit related to remote-hg, and neither
did I ever claim to. I do not know where you got such a ridiculous
qualifier as this to append to my statement.
Either it did happen, or it didn't;
It did. Where "it" is my actual claim, that I bisected to a commit
whose commit message helped me deduce its entirety.
But also, it didn't, where "it" is your preposterous interpretation of
my interest and/or experiences with remote-hg commits.
You seem only to want to argue, Felipe. I have neither time nor
interest in pig-wrestling, myself.
Phil
From: Felipe Contreras <hidden> Date: 2016-06-15 22:56:55
On Fri, Apr 19, 2013 at 4:07 PM, Phil Hord [off-list ref] wrote:
On Thu, Apr 18, 2013 at 7:48 PM, Felipe Contreras
[off-list ref] wrote:
quoted
If something is not hypothetical, it's real, which means it actually
happened, but then you said you never made the claim that it did. So
what is it?
My claim:
I bisected to a commit whose commit message helped me deduce its entirety.
What a bold claim! That changes everything! Without your valuable
input this discussion would have gone nowhere!
This claim is absolutely worthless, nobody denies that somebody at
some point in time did bisect a commit and a read it's commit message,
and claiming what nobody denies makes as much sense as fighting the
wind.
Thanks for wasting all of our times.
Your fanciful interpretation, which I denied:
"Show me one of the instances where you hit a bisect with
any of the remote-hg commits mentioned above by Thomas Rast."
I have never bisected to any commit related to remote-hg, and neither
did I ever claim to. I do not know where you got such a ridiculous
qualifier as this to append to my statement.
That's *EXACTLY* the topic you replied to. Thomas Rast pointed to
remote-hg commits, I asked if he hit an actual issue that required to
look at the commit message, or such issue was hypothetical.
Then you come along and say it isn't, Well, what isn't? If it's not
the *EXACT* topic we were talking about.
quoted
Either it did happen, or it didn't;
It did. Where "it" is my actual claim, that I bisected to a commit
whose commit message helped me deduce its entirety.
So "it" is absolutely unrelated to what we were talking about, and
"it" was something nobody cared about, nor did help one iota to move
the conversation forward.
Thanks, thanks a lot.
But also, it didn't, where "it" is your preposterous interpretation of
my interest and/or experiences with remote-hg commits.
You seem only to want to argue, Felipe. I have neither time nor
interest in pig-wrestling, myself.
No, I don't want to argue, specially with people that either a) deny
that they argued what they argued, or b) argue with pointless obvious
claims about something that is not being discussed. Whether it's
intellectual dishonesty, or plain madness, I'm not interested.
Hitting an issue that required anybody to look at the commit messages
of the commits that Thomas Rast mentioned, is a hypothetical
situation. *Period*.
Cheers.
--
Felipe Contreras
[off-topic; what happened/happens to your series is entirely unrelated
to the issue]
Felipe Contreras wrote:
Nobody knows how life began, and it doesn't matter now, what matters
is how life evolves. It doesn't matter if the chicken was first, or
the egg, what matters is that if all the chickens and eggs are gone,
there won't be more.
Plenty of projects have died because they stopped caring about their
users, and without users there's no new developers, and the old
developers eventually move on, and all the literary quality of commit
messages have no eyes to see it.
I was a pure end-user of git until about Jan 2010. I was initially
impressed with git because it behaved in a beautiful consistent
manner. Then I dug in and found out that it had a beautiful codebase,
excellent mailing list (content and conventions), and large
development community. I could literally read through the commit
messages and code with ease. I do bounce between a few projects, but
always come back to git because nothing else fits the criterion. What
I do not consider (as much as the other things) is the
number-of-end-users.
Then again, you would argue that I came across git only because of a
large enough user-base. I agree with that, but you're practically
idolizing user-base as the most important thing.
My point is simple: yes, it's nice to have a big user base. We
already do. Now, what's the point of pitching to end-users who only
use the most basic functionality? Their inputs are likely to be
useless (arising from misunderstandings) anyway. They're not going to
be the next developers. And they're not going to help create what our
next developer is looking for in us either (i.e. codebase, community).
Our primary customers are each other, because that's how we get a
tight community and great codebase. And because the next potential
developer looks like one of us.
That does _not_ mean: live only within the community. Everyone should
have a healthy interaction with the outside world, otherwise they risk
turning into researchers and suffering engineering myopia. And
ofcourse not attract a large userbase.
From: Felipe Contreras <hidden> Date: 2016-06-15 22:56:58
On Tue, Apr 23, 2013 at 1:49 PM, Ramkumar Ramachandra
[off-list ref] wrote:
My point is simple: yes, it's nice to have a big user base. We
already do. Now, what's the point of pitching to end-users who only
use the most basic functionality? Their inputs are likely to be
useless (arising from misunderstandings) anyway. They're not going to
be the next developers. And they're not going to help create what our
next developer is looking for in us either (i.e. codebase, community).
That is your mistake right there. They *are* the next developers, you
yourself came from there. We all did.
In fact, this notion that there's a divide between users and
developers is a myth; it's a continuum that follows the Pareto
distribution. It happens in every healthy open source project.
And this is not an assumption, I've measured it:
http://felipec.wordpress.com/2011/11/21/no-project-is-more-important-than-its-users/
70% of the commits in git.git come from people that have provided less
than 6 patches. That 70% (maybe 80%, maybe 90%) would have never
happened, if git didn't have a large enough user-base. I'm not
idolizing the user-base, this project *is* the user-base, developers
are users, and without users there's no project.
Again, in the words of Linus: no project is more important than it's users.
Cheers.
--
Felipe Contreras