[swift-dev] Cleaning up stale branches?

Dave Abrahams dabrahams at apple.com
Fri Oct 21 14:14:10 CDT 2016


on Fri Oct 21 2016, John McCall <rjmccall-AT-apple.com> wrote:

>> On Oct 21, 2016, at 10:39 AM, Dave Abrahams via swift-dev <swift-dev at swift.org> wrote:
>> on Fri Oct 21 2016, Daniel Dunbar <swift-dev-AT-swift.org> wrote:
>> 
>>> While on this topic...
>>> 
>
>>> GitHub's support for doing cross-repo pull requests is
>>> excellent. Anyone can easily fork the main repo, and push to their
>>> side repo (for example, with: `git push ddunbar
>>> HEAD:name-of-my-new-branch`) and the GitHub web UI on the main repo
>>> will automatically show you a handy button for creating the PR.
>>> 
>>> With this level of support, IMHO branches usually should be pushed to
>>> individual's own repos, not the main repo.
>> 
>> IMO it depends whether you think Swift development should be
>> discoverable.  When the Swift project formally engages in developing
>> something like the new integer and floating point models, there's an
>> advantage to having it in the main repository.
>
> I don't understand this argument.  Looking at a list of branches is not a useful
> way of discovering development history — you don't know which branches are
> still active, which branches were merged, or which branches were completely
> abandoned.  

True.  Maybe discoverability isn't the word I was looking for.  When
three people want to collaborate on development of a feature branch,
where should it live?

> Moreover, branches are just commit histories and so are missing all
> sorts of useful discussion and review that are just as much a part of
> the development history.  All of these disadvantages are addressed by
> instead looking at pull requests, and once you're looking at a pull
> request, it does not matter what repository it came from.

Sure, OK.  I feel a bit odd about doing development for the project that
employs me in a “personal fork” of the main repository, but I can
adjust, if that's what we decide we want to do.

-- 
-Dave


More information about the swift-dev mailing list