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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html