My patches

My patches

[Felipe Contreras]

Hi,

Clearly, a lot of my patches have not been reviewed properly, so even
though they are technically correct, and would benefit users, some have
specifically been requested by them, and at least one would
significantly improve Git's user interface... they are going nowhere.

Here is the summary, and you can also find a web version:
https://github.com/felipec/git/wiki/My-patches

Cheers.

=== branch: improve verbose option ===

People have commented that this is a good change, yet it's ignored.

----
Felipe Contreras (2):
      branch: trivial cleanup
      branch: reorganize verbose options
----

Link: https://github.com/felipec/git/commits/fc/branch/fast +
Patches: http://mid.gmane.org/1381561229-19947-1-git-send-email-felipe.contreras@gmail.com +

=== Reject non-ff pulls by default (v4) ===

The conclusion of the discussions is that this change is good, yet it doesn't move forward.

----
Felipe Contreras (7):
      pull: rename pull.rename to pull.mode
      pull: refactor $rebase variable into $mode
      pull: add --merge option
      pull: add merge-ff-only option
      pull: add warning on non-ff merges
      pull: cleanup documentation
      pull: add documentation about non-ff merges
----

Link: https://github.com/felipec/git/commits/fc/pull-merge-ff-only +
Patches: http://mid.gmane.org/1381561322-20059-1-git-send-email-felipe.contreras@gmail.com +

=== remote-helpers: test reorganization (v2) ===

People have requested both that the scripts are autogenerated, and that we
provide instructions how to install these for distributions, this fixes both,
and yet is not merged.

----
Felipe Contreras (5):
      remote-helpers: generate scripts
      build: fix installation of scripts
      remote-helpers: rename tests
      remote-helpers: allow direct test execution
      remote-helpers: add exec-path links
----

Link: https://github.com/felipec/git/commits/fc/remote/reorg +
Patches: http://mid.gmane.org/1381561465-20147-1-git-send-email-felipe.contreras@gmail.com +

=== build: add default aliases (v3) ===

All version control systems out there have default aliases, except Git.
Mercurial even allows overriding the main commands, like 'hg commit' so all the
arguments that use the override of default aliases causing discrepancies as a
reason to reject this change are void, since clearly Mercurial doesn't have
such problems.

----
Felipe Contreras (1):
      build: add default aliases
----

Link: https://github.com/felipec/git/commits/fc/default-aliases +
Patches: http://mid.gmane.org/1381561482-20208-1-git-send-email-felipe.contreras@gmail.com +

=== Add core.mode configuration (v3) ===

Not even a reply.

----
Felipe Contreras (1):
      Add core.mode configuration
----

Link: https://github.com/felipec/git/commits/fc/config-mode-next +
Patches: http://mid.gmane.org/1381561485-20252-1-git-send-email-felipe.contreras@gmail.com +

=== Officially start moving to the term 'staging area' ===

Everybody agrees this is the way to go, and yet Junio doesn't comment on the way
forward.

----
Felipe Contreras (14):
      Add proper 'stage' command
      stage: add edit command
      diff: document --staged
      grep: add --staged option
      rm: add --staged option
      stash: add --stage option to save
      stash: add --stage to pop and apply
      submodule: add --staged options
      apply: add --stage option
      apply: add --work, --no-work options
      completion: update --staged options
      reset: add --stage and --work options
      reset: allow --keep with --stage
      completion: update 'git reset' new stage options
----

Link: https://github.com/felipec/git/commits/fc/stage +
Patches: http://mid.gmane.org/1381561488-20294-1-git-send-email-felipe.contreras@gmail.com +

=== transport-helper: updates (v3) ===

People have requested --foce --dry-run and old:new support for remote helpers,
this introduces those options and it was rejected without any reason given.

----
Felipe Contreras (10):
      transport-helper: add 'force' to 'export' helpers
      transport-helper: fix extra lines
      transport-helper: check for 'forced update' message
      fast-export: improve argument parsing
      fast-export: add new --refspec option
      transport-helper: add support for old:new refspec
      fast-import: add support to delete refs
      fast-export: add support to delete refs
      transport-helper: add support to delete branches
      transport-helper: don't update refs in dry-run
----

Link: https://github.com/felipec/git/commits/fc/transport/improv +
Patches: http://mid.gmane.org/1381561533-20381-1-git-send-email-felipe.contreras@gmail.com +

=== Introduce publish tracking branch ===

This improves the support for triangular workflows, which even Junio accepted
is lacking, yet it didn't even receive comments.

----
Felipe Contreras (8):
      branch: trivial cleanup
      branch: reorganize verbose options
      push: trivial reorganization
      Add concept of 'publish' branch
      branch: allow configuring the publish branch
      t: branch add publish branch tests
      push: add --set-publish option
      branch: display publish branch
----

Link: https://github.com/felipec/git/commits/fc/publish +
Patches: http://mid.gmane.org/1381561561-20459-1-git-send-email-felipe.contreras@gmail.com +

=== New git-related helper (v10) ===

This series was included in 'pu' and then silently dropped with no reason
given. 'git contacts' implements a rudimentary version of this, but lacks all
the features. I started an external project as a result.

----
Felipe Contreras (15):
      Add new git-related helper to contrib
      contrib: related: add tests
      contrib: related: add support for multiple patches
      contrib: related: add option to parse from committish
      contrib: related: parse committish like format-patch
      contrib: related: print the amount of involvement
      contrib: related: add helper Person classes
      contrib: related: show role count
      contrib: related: add support for more roles
      contrib: related: group persons with same email
      contrib: related: allow usage on other directories
      contrib: related: add mailmap support
      contrib: related: add option parsing
      contrib: related: add option to show commits
      contrib: related: add README
----

Link: https://github.com/felipec/git/commits/fc/related +
Patches: http://mid.gmane.org/1381561584-20529-1-git-send-email-felipe.contreras@gmail.com +

=== fetch: add new fetch.default configuration ===

No response whatsoever, even after a thorough expalanation of the issue.
'git fetch .' is still braindead.

----
Felipe Contreras (1):
      fetch: add new fetch.default configuration
----

Link: https://github.com/felipec/git/commits/fc/fetch/default +
Patches: http://mid.gmane.org/1381561625-20624-1-git-send-email-felipe.contreras@gmail.com +

=== Version fixes and cleanups (v4) ===

Our git.spec is clearly broken for release candidates, and yet the patch
doesn't receive feedback.

----
Felipe Contreras (2):
      version-gen: cleanup
      version-gen: fix versions
----

Link: https://github.com/felipec/git/commits/fc/version-fix +
Patches: http://mid.gmane.org/1381561628-20665-1-git-send-email-felipe.contreras@gmail.com +

=== Trivial paches ===

----
Felipe Contreras (20):
      merge: simplify ff-only option
      t: replace pulls with merges
      pull: cleanup documentation
      fetch: add missing documentation
      remote: fix trivial memory leak
      revision: add missing include
      shortlog: add missing declaration
      branch: trivial style fix
      sha1-name: trivial style cleanup
      doc: git-foo was obsoleted several years ago
      symbolic-ref: trivial style fix
      alias: trivial style fix
      transport-helper: trivial style fix
      describe: trivial style fixes
      pretty: trivial style fix
      revision: trivial style fixes
      diff: trivial style fix
      run-command: trivial style fixes
      setup: trivial style fixes
      add: avoid yoda conditions
----

Patches: http://mid.gmane.org/1381561636-20717-1-git-send-email-felipe.contreras@gmail.com +

=== Massive improvents to rebase and cherry-pick (v6) ===

People make a fuss that Ruby support is no-go because we need to move scripts
to C, and when somebody does the work for that, the work gets ignored, even
though it's fixing and simplyfing code.

----
Felipe Contreras (28):
      cherry-pick: don't barf when there's nothing to do
      cherry-pick: add --skip-empty option
      revert/cherry-pick: add --quiet option
      revert/cherry-pick: add --skip option
      builtin: add rewrite helper
      cherry-pick: store rewritten commits
      cherry-pick: don't store skipped commit
      builtin: move run_rewrite_hook() to rewrite.c
      builtin: rewrite: add copy_rewrite_notes()
      cherry-pick: add --action-name option
      cherry-pick: copy notes and run hooks
      cherry-pick: remember rerere-autoupdate
      rebase: split the cherry-pick stuff
      rebase: cherry-pick: fix mode storage
      rebase: cherry-pick: fix sequence continuation
      rebase: cherry-pick: fix abort of cherry mode
      rebase: cherry-pick: fix command invocations
      rebase: cherry-pick: fix status messages
      rebase: cherry-pick: automatically commit stage
      rebase: cherry-pick: set correct action-name
      rebase: trivial cleanup
      t: rebase-autostash: fix setup
      sequencer: store progress information
      prompt: parse cherry-pick rebase mode
      rebase: use 'cherrypick' mode instead of 'am'
      rebase: cherry-pick: add merge options
      rebase: remove merge mode
      rebase: cherry-pick: add copyright
----

Link: https://github.com/felipec/git/commits/fc/rebase +
Patches: http://mid.gmane.org/1377842182-18724-1-git-send-email-felipe.contreras@gmail.com +

=== Support for Ruby (v2) ===

Ruby is clearly the way to move forward to replace shell and perl scripts with
C, with a similar syntax to all three, and yet this comprehensive patch series
doesn't even receive a response.

----
Felipe Contreras (44):
      Add support for ruby commands
      ruby: add support for internal ruby programs
      request-pull: fix annotated tag check
      request-pull: fix for specific branch
      request-pull: use appropriate ref
      request-pull: fix exact match checking
      request-pull: trivial simplification
      request-pull: t: trivial whitespace style fixes
      request-pull: t: add missing cat
      ruby: rewrite 'request-pull'
      ruby: request-pull: rewrite perl script
      ruby: request-pull: trivial simplifications
      ruby: bind setup_git_directory()
      ruby: bind dwim_ref()
      ruby: request-pull: use native dwim_ref()
      ruby: bind git_config()
      ruby: request-pull: use native git_config()
      ruby: bind read_ref()/peel_ref()
      ruby: bind get_sha1()
      ruby: request-pull: simplify tag fetching
      ruby: request-pull: use get_sha1()
      ruby: add Commit class
      ruby: bind get_merge_bases()
      ruby: request-pull: use get_merge_bases()
      ruby: request-pull: trivial cleanups
      ruby: bind remote and transport stuff
      ruby: request-pull: use native remote and transport
      ruby: bind find_unique_abbrev()
      ruby: request-pull: use native commit info
      ruby: bind read_sha1_file()
      ruby: request-pull: use read_sha1_file()
      revision: add missing include
      shortlog: add missing declaration
      shortlog: split builtin from common code
      ruby: add RevInfo and DiffOptions
      ruby: bind shortlog()
      ruby: request-pull: use shortlog()
      ruby: bind diff_tree_sha1()
      ruby: bind log_tree_diff_flush()
      ruby: request-pull: use native diff_tree stuff
      ruby: request-pull: remove rescue block
      ruby: remove GIT_PAGER from environment
      ruby: add simpler option parser
      request-pull: rewrite to C
----

Link: https://github.com/felipec/git/commits/fc/ruby +
Patches: http://mid.gmane.org/1380405849-13000-11-git-send-email-felipe.contreras@gmail.com +

=== revision: add --except option (v3) ===

All comments were addressed, yet there doesn't seem to be any path forward.

----
Felipe Contreras (1):
      revision: add --except option
----

Link: https://github.com/felipec/git/commits/fc/revision/except +
Patches: http://mid.gmane.org/1381561690-20827-1-git-send-email-felipe.contreras@gmail.com +

=== sha1-name: refactor get_sha1() parsing ===

Duy Nguyen suggested that I do this, and now that I do the first step, the work gets ignored.

----
Felipe Contreras (1):
      sha1-name: refactor get_sha1() parsing
----

Link: https://github.com/felipec/git/commits/fc/revision/refactor +
Patches: http://mid.gmane.org/1381561692-20869-1-git-send-email-felipe.contreras@gmail.com +

-- 
Felipe Contreras

Re: My patches

[Philip Oakley]

From: "Felipe Contreras" <felipe.contreras@gmail.com>
Sent: Saturday, October 12, 2013 8:24 AM
> Hi,
>
> Clearly, a lot of my patches have not been reviewed properly, so even
> though they are technically correct, and would benefit users, some 
> have
> specifically been requested by them, and at least one would
> significantly improve Git's user interface...

Hi Filipe,

Given you have put a lot of work into your 16 patch series, is there any 
particular order, or grouping that would help their review.

With so many patches to consider one (the reviewer(s)) gains another 
task of simply trying to prioritise the patches (usually one can take 
big decisions by simply remebering who's series one was interested in).

I expect the clean-ups and 'trivials's' can be managed separately from 
the 'improvements', which would again be separate from the "satging" and 
"Ruby" philosophical discussions.

>   they are going nowhere.
I wouldn't expect 100% success. Every now and again one hears of the 
"here's some patches I've had in my tree for a while" that probably had 
the same early frustrations - they just feel worse the more you produce.

>
> Here is the summary, and you can also find a web version:
> https://github.com/felipec/git/wiki/My-patches
>
> Cheers.
>

Thanks for the summary.
 Philip

> === branch: improve verbose option ===
> Felipe Contreras (2):
> === Reject non-ff pulls by default (v4) ===
> Felipe Contreras (7):
> === remote-helpers: test reorganization (v2) ===
> Felipe Contreras (5):
> === build: add default aliases (v3) ===
> Felipe Contreras (1):
> === Add core.mode configuration (v3) ===
> Felipe Contreras (1):
> === Officially start moving to the term 'staging area' ===
> Felipe Contreras (14):
> === transport-helper: updates (v3) ===
> Felipe Contreras (10):
> === Introduce publish tracking branch ===
> Felipe Contreras (8):
> === New git-related helper (v10) ===
> Felipe Contreras (15):
> === fetch: add new fetch.default configuration ===
> Felipe Contreras (1):
> === Version fixes and cleanups (v4) ===
> Felipe Contreras (2):
> === Trivial paches ===
> Felipe Contreras (20):
> === Massive improvents to rebase and cherry-pick (v6) ===
> Felipe Contreras (28):
> === Support for Ruby (v2) ===
> Felipe Contreras (44):
> === revision: add --except option (v3) ===
> Felipe Contreras (1):
> === sha1-name: refactor get_sha1() parsing ===
> Felipe Contreras (1):
>      sha1-name: refactor get_sha1() parsing
> -- 
> Felipe Contreras
> --

Re: My patches

[Felipe Contreras]

On Sat, Oct 12, 2013 at 11:18 AM, Philip Oakley <philipoakley@iee.org> wrote:
> From: "Felipe Contreras" <felipe.contreras@gmail.com>
> Sent: Saturday, October 12, 2013 8:24 AM

>> Clearly, a lot of my patches have not been reviewed properly, so even
>> though they are technically correct, and would benefit users, some have
>> specifically been requested by them, and at least one would
>> significantly improve Git's user interface...
>

> Given you have put a lot of work into your 16 patch series, is there any
> particular order, or grouping that would help their review.

I ordered them in order of importance, and chance of being merged. For
example, the first patch series 'branch: improve verbose option' is
relatively simple, it improves things significantly, and other
developers have already argued this is the way to go. The last one
'sha1-name: refactor get_sha1() parsing' doesn't have much of a chance
of being merged, it's quite complicated, there isn't any particular
change that is visible to the users, and there isn't probably much
interest.

> With so many patches to consider one (the reviewer(s)) gains another task of
> simply trying to prioritise the patches (usually one can take big decisions
> by simply remebering who's series one was interested in).
>
> I expect the clean-ups and 'trivials's' can be managed separately from the
> 'improvements', which would again be separate from the "satging" and "Ruby"
> philosophical discussions.

Maybe, but the trivial patches have a higher chance of being merged
than 'Massive improvents to rebase and cherry-pick' or 'Support for
Ruby', that's why I put them first.

>>   they are going nowhere.
>
> I wouldn't expect 100% success. Every now and again one hears of the "here's
> some patches I've had in my tree for a while" that probably had the same
> early frustrations - they just feel worse the more you produce.

Yeah, I'm aware of that, I have contributed to lots of open source
projects. However, we are not talking about a couple of patches that
now and again get lost, we are talking about 160 patches, some which
have gone through several (even ten) iterations. I think that is
different.

Cheers.

-- 
Felipe Contreras

Re: My patches

[Junio C Hamano]

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

> Clearly, a lot of my patches have not been reviewed ...

I think the reason for it most likely is because you earned the Bozo
bit ($gmane/227602) in many reviewers' eyes.

I phrased it differently ($gmane/233347) at the beginning of this
cycle, but I'll say it one more time. I'll refrain from responding
to your messages with anything other than "looks good, thanks". A
patch from you that I do not understand the motivation behind it, or
a patch from you that attempts to solve a problem I see better ways
of solving the same, will not see the usual response from me that
requests a clarification (in the resulting code or in its
explanation in the proposed commit log message) or suggests an
improvement or an alternative.

Such a review comment and the discussion that follows it after a
patch is posted is an essential part of the collaborative
development process in this community and it has helped the quality
of our end product. We unfortunately saw time and again that the
process rarely works when the discussion involves your patches. A
review thread tends not to conclude with a useful patch but instead
descends into an unproductive centithread, frustrating reviewers and
discouraging other people from participating, and ends up draining
the energy from everybody involved, which is better spent elsewhere
to do the real work. It may be reviewers' fault (cf. $gmane/235277),
or maybe the blame lies elsewhere, but it does not change the fact
that we end up wasting a lot of energy without going anywhere.

In short, responding to your patch that is not a simple "looks good,
thanks" material wastes time, harming the community and hurting our
users. That was exactly the reason why you earlier were asked to
leave ($gmane/227750). So I'll try not to respond to them.

I haven't caught up with the list traffic yet, but the way the
discussion that followed a recent review ($gmane/235936) progressed
tells me that things haven't improved much, so the assessment above
still seems to hold true, at least to me.

Re: My patches

[Felipe Contreras]

Junio C Hamano wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
> 
> > Clearly, a lot of my patches have not been reviewed ...
> 
> I think the reason for it most likely is because you earned the Bozo
> bit ($gmane/227602) in many reviewers' eyes.

So what you are saying is that the reason is entirely personal, not technical.
Is that correct?

However, it is funny how Theodore Ts'o is saying so in that mail, yet at the
same time he is actively engaged in at least two discussions started by me in
two different projects (Linux and isync) just last week.

> I phrased it differently ($gmane/233347) at the beginning of this
> cycle,

You said:

---
It seems that Matthew is trying to see if you can work better with
others than before after a break, but I personally am not hopeful
yet and do not want to waste my/our time on flamewars like we saw in
the past.
---

By which you presumably are referring to this patch series:

http://thread.gmane.org/gmane.comp.version-control.git/233295/focus=233306

It seems to me there's no negative fallout from that thread, and Matthieu Moy
still thinks this is a good series, yet you haven't applied it, or even
commented on it.

> but I'll say it one more time. I'll refrain from responding
> to your messages with anything other than "looks good, thanks". A
> patch from you that I do not understand the motivation behind it, or
> a patch from you that attempts to solve a problem I see better ways
> of solving the same, will not see the usual response from me that
> requests a clarification (in the resulting code or in its
> explanation in the proposed commit log message) or suggests an
> improvement or an alternative.

So, what you are saying is that if none of my 160 patches have been picked yet,
it means you will not be picking them, even though you are not explicitly
saying so. Is that correct?

Even if other Git developers agree it's a good change, you will not be picking
them. Correct?

> Such a review comment and the discussion that follows it after a
> patch is posted is an essential part of the collaborative
> development process in this community and it has helped the quality
> of our end product. We unfortunately saw time and again that the
> process rarely works when the discussion involves your patches.

No, you did not. What you saw was a person that unlike a trained dog, argued
against you. And apparently your definition of a good discussion is one in
which the other person just does what you say, and doesn't argue back.

Let me be clear; what I did is provide arguments against your arguments, which
means all I did was disagree. That is all.

> I haven't caught up with the list traffic yet, but the way the
> discussion that followed a recent review ($gmane/235936) progressed
> tells me that things haven't improved much, so the assessment above
> still seems to hold true, at least to me.

I applied the change requested in ($gmane/235936), so there is no more comments
left on that series, there's nothing that prevents that series from being
picked, yet it's not.

Presumably you have a problem with that series, but you haven't spoken, and you
won't, even though it's not just me that is waiting for a response, but other
Git developers (and users) who are interested in moving this forward.

Anyway, I spent a lot of time working on those 160 patches, I would appreciate
if you could respond to this single question:

Are the patches going to be applied? Yes or no.

-- 
Felipe Contreras

Re: My patches

[Junio C Hamano]

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

> Junio C Hamano wrote:
>> Such a review comment and the discussion that follows it after a
>> patch is posted is an essential part of the collaborative
>> development process in this community and it has helped the quality
>> of our end product. We unfortunately saw time and again that the
>> process rarely works when the discussion involves your patches.
>
> No, you did not. What you saw was a person that unlike a trained dog, argued
> against you. And apparently your definition of a good discussion is one in
> which the other person just does what you say, and doesn't argue back.

That is so untrue that it is not even funny.  If the ultimate goal
of your whining is to spread misinformation to make you look like a
victim, you are not worth talking to.

Contributors often make sensible counter-arguments and/or explain
the rationale better than they did in their original messages, and
then receive a "Thanks for a dose of sanity" (or an equivalent
phrased in different ways).

Re: My patches

[Felipe Contreras]

Junio C Hamano wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
> 
> > Junio C Hamano wrote:
> >> Such a review comment and the discussion that follows it after a
> >> patch is posted is an essential part of the collaborative
> >> development process in this community and it has helped the quality
> >> of our end product. We unfortunately saw time and again that the
> >> process rarely works when the discussion involves your patches.
> >
> > No, you did not. What you saw was a person that unlike a trained dog, argued
> > against you. And apparently your definition of a good discussion is one in
> > which the other person just does what you say, and doesn't argue back.
> 
> That is so untrue that it is not even funny.

It is true, and there's penty of evidence that proves it.

Every single time that you get mad at me, it's because I disagree with you.

> Contributors often make sensible counter-arguments and/or explain
> the rationale better than they did in their original messages, and
> then receive a "Thanks for a dose of sanity" (or an equivalent
> phrased in different ways).

Yes, when there's an agreement, so you are basically proving what I said. I
disagree with you, you disagree with me, and that means I'm the problem.

In any healthy collaborative project that simply means there was a
disagreement, and that's that.

-- 
Felipe Contreras

Re: My patches

[Max Horn]

[-- Attachment #1: Type: text/plain, Size: 4417 bytes --]

I guess most other people keep out of this because they are sensible enough to not feed the troll, and instead focus on useful things. But I can't help it, I have to say this.


On 17.10.2013, at 23:44, Felipe Contreras <felipe.contreras@gmail.com> wrote:

> Junio C Hamano wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>> 
>>> Junio C Hamano wrote:
>>>> Such a review comment and the discussion that follows it after a
>>>> patch is posted is an essential part of the collaborative
>>>> development process in this community and it has helped the quality
>>>> of our end product. We unfortunately saw time and again that the
>>>> process rarely works when the discussion involves your patches.
>>> 
>>> No, you did not. What you saw was a person that unlike a trained dog, argued
>>> against you. And apparently your definition of a good discussion is one in
>>> which the other person just does what you say, and doesn't argue back.
>> 
>> That is so untrue that it is not even funny.
> 
> It is true, and there's penty of evidence that proves it.

No, it is not true, and there is plenty of evidence that proves it.

But I don't think it's helpful for either of us drag up such "evidence", as it'll convince nobody -- indeed, I am sure almost everybody here has already formed a clear opinion on this matter. And I hazard to guess that the vast majority agree with Junio on this (based, again, on email evidence). Not with you.

Of course one can't prove mathematical theorems by a majority vote, but as we are not talking about theorems, but rather about judging whether Junion's behavior is considered fair or not, I think it is appropriate to. Moreover, if I look at e.g. the "staging area" discussion, you also bring up the "everybody but Junio and one other guy" argument (incorrectly generalizing from "those people on this mailing list who chose to reply" to "everybody"), so I think I am entitled to do the same ;-).

(BTW, I am actually in favor of using the term "staging area" over "index")


> Every single time that you get mad at me, it's because I disagree with you.

I have not yet seen Junio get "mad" here, even in discussions with you were I think most other people would indeed have gotten "mad" at you. He stays remarkably polite, despite the insults and dirt you keep flinging at him... If at all, it would seem that you are getting mad at Junio.


> 
>> Contributors often make sensible counter-arguments and/or explain
>> the rationale better than they did in their original messages, and
>> then receive a "Thanks for a dose of sanity" (or an equivalent
>> phrased in different ways).
> 
> Yes, when there's an agreement, so you are basically proving what I said. I
> disagree with you, you disagree with me, and that means I'm the problem.

Actually, it is more like this: "Felipe disagrees with Junio, Junio disagrees with Felipe, Felipe insults Junio and in passing half a dozen other people." It is the latter point which makes the situation asymmetric, and indeed indicates you as the problem.

> In any healthy collaborative project that simply means there was a
> disagreement, and that's that.

If your premise was correct (that there is simply a disagreement), then this conclusion might be correct. As it is, though, your premise is false. The problem is rather a disruptive person: you. Quite sad, since you seem to have some good ideas and code contributions! I am in particular grateful for your work on remote helpers, both on specific ones (git-remote-hg) and also on improving the whole remote helper interface. I hope some of this work can eventually be merged...

But at the end of the day, we most (all?) of us here are volunteers, and unlike what you seem to claim a lot, for most of us, making git better is *not* the number 1 priority in our lives... In particular, if working with you would make git better, but at the same time would give me ulcers, well, my choice is clear to me... Perhaps it wouldn't be best for git, but I don't think anybody (except, perhaps, you) would blame me for it. Or, for that matter, Junio. 


@Junio: Thank you for being an opinionated but also very fair project lead, who listens to *constructive* feedback, and has again and again demonstrated through action a readiness to revise a position based on sensible discussions conducted on this list.



Max

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 235 bytes --]

Re: My patches

[Felipe Contreras]

Max Horn wrote:
> I guess most other people keep out of this because they are sensible enough
> to not feed the troll, and instead focus on useful things. But I can't help
> it, I have to say this.

You should probably read the definition of troll:

https://en.wikipedia.org/wiki/Troll_(Internet)

Unless you think that contributing useful patches to Git is off-topic, a person
that does that by definition cannot be a troll.

> On 17.10.2013, at 23:44, Felipe Contreras <felipe.contreras@gmail.com> wrote:
> > Junio C Hamano wrote:
> >> Felipe Contreras <felipe.contreras@gmail.com> writes:
> >>> Junio C Hamano wrote:
> >>>> Such a review comment and the discussion that follows it after a
> >>>> patch is posted is an essential part of the collaborative
> >>>> development process in this community and it has helped the quality
> >>>> of our end product. We unfortunately saw time and again that the
> >>>> process rarely works when the discussion involves your patches.
> >>> 
> >>> No, you did not. What you saw was a person that unlike a trained dog, argued
> >>> against you. And apparently your definition of a good discussion is one in
> >>> which the other person just does what you say, and doesn't argue back.
> >> 
> >> That is so untrue that it is not even funny.
> > 
> > It is true, and there's penty of evidence that proves it.
> 
> No, it is not true, and there is plenty of evidence that proves it.
> 
> But I don't think it's helpful for either of us drag up such "evidence", as
> it'll convince nobody -- indeed, I am sure almost everybody here has already
> formed a clear opinion on this matter.

That's why I didn't bring it up.

> And I hazard to guess that the vast majority agree with Junio on this (based,
> again, on email evidence). Not with you.

That is irrelevant, and a fallacy. The vast majority of people thought the
Earth was the center of the universe, and they were all wrong.

It's called ad populum fallacy, look it up. Wether the majority of Git
developers agree that there's something more than a disagreement is irrelevant,
their opinion doesn't change the truth.

And by the way, a disregard for evidence is a clear sign of a person that is
not interested in the truth.

> Of course one can't prove mathematical theorems by a majority vote, but as we
> are not talking about theorems, but rather about judging whether Junion's
> behavior is considered fair or not, I think it is appropriate to.

No, that's not what we are talking about.

My claim is that all I did was disagree with Junio. You can invalidate that
claim easily by providing *a single* example where I did more than disagree.

> Moreover, if I look at e.g. the "staging area" discussion, you also bring up
> the "everybody but Junio and one other guy" argument (incorrectly
> generalizing from "those people on this mailing list who chose to reply" to
> "everybody"), so I think I am entitled to do the same ;-).

I've stated multiple times that by "everybody" I mean "virtually everybody".
Since Junio has accepted that "the index" is not the best term, "virtually
everybody" is actually everybody that has voiced an opinion, except one single
person.

> > Every single time that you get mad at me, it's because I disagree with you.
> 
> I have not yet seen Junio get "mad" here, even in discussions with you were I
> think most other people would indeed have gotten "mad" at you.

I can provide the evidence when Junio has become clearly "mad"... If you are
interested in the truth that is.

> He stays remarkably polite, despite the insults and dirt you keep flinging at
> him...  If at all, it would seem that you are getting mad at Junio.

That is pure libel. Show me *one* example where I threw an insult, or "dirt".

> >> Contributors often make sensible counter-arguments and/or explain
> >> the rationale better than they did in their original messages, and
> >> then receive a "Thanks for a dose of sanity" (or an equivalent
> >> phrased in different ways).
> > 
> > Yes, when there's an agreement, so you are basically proving what I said. I
> > disagree with you, you disagree with me, and that means I'm the problem.
> 
> Actually, it is more like this: "Felipe disagrees with Junio, Junio disagrees
> with Felipe, Felipe insults Junio and in passing half a dozen other people."

Lies. When did I insult anybody?

> > In any healthy collaborative project that simply means there was a
> > disagreement, and that's that.
> 
> If your premise was correct (that there is simply a disagreement), then this
> conclusion might be correct. As it is, though, your premise is false.

Evidence, or that claim is dismissed.

That which can be asserted without evidence can be dismissed without evidence.

> The problem is rather a disruptive person: you.

Nelson Mandela was considered a "disruptive person" (a terrorist[1]), yet
virtually everyone agrees that the problem was not him, but the system that
labeled him as such.

[1] http://en.wikinews.org/wiki/Nelson_Mandela_taken_off_US_terrorist_list

-- 
Felipe Contreras

Re: My patches

[Theodore Ts'o]

On Fri, Oct 18, 2013 at 06:41:41AM -0500, Felipe Contreras wrote:
> > And I hazard to guess that the vast majority agree with Junio on this (based,
> > again, on email evidence). Not with you.
> 
> That is irrelevant, and a fallacy. The vast majority of people thought the
> Earth was the center of the universe, and they were all wrong.
> 
> It's called ad populum fallacy, look it up. Wether the majority of Git
> developers agree that there's something more than a disagreement is irrelevant,
> their opinion doesn't change the truth.

Look, the problem is that you insist on being "right", even on matters
which may be more about taste and preference than anything that can be
proven mathematically.  Worse, you insist on trying to convince people
even when it might be better to just give up and decide that maybe
something not's worth the effort to get the last word in.  This is how
we get to centithreads.  If every time someone disagrees, you insist
on replying, and then if people give up in disgust, you then try to
use that as "proof" that you must be right, since you've dazzled them
with your brilliance, that's not good for the development community.

Sometimes a question is important enough that it's worth doing this.
But I'd suggest to you that you should ask yourself whether you're
doing it too often.

After all, this is open source.  If you are convinced that you are
right, and everyone else in the community is wrong, it is within your
power to fork the code base, and to prove us wrong by creating a
better product.

Or you can decide to just keep a patch set to yourself, or perhaps
post it periodically, if it is some key feature that you are certain
you or your company can't live with out.  Heck, I've done this with
ext4, even though I'm the maintainer --- there have been features that
I know are critical for my company, but the rest of the ext4
development community are stridently against.  I've just simply posted
the patch set once, and if it gets strongly opposed, I'll just keep it
as a out-of-tree patch.

The fallocate NO_HIDE_STALE flag is a good example of that; it's used
in production on thousands and thousands of servers by Google and Tao
Bao, but since there was strong opposition on the ext4 list, we've
kept it as an out-of-tree patch.  Note what I did not do.  I did not
force the patch in, even though it might be within my power as the
maintainer; nor did I try to convince people over and OVER and OVER
again about the rightness of my position, and turn it into a
centithread.

> My claim is that all I did was disagree with Junio. You can invalidate that
> claim easily by providing *a single* example where I did more than disagree.

The problem is when you disagree with a number of people (not just
Junio), and you are, in my opinion, overly persistent.  We can argue
whether you've stepped over the line in terms of impugning people's
motives or sanity, but that's not necessarily the most important
issue.  People sometimes step over the line, and while that's
unfortunate, it's when it becomes a persistent pattern, and it happens
frequently enough, that it becomes a real problem.

Alternatively, if you are right that Junio is mad, and he's being
capriciously insulting, then I'm sure that when you establish your own
fork, lots of developers will come flocking to your flag.  If they do
not, then perhaps you might want to take that as some objective
evidence that the community is perhaps, more willing to work with him,
then they are to work with you.

Best regards,

						- Ted

P.S.  There are plenty of things that I consider to be unfortunate
about git's command line interface, in terms of inconsistencies and
confusing terminology.  Over the past 5+ years, I've observed that I
think the way commit selection in "git format-patch" is inconsistent
with how we handle commit selection for other commands, e.g., "git log
<commit>" vs and "git format-patch <commit>".  Even if you think that
this is a matter of self-inherent "truth", versus just a matter of
taste, there is also the consideration of backwards compatibility, and
the question of how important consistency and easy of learning gets
traded off against backwards compatibility and invalidating
potentially huge numbers of shell scripts and documentation.  So it's
not something where I've made a nuisance of myself, because it's a
settled issue.

As another example, people have agreed for a long time that the fact
that tab characters are significant in Makefiles is highly
unfortunate.  However, no one is running around calling the GNU Make
maintainers "insane" for not being willing to make a change that would
break huge numbers of Makefiles in the world.  More importantly,
people aren't brining up the same subject over and over and over again
on the GNU Makefile mailing list.  Perhaps you might consider what
would be the appropriate response if someone insisteted on creating
centithreads on the GNU Makefile discuss list on that subject.

Re: My patches

[Felipe Contreras]

Theodore Ts'o wrote:
> On Fri, Oct 18, 2013 at 06:41:41AM -0500, Felipe Contreras wrote:
> > > And I hazard to guess that the vast majority agree with Junio on this (based,
> > > again, on email evidence). Not with you.
> > 
> > That is irrelevant, and a fallacy. The vast majority of people thought the
> > Earth was the center of the universe, and they were all wrong.
> > 
> > It's called ad populum fallacy, look it up. Wether the majority of Git
> > developers agree that there's something more than a disagreement is irrelevant,
> > their opinion doesn't change the truth.
> 
> Look, the problem is that you insist on being "right", even on matters which
> may be more about taste and preference than anything that can be proven
> mathematically.

I don't insist on being right, I have an opinion and I voice it, there is
nothing wrong with that. If the other side agrees there's a difference of
opinion, that's the end of the discussion.

I would say it's actually the other side that insists on being right, and
that's the problem; they don't agree it's a difference in opinion, from their
point of one side is right, and the other side is wrong, and that's what causes
their frustration.

Ask Junio if he thinks it's simply a matter of a difference in opinion. He
pretty much already said it's not.

> Worse, you insist on trying to convince people even when it might be better
> to just give up and decide that maybe something not's worth the effort to get
> the last word in.  This is how we get to centithreads.  If every time someone
> disagrees, you insist on replying,

This is how it goes:

 1) Side A
 2) Side B

 3) Side A
 4) Side B

 5) Side A
 6) Side B

At any point in time side B could stop replying, sure, but so could side A.

Why do you blame ME for replying, and not the other side, for replying to my
reply?

Presumably because right before reply 4), side A thought the discussion was
wortwhile, and something happened in 5) that changed their opinion, and now
side B becomes a problematic person. And since you are friends with side A, you
take their side.

> and then if people give up in disgust, you then try to use that as "proof"
> that you must be right,

Show me *one* instance when I have done so. I have never used silence as
evidence of anything.

> Sometimes a question is important enough that it's worth doing this.
> But I'd suggest to you that you should ask yourself whether you're
> doing it too often.
> 
> After all, this is open source.  If you are convinced that you are
> right, and everyone else in the community is wrong, it is within your
> power to fork the code base, and to prove us wrong by creating a
> better product.

Don't worry, that is *exactly* what I plan to do.

> The fallocate NO_HIDE_STALE flag is a good example of that; it's used
> in production on thousands and thousands of servers by Google and Tao
> Bao, but since there was strong opposition on the ext4 list, we've
> kept it as an out-of-tree patch.  Note what I did not do.  I did not
> force the patch in, even though it might be within my power as the
> maintainer; nor did I try to convince people over and OVER and OVER
> again about the rightness of my position, and turn it into a
> centithread.

My patches are not good just for me or my company, they are good for everyone.

Have you actually looked at any of them?

> > My claim is that all I did was disagree with Junio. You can invalidate that
> > claim easily by providing *a single* example where I did more than
> > disagree.
> 
> The problem is when you disagree with a number of people (not just
> Junio), and you are, in my opinion, overly persistent.

But that's not what Junio said. This is the second time you defend Junio by
assuming his position is exactly the opposite.

Junio doesn't think it's just a disagreement, Junio doesn't think I'm just
being persistent, Junio is saying I can't be worked with.

The interesting thing is that when Junio agrees with the change, he can work
with me, when I agree my change is not good, the same, but suddenly when I
don't agree, then I'm not good to work with. See the pattern?

> We can argue whether you've stepped over the line in terms of impugning
> people's motives or sanity, but that's not necessarily the most important
> issue.  People sometimes step over the line, and while that's unfortunate,
> it's when it becomes a persistent pattern, and it happens frequently enough,
> that it becomes a real problem.

Have I ever impugned people's motives or sanity? Please, show me where I did that.

> Alternatively, if you are right that Junio is mad,

I didn't say Junio is mad, I said he got mad.

:  carried away by intense anger :  furious <mad about the delay>

http://www.merriam-webster.com/dictionary/mad

> and he's being capriciously insulting, then I'm sure that when you establish
> your own fork, lots of developers will come flocking to your flag.  If they
> do not, then perhaps you might want to take that as some objective evidence
> that the community is perhaps, more willing to work with him, then they are
> to work with you.

If you know anything about rationality you know that correlation doesn't prove
causation. So no, it would not be objective evidence.

-- 
Felipe Contreras

Re: My patches

[Junio C Hamano]

Theodore Ts'o <tytso@mit.edu> writes:

> Over the past 5+ years, I've observed that I
> think the way commit selection in "git format-patch" is inconsistent
> with how we handle commit selection for other commands, e.g., "git log
> <commit>" vs and "git format-patch <commit>".  Even if you think that
> this is a matter of self-inherent "truth", versus just a matter of
> taste, there is also the consideration of backwards compatibility, and
> the question of how important consistency and easy of learning gets
> traded off against backwards compatibility and invalidating
> potentially huge numbers of shell scripts and documentation.  So it's
> not something where I've made a nuisance of myself, because it's a
> settled issue.

The original syntax to select of commits by format-patch is very
inconsistent from the log family because it was done way before the
log family's way has been established as the best practice. It has
annoyed enough people that we spent effort to teach recent Git
to accept

	$ git format-patch master..next

as well.

So it indeed is a settled issue, but you are correct to point out
that we had to find a way to do so while still keeping the original
syntax working for people who have scripts and people who work from
random and stale documents we have not much control over updating.