search

GatorQue / git-repo-flow

Enhanced Google repo alternative that utilizes a git-flow methodology.
Apache License 2.0
6 stars 3 forks source link

Complete push subcmd #4

Open smipi1 opened 8 years ago

smipi1 commented 8 years ago

A naive push is provided by https://github.com/GatorQue/git-repo-flow/commit/fddfdac4fed3981f8ee07ef2ec6eb0b675d637f9 and https://github.com/GatorQue/git-repo-flow/commit/04df653234de2b6ccfc0d1a9ac8ed71e2fc20293. To complete the functionality, push should:

  1. Only push projects with checked out branches.
  2. Support some option to push all branches in the <flow><branches> manifest specification.
smipi1 commented 8 years ago

repo push should:

  1. Fail if there are local changes to any of the projects or the manifest repository.
  2. By default, push the current state of the manifest repository along with any checked out branches to the remote(s).
  3. Ensure that all tags referenced in the manifests being pushed are also pushed to the remote(s).
  4. Optionally perform a repo switch to a specified manifest, push the manifest repository and associated branches to the remote(s) and repo switch back to the original manifest.
GatorQue commented 8 years ago

Can you help me understand the use case for step 4? when switching between manifests, what would I hope to pickup in terms of branches to be pushed. Wouldn't the repositories be identical to the one I just left? Its not clear to me what would end up being pushed or why I would want to switch manifest files.

smipi1 commented 8 years ago

By default git only pushes the branch currently checked out. This will be the same for repo push.

With git, if a user wants has develop checked out, but he wants to push master, he can perform a git push <remote> master. If he is happy with pushing the current branch (I.e. develop), a simple git push will suffice. Git does offer a --all option, but that pushes all branches to all remotes. With a single remote this is usually what the developer wants, but with multiple remotes, you end up unnecessarily polluting one of the two remotes.

repo push will be subject to the same behavior. A repo push will push the currently checked out manifest and associated branches. Should the developer wish to push another manifest along with its associated branches, we provide him with the same git-like option.