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

Re: metastore

From
Ddavid@lang.hm <david@lang.hm>
Date
Sep 17, 2007, 04:35 UTC
Message-ID
<Pine.LNX.4.64.0709162126380.24221@asgard.lang.hm>
In-Reply-To
<7v7imp539u.fsf@gitster.siamese.dyndns.org>
On Sun, 16 Sep 2007, Junio C Hamano wrote:
Show 31 quoted lines
> david@lang.hm writes:
>
>>> Post-checkout trigger is something I can say I can live with
>>> without looking at the actual patch, but that does not mean it
>>> would be a better approach at all.
>>
>> we agree on this much at least :-)
>>
>>> I would not be able to answer the first question right now; that
>>> needs a patch to prove that it can be done with a well contained
>>> set of changes that results in a maintainable code.
>>
>> you cannot answer the question in the affirmitive, but you could say
>> that any changes in that area would be completely unacceptable to you
>> (and for a while it sounded like you were saying exactly that). in
>> which case any effort put into preparing patches would be a waste of
>> time
>
> I tend to disagree.  It's far from a waste of time.  While, as I
> said, I am skeptical that such a patch would be small impact, if
> it helps people's needs, somebody will pick it up and carry
> forward, even if that somebody is not me.  It can then mature
> out of tree and later could be merged.  We simply do not know
> unless somebody tries.  And I am quite happy that you seem to be
> motivated enough to see how it goes.
>
> On the other hand, the experiment could fail and you may end up
> with a patch that is too messy to be acceptable, in which case
> you might feel it a waste of time, but I do not think it is a
> waste even in such a case.  We would learn what works and what
> doesn't, and we can bury "keeping track of /etc" topic to rest.

this is perfectly acceptable to me. I was trying to make very sure that this topic fell in this catagory.

there are other topics that come up repeatedly that do get (and deserve) automatic rejections ('patch to explicitly record renames' for example). and while I didn't think that 'managing /etc' was in the same catagory, sometimes that catagory is defined as much by the opinions and goals of the core team as it is by techinical considerations.

there's a huge difference between 'this patch is rejected becouse we think the implementation is bad' and 'this patch is rejected becouse we disagree with the fundamental goal of the patch' effort spent on a patch rejected for the first reason is never a complete waste (if nothing else it can serve an an example of how not to do things for future developers ;-) but effort spent on a patch that's rejected for the second reason is useually a waste, and as such I make it a point to discuss the objective and basic approach before spending much effort on somthing.

Show 14 quoted lines
> I also need to rant here a bit.
>
> Fortunately we haven't had this problem too many times on this
> list, but sometimes people say "Here is my patch.  If this is
> accepted I'll add documentation and tests".  I rarely reply to
> such patches without sugarcoating my response, but my internal
> reaction is, "Don't you, as the person who proposes that change,
> believe in your patch deeply enough to be willing to perfect it,
> in order to make it suitable for consumption by the general
> public, whether it is included in my tree or not?  A change that
> even you do not believe in yourself has very little chance of
> benefitting the general public, so thanks but no thanks, I'll
> pass."
>
I hope that my questions did not seem to fall into this catagory.
David Lang
Previous: Junio C HamanoNext: Junio C Hamano
Message 39 of 72 in “Re: Track /etc directory using Git”
  1. Thomas Harning Jr.Sep 14, 2007
  2. Nicolas VilzSep 14, 2007
  3. metastore (was: Track /etc directory using Git)martin f krafft, Sep 15, 2007
  4. Johannes SchindelinSep 15, 2007
  5. David KastrupSep 15, 2007
  6. martin f krafftSep 15, 2007
  7. Grzegorz KulewskiSep 15, 2007
  8. Johannes SchindelinSep 15, 2007
  9. Randal L. SchwartzSep 15, 2007
  10. david@lang.hmSep 16, 2007
  11. Randal L. SchwartzSep 16, 2007
  12. david@lang.hmSep 16, 2007
  13. Francis MoreauSep 17, 2007
  14. Randal L. SchwartzSep 17, 2007
  15. Daniel BarkalowSep 15, 2007
  16. Johannes SchindelinSep 15, 2007
  17. david@lang.hmSep 16, 2007
  18. Johannes SchindelinSep 16, 2007
  19. david@lang.hmSep 16, 2007
  20. Junio C HamanoSep 16, 2007
  21. David KastrupSep 16, 2007
  22. david@lang.hmSep 16, 2007
  23. Daniel BarkalowSep 16, 2007
  24. david@lang.hmSep 16, 2007
  25. Junio C HamanoSep 16, 2007
  26. Daniel BarkalowSep 16, 2007
  27. david@lang.hmSep 16, 2007
  28. Daniel BarkalowSep 16, 2007
  29. david@lang.hmSep 16, 2007
  30. martin f krafftSep 17, 2007
  31. david@lang.hmSep 17, 2007
  32. Josh EnglandSep 17, 2007
  33. david@lang.hmSep 16, 2007
  34. Junio C HamanoSep 16, 2007
  35. david@lang.hmSep 16, 2007
  36. Junio C HamanoSep 17, 2007
  37. david@lang.hmSep 17, 2007
  38. Junio C HamanoSep 17, 2007
  39. david@lang.hmSep 17, 2007
  40. Junio C HamanoSep 17, 2007
  41. Daniel BarkalowSep 17, 2007
  42. Junio C HamanoSep 17, 2007
  43. Jan HudecSep 16, 2007
  44. david@lang.hmSep 16, 2007
  45. martin f krafftSep 16, 2007
  46. Jan HudecSep 16, 2007
  47. david@lang.hmSep 16, 2007
  48. martin f krafftSep 17, 2007
  49. david@lang.hmSep 16, 2007
  50. martin f krafftSep 16, 2007
  51. David HärdemanSep 19, 2007
  52. martin f krafftOct 2, 2007
  53. David HärdemanOct 2, 2007
  54. David KastrupOct 2, 2007
  55. david@lang.hmOct 2, 2007
  56. martin f krafftOct 2, 2007
  57. david@lang.hmOct 2, 2007
  58. martin f krafftOct 2, 2007
  59. david@lang.hmOct 2, 2007
  60. martin f krafftOct 2, 2007
  61. David HärdemanOct 2, 2007
  62. martin f krafftOct 2, 2007
  63. Julian PhillipsOct 2, 2007
  64. david@lang.hmOct 3, 2007
  65. Johannes SchindelinOct 3, 2007
  66. Daniel BarkalowOct 2, 2007
  67. Pierre HabouzitSep 15, 2007
  68. martin f krafftSep 15, 2007
  69. Pierre HabouzitSep 15, 2007
  70. martin f krafftSep 15, 2007
  71. martin f krafftSep 15, 2007
  72. David KastrupSep 15, 2007

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.