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

Re: Git and GCC

From
NNightStrike <nightstrike@gmail.com>
Date
Dec 7, 2007, 05:36 UTC
Message-ID
<b609cb3b0712062136y154ec1c3g875ba33e470355a8@mail.gmail.com>
In-Reply-To
<alpine.LFD.0.9999.0712061036200.13796@woody.linux-foundation.org>
On 12/6/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
Show 40 quoted lines
>
>
> On Thu, 6 Dec 2007, NightStrike wrote:
> >
> > No disrespect is meant by this reply.  I am just curious (and I am
> > probably misunderstanding something)..  Why remove all of the
> > documentation entirely?  Wouldn't it be better to just document it
> > more thoroughly?
>
> Well, part of it is that I don't think "--aggressive" as it is implemented
> right now is really almost *ever* the right answer. We could change the
> implementation, of course, but generally the right thing to do is to not
> use it (tweaking the "--window" and "--depth" manually for the repacking
> is likely the more natural thing to do).
>
> The other part of the answer is that, when you *do* want to do what that
> "--aggressive" tries to achieve, it's such a special case event that while
> it should probably be documented, I don't think it should necessarily be
> documented where it is now (as part of "git gc"), but as part of a much
> more technical manual for "deep and subtle tricks you can play".
>
> > I thought you did a fine job in this post in explaining its purpose,
> > when to use it, when not to, etc.  Removing the documention seems
> > counter-intuitive when you've already gone to the trouble of creating
> > good documentation here in this post.
>
> I'm so used to writing emails, and I *like* trying to explain what is
> going on, so I have no problems at all doing that kind of thing. However,
> trying to write a manual or man-page or other technical documentation is
> something rather different.
>
> IOW, I like explaining git within the _context_ of a discussion or a
> particular problem/issue. But documentation should work regardless of
> context (or at least set it up), and that's the part I am not so good at.
>
> In other words, if somebody (hint hint) thinks my explanation was good and
> readable, I'd love for them to try to turn it into real documentation by
> editing it up and creating enough context for it! But I'm nort personally
> very likely to do that. I'd just send Junio the patch to remove a
> misleading part of the documentation we have.
hehe.. I'd love to, actually.  I can work on it next week.
Previous: Linus TorvaldsNext: Jon Loeliger
Message 72 of 89 in “Re: Git and GCC”
  1. David MillerDec 6, 2007
  2. Daniel BerlinDec 6, 2007
  3. David MillerDec 6, 2007
  4. Daniel BerlinDec 6, 2007
  5. David MillerDec 6, 2007
  6. Harvey HarrisonDec 6, 2007
  7. Daniel BerlinDec 6, 2007
  8. David MillerDec 6, 2007
  9. Daniel BerlinDec 6, 2007
  10. Harvey HarrisonDec 6, 2007
  11. Daniel BerlinDec 6, 2007
  12. Jon SmirlDec 6, 2007
  13. Jeff KingDec 6, 2007
  14. Nicolas PitreDec 6, 2007
  15. Jeff KingDec 6, 2007
  16. Nicolas PitreDec 6, 2007
  17. Jeff KingDec 7, 2007
  18. Jeff KingDec 7, 2007
  19. Linus TorvaldsDec 6, 2007
  20. Jon SmirlDec 6, 2007
  21. Nicolas PitreDec 6, 2007
  22. Jon SmirlDec 6, 2007
  23. Nicolas PitreDec 6, 2007
  24. Jon SmirlDec 6, 2007
  25. Jon SmirlDec 6, 2007
  26. Nicolas PitreDec 6, 2007
  27. Jon SmirlDec 6, 2007
  28. Jeff KingDec 7, 2007
  29. Harvey HarrisonDec 8, 2007
  30. Gabriel PaubertDec 10, 2007
  31. Nicolas PitreDec 10, 2007
  32. David MillerDec 7, 2007
  33. Jeff KingDec 7, 2007
  34. Jon SmirlDec 7, 2007
  35. David MillerDec 7, 2007
  36. Linus TorvaldsDec 7, 2007
  37. Giovanni BajoDec 7, 2007
  38. Jakub NarebskiDec 7, 2007
  39. Luke LuDec 7, 2007
  40. Giovanni BajoDec 7, 2007
  41. Daniel BerlinDec 7, 2007
  42. Johannes SchindelinDec 8, 2007
  43. David MillerDec 8, 2007
  44. David MillerDec 10, 2007
  45. Linus TorvaldsDec 6, 2007
  46. Harvey HarrisonDec 6, 2007
  47. David BrownDec 6, 2007
  48. Nicolas PitreDec 6, 2007
  49. gc --aggressive: make it really aggressiveJohannes Schindelin, Dec 6, 2007
  50. Theodore TsoDec 6, 2007
  51. Nicolas PitreDec 6, 2007
  52. Pierre HabouzitDec 6, 2007
  53. Johannes SchindelinDec 6, 2007
  54. David KastrupDec 6, 2007
  55. Harvey HarrisonDec 6, 2007
  56. Johannes SchindelinDec 6, 2007
  57. Linus TorvaldsDec 6, 2007
  58. Johannes SchindelinMar 18, 2009
  59. Teemu LikonenMar 18, 2009
  60. Nicolas PitreMar 18, 2009
  61. Daniel BerlinDec 6, 2007
  62. Linus TorvaldsDec 6, 2007
  63. Harvey HarrisonDec 7, 2007
  64. Linus TorvaldsDec 7, 2007
  65. Jon SmirlDec 7, 2007
  66. Nicolas PitreDec 7, 2007
  67. Linus TorvaldsDec 7, 2007
  68. Jon SmirlDec 7, 2007
  69. Nicolas PitreDec 7, 2007
  70. NightStrikeDec 6, 2007
  71. Linus TorvaldsDec 6, 2007
  72. NightStrikeDec 7, 2007
  73. Jon LoeligerDec 6, 2007
  74. Linus TorvaldsDec 6, 2007
  75. Jakub NarebskiDec 7, 2007
  76. Junio C HamanoDec 6, 2007
  77. Junio C HamanoDec 6, 2007
  78. David KastrupDec 6, 2007
  79. [OT] Re: Git and GCCRandy Dunlap, Dec 6, 2007
  80. Harvey HarrisonDec 6, 2007
  81. Linus TorvaldsDec 6, 2007
  82. Harvey HarrisonDec 6, 2007
  83. Johannes SchindelinDec 6, 2007
  84. Ismail DönmezDec 6, 2007
  85. "Argument list too long" in git remote update (Was: Git and GCC)Geert Bosch, Dec 17, 2007
  86. Johannes SchindelinDec 17, 2007
  87. Linus TorvaldsDec 17, 2007
  88. Derek FawcusDec 18, 2007
  89. Shawn O. PearceDec 18, 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.