[swift-dev] Cleaning up stale branches?
daniel_dunbar at apple.com
Fri Oct 21 14:23:16 CDT 2016
> On Oct 21, 2016, at 12:14 PM, Dave Abrahams via swift-dev <swift-dev at swift.org> wrote:
> on Fri Oct 21 2016, John McCall <rjmccall-AT-apple.com <http://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
> 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?
I agree... longer lived high profile branches make sense to me personally, just not short lived "push for purpose of PRing immediately" ones.
>> 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.
> swift-dev mailing list
> swift-dev at swift.org <mailto:swift-dev at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-dev <https://lists.swift.org/mailman/listinfo/swift-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-dev