Cleaning up stale branches?


(Alex Blewitt) #1

There are a lot of branches in the main Swift Git repository at the moment. Many of these appear to be short-term testing branches that are out of date, or work in progress that may be better in an external repository until the work is done. There are also a number of branches (e.g. swift-3.0-preview-*-branch) which are in most cases out-of-step with the tags due to updating version numbers e.g.

9cf1a6f807dd0d36eca20433341a4f1667616431 tag:swift-3.0-PREVIEW-5
b687a0a9d3a4b588ee6c8ca5b43042bbd2fb8586 head:swift-3.0-preview-5-branch

Cleaning up the stale branches will allow others to focus on what the current work areas are, and what are the main branches to be pushing changes to.

$ git ls-remote --heads | cut -b-33 | xargs -n 1 git show -s --oneline "--pretty=format:%d %ar"

From https://github.com/apple/swift

(origin/SR-2545) 7 weeks ago
(origin/_fastCStringContents) 4 months ago
(origin/dabrahams-patch-1) 3 months ago
(origin/dabrahams-patch-3) 8 days ago
(origin/disable-associated-type-witness-inference) 4 months ago
(origin/distributed-test) 7 weeks ago
(origin/dwa-misc) 3 days ago
(origin/eager-bridging) 8 weeks ago
(origin/expression-breakup) 10 days ago
(origin/external-swift-stdlib) 4 weeks ago
(origin/inhibit-implicit-conversions) 6 months ago
(origin/jtbandes-patch-1) 5 weeks ago
(origin/line-directive-maintenance) 4 weeks ago
(origin/master, origin/HEAD) 10 hours ago
(origin/master-next) 2 days ago
(origin/moredistcc) 35 hours ago
(origin/new-integer-protocols) 15 hours ago
(origin/non-comparable-indices) 4 months ago
(origin/revert-5309-overlays-and-silgen_name) 2 days ago
(origin/rst-to-markdown) 5 months ago
(origin/runtime-fix-swift-error-box-comparison) 5 weeks ago
(origin/silgen-tests-should-build-modules) 7 weeks ago
(origin/stdlib-BidirectionalCollection.removeLast) 5 weeks ago
(origin/stdlib-default-RangeReplaceableCollection.SubSequence-3.0) 5 weeks ago
(origin/stdlib-indexing) 5 weeks ago
(tag: swift-2.2.1-SNAPSHOT-2016-04-23-a, origin/swift-2.2-branch) 6 months ago
(origin/swift-2.2-with-migration-attributes) 4 weeks ago
(origin/swift-2.3-branch) 9 weeks ago
(origin/swift-3-indexing-model-typechecker-bug-1) 7 months ago
(origin/swift-3.0-branch) 13 hours ago
(origin/swift-3.0-preview-1-branch) 4 months ago
(origin/swift-3.0-preview-2-branch) 4 months ago
(origin/swift-3.0-preview-3-branch) 3 months ago
(origin/swift-3.0-preview-4-branch) 3 months ago
(origin/swift-3.0-preview-5-branch) 3 months ago
(origin/swift-3.0-preview-5-speculative) 3 months ago
(origin/swift-3.0.1-preview-2-branch) 4 weeks ago
(origin/tests-mkdir-p) 7 weeks ago
(origin/underscore-playgroundquicklook) 2 months ago
(origin/update-checkout-script-for-2.3) 3 months ago


(Daniel Dunbar) #2

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.

- Daniel

···

On Oct 21, 2016, at 5:50 AM, Alex Blewitt via swift-dev <swift-dev@swift.org> wrote:

There are a lot of branches in the main Swift Git repository at the moment. Many of these appear to be short-term testing branches that are out of date, or work in progress that may be better in an external repository until the work is done. There are also a number of branches (e.g. swift-3.0-preview-*-branch) which are in most cases out-of-step with the tags due to updating version numbers e.g.

9cf1a6f807dd0d36eca20433341a4f1667616431 tag:swift-3.0-PREVIEW-5
b687a0a9d3a4b588ee6c8ca5b43042bbd2fb8586 head:swift-3.0-preview-5-branch

Cleaning up the stale branches will allow others to focus on what the current work areas are, and what are the main branches to be pushing changes to.

$ git ls-remote --heads | cut -b-33 | xargs -n 1 git show -s --oneline "--pretty=format:%d %ar"
From https://github.com/apple/swift
(origin/SR-2545) 7 weeks ago
(origin/_fastCStringContents) 4 months ago
(origin/dabrahams-patch-1) 3 months ago
(origin/dabrahams-patch-3) 8 days ago
(origin/disable-associated-type-witness-inference) 4 months ago
(origin/distributed-test) 7 weeks ago
(origin/dwa-misc) 3 days ago
(origin/eager-bridging) 8 weeks ago
(origin/expression-breakup) 10 days ago
(origin/external-swift-stdlib) 4 weeks ago
(origin/inhibit-implicit-conversions) 6 months ago
(origin/jtbandes-patch-1) 5 weeks ago
(origin/line-directive-maintenance) 4 weeks ago
(origin/master, origin/HEAD) 10 hours ago
(origin/master-next) 2 days ago
(origin/moredistcc) 35 hours ago
(origin/new-integer-protocols) 15 hours ago
(origin/non-comparable-indices) 4 months ago
(origin/revert-5309-overlays-and-silgen_name) 2 days ago
(origin/rst-to-markdown) 5 months ago
(origin/runtime-fix-swift-error-box-comparison) 5 weeks ago
(origin/silgen-tests-should-build-modules) 7 weeks ago
(origin/stdlib-BidirectionalCollection.removeLast) 5 weeks ago
(origin/stdlib-default-RangeReplaceableCollection.SubSequence-3.0) 5 weeks ago
(origin/stdlib-indexing) 5 weeks ago
(tag: swift-2.2.1-SNAPSHOT-2016-04-23-a, origin/swift-2.2-branch) 6 months ago
(origin/swift-2.2-with-migration-attributes) 4 weeks ago
(origin/swift-2.3-branch) 9 weeks ago
(origin/swift-3-indexing-model-typechecker-bug-1) 7 months ago
(origin/swift-3.0-branch) 13 hours ago
(origin/swift-3.0-preview-1-branch) 4 months ago
(origin/swift-3.0-preview-2-branch) 4 months ago
(origin/swift-3.0-preview-3-branch) 3 months ago
(origin/swift-3.0-preview-4-branch) 3 months ago
(origin/swift-3.0-preview-5-branch) 3 months ago
(origin/swift-3.0-preview-5-speculative) 3 months ago
(origin/swift-3.0.1-preview-2-branch) 4 weeks ago
(origin/tests-mkdir-p) 7 weeks ago
(origin/underscore-playgroundquicklook) 2 months ago
(origin/update-checkout-script-for-2.3) 3 months ago

_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev


(Mark Lacey) #3

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.

You can also set the pushurl for a remote so that it goes to a different repo. This is what I do:
$ git remote -v
origin git@github.com:apple/swift.git (fetch)
origin git@github.com:rudkx/swift.git (push)

This makes it possible to continue using ./utils/update-checkout to set up and update repos, with the one small step that you need to use ‘git config’ to set the pushurl after the initial clone.

Any ‘push’ thereafter will go to your fork.

The only minor annoyance I’ve run across is that ‘git fetch --prune’ and ‘git remote update --prune’ will delete tracking branches for things you push to your fork.

With this level of support, IMHO branches usually should be pushed to individual's own repos, not the main repo.

I agree. This is how I’ve done all my PRs.

Mark

···

On Oct 21, 2016, at 9:14 AM, Daniel Dunbar via swift-dev <swift-dev@swift.org> wrote:

- Daniel

On Oct 21, 2016, at 5:50 AM, Alex Blewitt via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:

There are a lot of branches in the main Swift Git repository at the moment. Many of these appear to be short-term testing branches that are out of date, or work in progress that may be better in an external repository until the work is done. There are also a number of branches (e.g. swift-3.0-preview-*-branch) which are in most cases out-of-step with the tags due to updating version numbers e.g.

9cf1a6f807dd0d36eca20433341a4f1667616431 tag:swift-3.0-PREVIEW-5
b687a0a9d3a4b588ee6c8ca5b43042bbd2fb8586 head:swift-3.0-preview-5-branch

Cleaning up the stale branches will allow others to focus on what the current work areas are, and what are the main branches to be pushing changes to.

$ git ls-remote --heads | cut -b-33 | xargs -n 1 git show -s --oneline "--pretty=format:%d %ar"
From https://github.com/apple/swift
(origin/SR-2545) 7 weeks ago
(origin/_fastCStringContents) 4 months ago
(origin/dabrahams-patch-1) 3 months ago
(origin/dabrahams-patch-3) 8 days ago
(origin/disable-associated-type-witness-inference) 4 months ago
(origin/distributed-test) 7 weeks ago
(origin/dwa-misc) 3 days ago
(origin/eager-bridging) 8 weeks ago
(origin/expression-breakup) 10 days ago
(origin/external-swift-stdlib) 4 weeks ago
(origin/inhibit-implicit-conversions) 6 months ago
(origin/jtbandes-patch-1) 5 weeks ago
(origin/line-directive-maintenance) 4 weeks ago
(origin/master, origin/HEAD) 10 hours ago
(origin/master-next) 2 days ago
(origin/moredistcc) 35 hours ago
(origin/new-integer-protocols) 15 hours ago
(origin/non-comparable-indices) 4 months ago
(origin/revert-5309-overlays-and-silgen_name) 2 days ago
(origin/rst-to-markdown) 5 months ago
(origin/runtime-fix-swift-error-box-comparison) 5 weeks ago
(origin/silgen-tests-should-build-modules) 7 weeks ago
(origin/stdlib-BidirectionalCollection.removeLast) 5 weeks ago
(origin/stdlib-default-RangeReplaceableCollection.SubSequence-3.0) 5 weeks ago
(origin/stdlib-indexing) 5 weeks ago
(tag: swift-2.2.1-SNAPSHOT-2016-04-23-a, origin/swift-2.2-branch) 6 months ago
(origin/swift-2.2-with-migration-attributes) 4 weeks ago
(origin/swift-2.3-branch) 9 weeks ago
(origin/swift-3-indexing-model-typechecker-bug-1) 7 months ago
(origin/swift-3.0-branch) 13 hours ago
(origin/swift-3.0-preview-1-branch) 4 months ago
(origin/swift-3.0-preview-2-branch) 4 months ago
(origin/swift-3.0-preview-3-branch) 3 months ago
(origin/swift-3.0-preview-4-branch) 3 months ago
(origin/swift-3.0-preview-5-branch) 3 months ago
(origin/swift-3.0-preview-5-speculative) 3 months ago
(origin/swift-3.0.1-preview-2-branch) 4 weeks ago
(origin/tests-mkdir-p) 7 weeks ago
(origin/underscore-playgroundquicklook) 2 months ago
(origin/update-checkout-script-for-2.3) 3 months ago

_______________________________________________
swift-dev mailing list
swift-dev@swift.org <mailto:swift-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-dev

_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev


(Daniel Dunbar) #4

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.

You can also set the pushurl for a remote so that it goes to a different repo. This is what I do:
$ git remote -v
origin git@github.com <mailto:git@github.com>:apple/swift.git (fetch)
origin git@github.com <mailto:git@github.com>:rudkx/swift.git (push)

This makes it possible to continue using ./utils/update-checkout to set up and update repos, with the one small step that you need to use ‘git config’ to set the pushurl after the initial clone.

Nice, thanks!

- Daniel

···

On Oct 21, 2016, at 9:57 AM, Mark Lacey <mark.lacey@apple.com> wrote:

On Oct 21, 2016, at 9:14 AM, Daniel Dunbar via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:

Any ‘push’ thereafter will go to your fork.

The only minor annoyance I’ve run across is that ‘git fetch --prune’ and ‘git remote update --prune’ will delete tracking branches for things you push to your fork.

With this level of support, IMHO branches usually should be pushed to individual's own repos, not the main repo.

I agree. This is how I’ve done all my PRs.

Mark

- Daniel

On Oct 21, 2016, at 5:50 AM, Alex Blewitt via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:

There are a lot of branches in the main Swift Git repository at the moment. Many of these appear to be short-term testing branches that are out of date, or work in progress that may be better in an external repository until the work is done. There are also a number of branches (e.g. swift-3.0-preview-*-branch) which are in most cases out-of-step with the tags due to updating version numbers e.g.

9cf1a6f807dd0d36eca20433341a4f1667616431 tag:swift-3.0-PREVIEW-5
b687a0a9d3a4b588ee6c8ca5b43042bbd2fb8586 head:swift-3.0-preview-5-branch

Cleaning up the stale branches will allow others to focus on what the current work areas are, and what are the main branches to be pushing changes to.

$ git ls-remote --heads | cut -b-33 | xargs -n 1 git show -s --oneline "--pretty=format:%d %ar"
From https://github.com/apple/swift
(origin/SR-2545) 7 weeks ago
(origin/_fastCStringContents) 4 months ago
(origin/dabrahams-patch-1) 3 months ago
(origin/dabrahams-patch-3) 8 days ago
(origin/disable-associated-type-witness-inference) 4 months ago
(origin/distributed-test) 7 weeks ago
(origin/dwa-misc) 3 days ago
(origin/eager-bridging) 8 weeks ago
(origin/expression-breakup) 10 days ago
(origin/external-swift-stdlib) 4 weeks ago
(origin/inhibit-implicit-conversions) 6 months ago
(origin/jtbandes-patch-1) 5 weeks ago
(origin/line-directive-maintenance) 4 weeks ago
(origin/master, origin/HEAD) 10 hours ago
(origin/master-next) 2 days ago
(origin/moredistcc) 35 hours ago
(origin/new-integer-protocols) 15 hours ago
(origin/non-comparable-indices) 4 months ago
(origin/revert-5309-overlays-and-silgen_name) 2 days ago
(origin/rst-to-markdown) 5 months ago
(origin/runtime-fix-swift-error-box-comparison) 5 weeks ago
(origin/silgen-tests-should-build-modules) 7 weeks ago
(origin/stdlib-BidirectionalCollection.removeLast) 5 weeks ago
(origin/stdlib-default-RangeReplaceableCollection.SubSequence-3.0) 5 weeks ago
(origin/stdlib-indexing) 5 weeks ago
(tag: swift-2.2.1-SNAPSHOT-2016-04-23-a, origin/swift-2.2-branch) 6 months ago
(origin/swift-2.2-with-migration-attributes) 4 weeks ago
(origin/swift-2.3-branch) 9 weeks ago
(origin/swift-3-indexing-model-typechecker-bug-1) 7 months ago
(origin/swift-3.0-branch) 13 hours ago
(origin/swift-3.0-preview-1-branch) 4 months ago
(origin/swift-3.0-preview-2-branch) 4 months ago
(origin/swift-3.0-preview-3-branch) 3 months ago
(origin/swift-3.0-preview-4-branch) 3 months ago
(origin/swift-3.0-preview-5-branch) 3 months ago
(origin/swift-3.0-preview-5-speculative) 3 months ago
(origin/swift-3.0.1-preview-2-branch) 4 weeks ago
(origin/tests-mkdir-p) 7 weeks ago
(origin/underscore-playgroundquicklook) 2 months ago
(origin/update-checkout-script-for-2.3) 3 months ago

_______________________________________________
swift-dev mailing list
swift-dev@swift.org <mailto:swift-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-dev

_______________________________________________
swift-dev mailing list
swift-dev@swift.org <mailto:swift-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-dev


(Dave Abrahams) #5

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.

···

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.

--
-Dave


(John McCall) #6

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. 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.

John.

···

On Oct 21, 2016, at 10:39 AM, Dave Abrahams via swift-dev <swift-dev@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.


(Dave Abrahams) #7

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.

···

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@swift.org> wrote:
on Fri Oct 21 2016, Daniel Dunbar <swift-dev-AT-swift.org> wrote:

--
-Dave


(Daniel Dunbar) #8

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?

I agree... longer lived high profile branches make sense to me personally, just not short lived "push for purpose of PRing immediately" ones.

- Daniel

···

On Oct 21, 2016, at 12:14 PM, Dave Abrahams via swift-dev <swift-dev@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@swift.org> wrote:
on Fri Oct 21 2016, Daniel Dunbar <swift-dev-AT-swift.org> wrote:

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
_______________________________________________
swift-dev mailing list
swift-dev@swift.org <mailto:swift-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-dev


(John McCall) #9

Yeah, I agree. Any sort of *collaborative* branch is 100% okay to live in the main repository. If you weren't expecting a branch to be a collaboration and it starts turning into one, it's easy to just move it over from your personal fork at that point.

John.

···

On Oct 21, 2016, at 12:23 PM, Daniel Dunbar <daniel_dunbar@apple.com> wrote:

On Oct 21, 2016, at 12:14 PM, Dave Abrahams via swift-dev <swift-dev@swift.org <mailto:swift-dev@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@swift.org <mailto:swift-dev@swift.org>> wrote:
on Fri Oct 21 2016, Daniel Dunbar <swift-dev-AT-swift.org <http://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?

I agree... longer lived high profile branches make sense to me personally, just not short lived "push for purpose of PRing immediately" ones.


(Dave Abrahams) #10

FWIW, if you visit https://github.com/apple/swift/branches you'll see
all your branches at the top, and you can delete (at least) any that
have already been merged.

···

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

On Oct 21, 2016, at 12:23 PM, Daniel Dunbar <daniel_dunbar@apple.com> wrote:

On Oct 21, 2016, at 12:14 PM, Dave Abrahams via swift-dev <swift-dev@swift.org > <mailto:swift-dev@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@swift.org <mailto:swift-dev@swift.org>> wrote:
on Fri Oct 21 2016, Daniel Dunbar <swift-dev-AT-swift.org <http://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?

I agree... longer lived high profile branches make sense to me personally, just not short lived

"push for purpose of PRing immediately" ones.

Yeah, I agree. Any sort of *collaborative* branch is 100% okay to
live in the main repository. If you weren't expecting a branch to be
a collaboration and it starts turning into one, it's easy to just move
it over from your personal fork at that point.

--
-Dave


(Ted Kremenek) #11

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?

I agree... longer lived high profile branches make sense to me personally, just not short lived "push for purpose of PRing immediately" ones.

Yeah, I agree. Any sort of *collaborative* branch is 100% okay to live in the main repository. If you weren't expecting a branch to be a collaboration and it starts turning into one, it's easy to just move it over from your personal fork at that point.

These arguments all resonate with me as well. I'd prefer we keep branches in the main repository for release management or high-profile collaborative branches only. That said, your argument that a list of branches doesn't provide a good axis of discoverability is still relevant. For that I still think pull requests are better suited. Still, branches provide all sorts of things like access control, etc., but I personally have no problems with collaborative development work happening on forks, even if it involves more than one person.

···

On Oct 21, 2016, at 12:49 PM, John McCall via swift-dev <swift-dev@swift.org> wrote:

On Oct 21, 2016, at 12:23 PM, Daniel Dunbar <daniel_dunbar@apple.com> wrote:
On Oct 21, 2016, at 12:14 PM, Dave Abrahams via swift-dev <swift-dev@swift.org> wrote:
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@swift.org> wrote:

on Fri Oct 21 2016, Daniel Dunbar <swift-dev-AT-swift.org> wrote:

John.
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev


(John McCall) #12

The PR page also prompts you to do this after the merge succeeds.

John.

···

On Oct 21, 2016, at 1:54 PM, Dave Abrahams <dabrahams@apple.com> wrote:
on Fri Oct 21 2016, John McCall <rjmccall-AT-apple.com> wrote:

On Oct 21, 2016, at 12:23 PM, Daniel Dunbar <daniel_dunbar@apple.com> wrote:

On Oct 21, 2016, at 12:14 PM, Dave Abrahams via swift-dev <swift-dev@swift.org >> <mailto:swift-dev@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@swift.org <mailto:swift-dev@swift.org>> wrote:
on Fri Oct 21 2016, Daniel Dunbar <swift-dev-AT-swift.org <http://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?

I agree... longer lived high profile branches make sense to me personally, just not short lived

"push for purpose of PRing immediately" ones.

Yeah, I agree. Any sort of *collaborative* branch is 100% okay to
live in the main repository. If you weren't expecting a branch to be
a collaboration and it starts turning into one, it's easy to just move
it over from your personal fork at that point.

FWIW, if you visit https://github.com/apple/swift/branches you'll see
all your branches at the top, and you can delete (at least) any that
have already been merged.


(Ted Kremenek) #13

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?

I agree... longer lived high profile branches make sense to me personally, just not short lived

"push for purpose of PRing immediately" ones.

Yeah, I agree. Any sort of *collaborative* branch is 100% okay to
live in the main repository. If you weren't expecting a branch to be
a collaboration and it starts turning into one, it's easy to just move
it over from your personal fork at that point.

FWIW, if you visit https://github.com/apple/swift/branches you'll see
all your branches at the top, and you can delete (at least) any that
have already been merged.

There are a fair number of stale branches. We should make an effort to go through these soon and purge the ones that are no longer relevant.

···

On Oct 21, 2016, at 1:54 PM, Dave Abrahams via swift-dev <swift-dev@swift.org> wrote:
on Fri Oct 21 2016, John McCall <rjmccall-AT-apple.com> wrote:

On Oct 21, 2016, at 12:23 PM, Daniel Dunbar <daniel_dunbar@apple.com> wrote:

On Oct 21, 2016, at 12:14 PM, Dave Abrahams via swift-dev <swift-dev@swift.org >> <mailto:swift-dev@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@swift.org <mailto:swift-dev@swift.org>> wrote:
on Fri Oct 21 2016, Daniel Dunbar <swift-dev-AT-swift.org <http://swift-dev-at-swift.org/>> wrote:

--
-Dave
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev


(Dave Abrahams) #14

FWIW, I reviewed mine, and all the branches that are still in the repo are there for a good reason.

···

Sent from my iPad

On Oct 21, 2016, at 9:20 PM, Ted kremenek <kremenek@apple.com> wrote:

On Oct 21, 2016, at 1:54 PM, Dave Abrahams via swift-dev <swift-dev@swift.org> wrote:

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

On Oct 21, 2016, at 12:23 PM, Daniel Dunbar <daniel_dunbar@apple.com> wrote:

On Oct 21, 2016, at 12:14 PM, Dave Abrahams via swift-dev <swift-dev@swift.org >>> <mailto:swift-dev@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@swift.org <mailto:swift-dev@swift.org>> wrote:
on Fri Oct 21 2016, Daniel Dunbar <swift-dev-AT-swift.org <http://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?

I agree... longer lived high profile branches make sense to me personally, just not short lived

"push for purpose of PRing immediately" ones.

Yeah, I agree. Any sort of *collaborative* branch is 100% okay to
live in the main repository. If you weren't expecting a branch to be
a collaboration and it starts turning into one, it's easy to just move
it over from your personal fork at that point.

FWIW, if you visit https://github.com/apple/swift/branches you'll see
all your branches at the top, and you can delete (at least) any that
have already been merged.

There are a fair number of stale branches. We should make an effort to go through these soon and purge the ones that are no longer relevant.

--
-Dave
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev