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

Re: [PATCH v12 06/41] refs.c: add an err argument to repack_without_refs

From
Jonathan Nieder <jrnieder@gmail.com>
Date
May 29, 2014, 18:17 UTC
Message-ID
<20140529181732.GF12314@google.com>
In-Reply-To
<1401379676-9307-2-git-send-email-sahlberg@google.com>
Hi,
Ronnie Sahlberg wrote:
Show 17 quoted lines
> Update repack_without_refs to take an err argument and update it if there
> is a failure. Pass the err variable from ref_transaction_commit to this
> function so that callers can print a meaningful error message if _commit
> fails due to a problem in repack_without_refs.
>
> Add a new function unable_to_lock_message that takes a strbuf argument and
> fills in the reason for the failure.
>
> In commit_packed_refs, make sure that we propagate any errno that
> commit_lock_file might have set back to our caller.
>
> Signed-off-by: Ronnie Sahlberg <sahlberg@google.com>
> ---
>  cache.h    |  2 ++
>  lockfile.c | 21 ++++++++++++---------
>  refs.c     | 25 +++++++++++++++++++------
>  3 files changed, 33 insertions(+), 15 deletions(-)

I don't want to sound like a broken record, but this still has the same issues I described before at http://thread.gmane.org/gmane.comp.version-control.git/250197/focus=250309.

The commit message or documentation or notes after the three dashes above could explain what I missed when making my suggestions. Otherwise I get no reality check as a reviewer, other reviewers get less insight into what's happening in the patch, people in the future looking into the patch don't understand its design as well, etc.

As a general rule, that is a good practice anyway --- even when a reviewer was confused, what they got confused about can be an indication of where to make the code or design documentation (commit message) more clear, and when reposting a patch it can be a good opportunity to explain how the patch evolved.

What would be wrong with the line of API documentation and the TODO comment for a known bug I suggested? If they are a bad idea, can you explain that so I can learn from it? Or if they were confusing, would you like a patch that explains what I mean?

Jonathan
Previous: Ronnie SahlbergNext: Ronnie Sahlberg
Message 3 of 18 in “Use ref transactions for all ref updates”
  1. 00/44 Use ref transactions for all ref updatesRonnie Sahlberg, May 29, 2014
  2. 06/41 refs.c: add an err argument to repack_without_refsRonnie Sahlberg, May 29, 2014
  3. Jonathan NiederMay 29, 2014
  4. Ronnie SahlbergJun 3, 2014
  5. 08/41 refs.c: add an err argument to delete_ref_looseRonnie Sahlberg, May 29, 2014
  6. 16/41 refs.c: add transaction.status and track OPEN/CLOSED/ERRORRonnie Sahlberg, May 29, 2014
  7. 24/41 receive-pack.c: use a reference transaction for updating the refsRonnie Sahlberg, May 29, 2014
  8. 25/41 fast-import.c: use a ref transaction when dumping tagsRonnie Sahlberg, May 29, 2014
  9. 26/41 walker.c: use ref transaction for ref updatesRonnie Sahlberg, May 29, 2014
  10. 31/41 refs.c: make prune_ref use a transaction to delete the refRonnie Sahlberg, May 29, 2014
  11. 32/41 refs.c: make delete_ref use a transactionRonnie Sahlberg, May 29, 2014
  12. 33/41 refs.c: pass the ref log message to _create/delete/update instead of _commitRonnie Sahlberg, May 29, 2014
  13. 36/41 refs.c: move the check for valid refname to lock_ref_sha1_basicRonnie Sahlberg, May 29, 2014
  14. 38/41 refs.c: pass a skip list to name_conflict_fnRonnie Sahlberg, May 29, 2014
  15. 39/41 refs.c: propagate any errno==ENOTDIR from _commit back to the callersRonnie Sahlberg, May 29, 2014
  16. 40/41 fetch.c: change s_update_ref to use a ref transactionRonnie Sahlberg, May 29, 2014
  17. 41/41 refs.c: make write_ref_sha1 staticRonnie Sahlberg, May 29, 2014
  18. Ronnie SahlbergMay 29, 2014

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.