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

[Stefan Beller <sbeller@google.com>]

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(-)

-- 
2.2.1.62.g3f15098