Re: [PATCH] bundle: remove unneeded code

> The changes in commit c06793a4ed (allow git-bundle to create bottomless
> bundle, 2007-08-08) ensure annotated tags are properly preserved when
> creating a bundle using a revision range operation.
>
> At the time the range notation would peel the ends to their
> corresponding commit, meaning ref v2.0 would point to the v2.0^0 commit.
> So the above workaround was introduced. This code looks up the ref
> before it's written to the bundle, and if the ref doesn't point to the
> object we expect (for tags this would be a tag object), we skip the ref
> from the bundle. Instead, when the ref is a tag that's the positive end
> of the range (e.g. v2.0 from the range "v1.0..v2.0"), then that ref is
> written to the bundle instead.
>
> Later, in 895c5ba3c1 (revision: do not peel tags used in range notation,
> 2013-09-19), the behavior of parsing ranges was changed and the problem
> was fixed at the cause. But the workaround in bundle.c was not reverted.
>
> Now it seems this workaround can cause a race condition. git-bundle(1)
> uses setup_revisions() to parse the input into `struct rev_info`. Later,
> in write_bundle_refs(), it uses this info to write refs to the bundle.
> As mentioned at this point each ref is looked up again and checked
> whether it points to the object we expect. If not, the ref is not
> written to the bundle. But, when creating a bundle in a heavy traffic
> repository (a repo with many references, and frequent ref updates) it's
> possible a branch ref was updated between setup_revisions() and
> write_bundle_refs() and thus the extra check causes the ref to be
> skipped.
>
> The workaround was originally added to deal with tags, but the code path
> also gets hit by non-tag refs, causing this race condition. Because it's
> no longer needed, remove it and fix the possible race condition.