[RFC PATCH 0/5] So you dislike the sequence of system calls?

This series goes on top of origin/sb/atomic-push-fix for now.

I am inclined to squash the first patch into the last commit of origin/sb/atomic-push-fix when rerolling that series as it just fixes the warning Ramsay pointed out. I'd also like to combine this series with the origin/sb/atomic-push-fix in a reroll of either series such that it becomes one larger series.

The patches 2,3,4 are just preparations (no change intended) for the patch 5 which then corrects the sequence of system calls such that we don't close and reopen the lock file.

(Background: Why am I spending time to fix that bug the way I do?) I think writing out the sha1 early to the .lock file helps in further patch series for cross repository atomic pushes, because if we can split the transaction_commit into two parts, where the latter part only has lock file pathes in memory, dealing with cross repository ref updates becomes easy in such a way: (compare discussion [RFC] Introducing different handling for small/large transactions)

        cat << EOF > stdin_pipe
        delete topic2 2345
        update master 4567 2378
        repository ../API-consumer # this switches to another repository
        delete topic2 3459
        update master 6787 9878
        EOF
        git update-ref --stdin <stdin_pipe

Internally update-ref would be easy to implement when all you have left are lock files you'd need to commit.

Any feedback welcome!

Thanks, Stefan

Stefan Beller (5):
  fixup for "refs.c: enable large transactions"
  refs.c: remove unlock_ref from write_ref_sha1
  refs.c: move static functions to close and commit refs
  refs.c: remove committing the ref from write_ref_sha1
  refs.c: write values to lock files early for committing

 refs.c | 81 ++++++++++++++++++++++++++++++++++++------------------------------
 1 file changed, 44 insertions(+), 37 deletions(-)