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

Re: [PATCH 0/5] gitweb: git_patchset_body fixes

From
Jakub Narebski <jnareb@gmail.com>
Date
Jan 8, 2007, 09:03 UTC
Message-ID
<200701081003.54991.jnareb@gmail.com>
In-Reply-To
<257061.93025.qm@web31801.mail.mud.yahoo.com>
Dnia poniedziałek 8. stycznia 2007 04:50, Luben Tuikov napisał:
> --- Jakub Narebski <jnareb@gmail.com> wrote:
>> Luben Tuikov wrote:
Show 11 quoted lines
>>> "And while at it" can you please actually *do* "refactor"
>>> git_patchset_body *into smaller functions each one doing
>>> a single particular task*.
>>> 
>>> It is sad to see git_patchset_body in such despicable state
>>> all the while seeing words like "refactor" in the commit logs
>>> of that function.
>> 
>> (Perhaps I overuse word "refactor").
> 
> Perhaps.  Or maybe it is used incorrectly.
That is also possible.

That said git_patchset_body was rewritten from AWK-like event-driven single loop, with lots of state variables, to few loops following the structure of patchset, and of git diff.

Show 24 quoted lines
>>> git_patchset_body is grossly overloaded for what it is
>>> supposed to do to, and being one single huge blob, it is
>>> hard to maintain.
>> 
>> I'm not sure if splitting git_patchset_body into smaller functions
>> would be worth doing, as 1) such functions would be used only
>> by git_patchset_body, 2) quite a bit of info has to be passed.
> 
> When things get too complex, they should be done out of
> principle, not out of "how I feel about it", since principles
> can be proved and what they define can be easily tracked.
> 
> Yes, it is worth doing.  It doesn't matter that those smaller
> functions would be used only by git_patchset_body, when
> (by principle) the workings, logic and justification would
> be clearly exposed by those smaller units of function.  Thus
> it would be possible to prove that the function is correct
> or not, and bugs would be able to be isolated easily.
> 
> Smaller units of function should do one thing and do it well.
> If you cannot isolate them "because quite a bit of info has
> to be passed" then the logic of git_patchset_body is faulty,
> by _definition_, and needs to be scrapped and re-engineered
> (from scratch).

On first glance it would be easy to separate (refactor) individual patch parsing and output into separate subroutine; perhaps also separate parsing and output of diff header.

The problems with this approach are two: empty patches (e.g. pure rename patch) and split patches (e.g. file to symlink patch). And we are dealing with two sources of information: "raw" difftree part, and the patch(set) part.

So it is not that easy. But I can certainly try...
-- 
Jakub Narebski
Poland
Previous: Luben TuikovNext: Luben Tuikov
Message 4 of 17 in “Bugs in gitweb”
  1. Luben TuikovJan 5, 2007
  2. 0/5 gitweb: git_patchset_body fixesJakub Narebski, Jan 7, 2007
  3. Luben TuikovJan 8, 2007
  4. Jakub NarebskiJan 8, 2007
  5. Luben TuikovJan 9, 2007
  6. Jakub NarebskiJan 9, 2007
  7. Jakub NarebskiJan 9, 2007
  8. Luben TuikovJan 9, 2007
  9. gitweb: Fix git_patchset_body not closing <div class="patch">Jakub Narebski, Jan 9, 2007
  10. Luben TuikovJan 9, 2007
  11. Luben TuikovJan 9, 2007
  12. 1/5 gitweb: Fix error in git_patchest_body for file creation/deletion patchJakub Narebski, Jan 7, 2007
  13. Luben TuikovJan 8, 2007
  14. 2/5 gitweb: Fix error in "rename to"/"copy to" git diff header outputJakub Narebski, Jan 7, 2007
  15. 3/5 gitweb: Fix errors in git_patchset_body for empty patchesJakub Narebski, Jan 7, 2007
  16. 4/5 Revert "gitweb: There can be empty patches (in git_patchset_body)"Jakub Narebski, Jan 7, 2007
  17. 5/5 gitweb: Fix split patches output (e.g. file to symlink)Jakub Narebski, Jan 7, 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.