git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 00/13] remote-hg: general updates

From
Philip Oakley <philipoakley@iee.org>
Date
Apr 6, 2013, 14:09 UTC
Message-ID
<CDBF6E3BB68D4385B19C53A447186556@PhilipOakley>
In-Reply-To
<CAMP44s10HGpfz=r1m8QRFY4V+rAOkiRaerW1T=vHz2YpbBH6Zg@mail.gmail.com>
From: "Felipe Contreras" <felipe.contreras@gmail.com>
Sent: Saturday, April 06, 2013 1:45 AM
Show 5 quoted lines
> On Fri, Apr 5, 2013 at 4:30 PM, Max Horn <max@quendi.de> wrote:
>
>> On 04.04.2013, at 08:42, Felipe Contreras wrote:
>
>> Please consider [...]
> Ultimately this is not about people, this is about the code.
In the case of helper functions this is not the case.

The question would be better framed: "Does this, or that, helper function make users (people) feel helped, or frustrated (or somewhere in limbo)?".

I've called IT help desks and often felt frustrated, and some times I've got one of the good girls/guys who worked with me to improve my situation (often despite official policies). I get back to those folks (even if they 'failed').

It's not a binary black/white issue when real users need help. It's no good keeping with the faith (e.g. the Git ideal, the coders ideal, ..) when the users (a mixed group) environmental doctine differs.

>    A sensible person that is not emotionally attached to any code,
  [I'm thinking users here, they are emotionally attached to their 
original problem, and sense doesn't come into it]
>  would simply look at the code,

Unfortunately, even for reasonable coders, looking at the code isn't usually the case because of lack of time, unfamiliarity with the code, extent of the code, availablity of the code (they may be simply running a packaged/compiled 'app'), this is not that likely to happen. We should be thankful when folk do look.

It's hard enough to get "good" bug reports from fellow coders (they are only human / no more human than us) that tell us what _we_ want to know (rather than what _they_ remember, or was important to them). ;-)

I don't use Hg, but as I read the discussion, there are incomaptibilities between Git, and Hg. Thus neither helper can ever be perfect. The winners will be those who solve a user need with enough documentation and error capture to make them (their user group) feel happy. At the moment it looks like the discussion is stratifying into various "it worked for me" camps, each with their own problem children repos that won't respond to parental advice, even with a --force from social services.

Philip [As they say back home: Between thee and me, ther's nowt so queer as fowk, and I ain't so sure about thee]

Previous: Felipe ContrerasNext: Felipe Contreras
Message 36 of 48 in “remote-hg: general updates”
  1. 00/13 remote-hg: general updatesFelipe Contreras, Apr 2, 2013
  2. 01/13 remote-hg: trivial cleanupsFelipe Contreras, Apr 2, 2013
  3. 02/13 remote-hg: add missing config variable in docFelipe Contreras, Apr 2, 2013
  4. 03/13 remote-hg: properly report errors on bookmark pushesFelipe Contreras, Apr 2, 2013
  5. 04/13 remote-hg: fix for files with spacesFelipe Contreras, Apr 2, 2013
  6. 05/13 remote-hg: make sure fake bookmarks are updatedFelipe Contreras, Apr 2, 2013
  7. 06/13 remote-hg: trivial test cleanupsFelipe Contreras, Apr 2, 2013
  8. 07/13 remote-hg: redirect buggy mercurial outputFelipe Contreras, Apr 2, 2013
  9. Junio C HamanoApr 2, 2013
  10. Felipe ContrerasApr 2, 2013
  11. Junio C HamanoApr 2, 2013
  12. Felipe ContrerasApr 4, 2013
  13. Junio C HamanoApr 4, 2013
  14. 08/13 remote-hg: split bookmark handlingFelipe Contreras, Apr 2, 2013
  15. 09/13 remote-hg: refactor exportFelipe Contreras, Apr 2, 2013
  16. 10/13 remote-hg: update remote bookmarksFelipe Contreras, Apr 2, 2013
  17. 11/13 remote-hg: force remote pushFelipe Contreras, Apr 2, 2013
  18. 12/13 remote-hg: don't update bookmarks unnecessarilyFelipe Contreras, Apr 2, 2013
  19. 13/13 remote-hg: update tags globallyFelipe Contreras, Apr 2, 2013
  20. Junio C HamanoApr 2, 2013
  21. Felipe ContrerasApr 2, 2013
  22. Junio C HamanoApr 2, 2013
  23. John KeepingApr 2, 2013
  24. Max HornApr 2, 2013
  25. Felipe ContrerasApr 3, 2013
  26. Felipe ContrerasApr 3, 2013
  27. Antoine PelisseApr 3, 2013
  28. Felipe ContrerasApr 5, 2013
  29. Max HornApr 4, 2013
  30. Felipe ContrerasApr 4, 2013
  31. Felipe ContrerasApr 4, 2013
  32. Max HornApr 4, 2013
  33. Felipe ContrerasApr 4, 2013
  34. Max HornApr 5, 2013
  35. Felipe ContrerasApr 6, 2013
  36. Philip OakleyApr 6, 2013
  37. Felipe ContrerasApr 6, 2013
  38. Junio C HamanoApr 6, 2013
  39. Felipe ContrerasApr 6, 2013
  40. Junio C HamanoApr 7, 2013
  41. Jed BrownApr 4, 2013
  42. Junio C HamanoApr 4, 2013
  43. Jed BrownApr 4, 2013
  44. Felipe ContrerasApr 4, 2013
  45. Felipe ContrerasApr 4, 2013
  46. Jed BrownApr 4, 2013
  47. Felipe ContrerasApr 4, 2013
  48. Felipe ContrerasApr 5, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.