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

Solution needed for switching manifests #8

Open smipi1 opened 8 years ago

smipi1 commented 8 years ago

When switching between the develop.xml and master.xml, we need to switch the project branches between develop and master as well. The exact behavior on a manifest and therefore project branch when switching between manifests is unknown, and should be properly defined to match what we are trying to achieve.

GatorQue commented 8 years ago

From what I read recently, there were some serious issues in the past when switching between manifest files. But I think the safest approach is to do something like this: repo init -m other_manifest.xml repo sync -d This typically leaves each project in a detached state and I think to some degree prevents the rebase which typically occurs during these switches. At least that was how it was described in the email chain I ran into (which was demonstrating an issue that was eventually resolved). I agree that a few experiments should be performed to confirm this. Is there something else you had in mind or was this what you were thinking?

smipi1 commented 8 years ago

Maybe... I would like to see the same behaviour at the composition level as you would normally see with git flow. With git flow you usually do a git checkout to switch between master and develop. Maybe a new repo switch command could provide the same behaviour at the composition level.

On Mon, 1 Feb 2016, 00:29 Ryan Lindeman notifications@github.com wrote:

From what I read recently, there were some serious issues in the past when switching between manifest files. But I think the safest approach is to do something like this: repo init -m other_manifest.xml repo sync -d This typically leaves each project in a detached state and I think to some degree prevents the rebase which typically occurs during these switches. At least that was how it was described in the email chain I ran into (which was demonstrating an issue that was eventually resolved). I agree that a few experiments should be performed to confirm this. Is there something else you had in mind or was this what you were thinking?

— Reply to this email directly or view it on GitHub https://github.com/GatorQue/git-repo-flow/issues/8#issuecomment-177660525 .

GatorQue commented 8 years ago

What about a repo flow checkout command?

smipi1 commented 8 years ago

Do you think we should add something with generic value to the flow sub-command?

A switch can be useful in its own right: switch = checkout manifest and associated branches, but don't merge / rebase anything.

GatorQue commented 8 years ago

Would this amount to a repo init followed by some type of repo sync? I'm assuming that is what repo flow switch or repo switch would entail.

smipi1 commented 8 years ago

Hi Ryan,

I think the workflow will be: repo init -m develop.xml -u... repo pull # same as sync, but checks out develop repo flow init repo flow feature start...

change and commit stuff.

repo flow features finish... repo push repo flow release start... repo flow release finish... repo push repo switch master.xml repo push --tags repo switch develop.xml

On Tue, 2 Feb 2016, 02:48 Ryan Lindeman notifications@github.com wrote:

Would this amount to a repo init followed by some type of repo sync? I'm assuming that is what repo flow switch or repo switch would entail.

— Reply to this email directly or view it on GitHub https://github.com/GatorQue/git-repo-flow/issues/8#issuecomment-178303878 .

smipi1 commented 8 years ago

We could perhaps improve the repo push by supporting an optional manifest spec: E.g. repo push master.xml develop.xml --tags

On Tue, 2 Feb 2016, 10:38 Pieter Smith pieter@boesman.nl wrote:

Hi Ryan,

I think the workflow will be: repo init -m develop.xml -u... repo pull # same as sync, but checks out develop repo flow init repo flow feature start...

change and commit stuff.

repo flow features finish... repo push repo flow release start... repo flow release finish... repo push repo switch master.xml repo push --tags repo switch develop.xml

On Tue, 2 Feb 2016, 02:48 Ryan Lindeman notifications@github.com wrote:

Would this amount to a repo init followed by some type of repo sync? I'm assuming that is what repo flow switch or repo switch would entail.

— Reply to this email directly or view it on GitHub https://github.com/GatorQue/git-repo-flow/issues/8#issuecomment-178303878 .

GatorQue commented 8 years ago

What internally would happen in repo push when you specify an optional manifest spec?

smipi1 commented 8 years ago

Equivalent to:

  1. Check that there are no uncommitted changes with current manifest state.
  2. Perform a repo switch to the specified manifest.
  3. Push all branches to remote.
  4. repo switch back to previous manifest.

On Tue, 2 Feb 2016, 14:34 Ryan Lindeman notifications@github.com wrote:

What internally would happen in repo push when you specify an optional manifest spec?

— Reply to this email directly or view it on GitHub https://github.com/GatorQue/git-repo-flow/issues/8#issuecomment-178575851 .

smipi1 commented 8 years ago

@GatorQue: We had some topic-drift here. I was using my phone so the context wasn't always clear. The goal was to specify repo switch, and we ended up expanding on repo push. I'll copy the repo push comments to #4 .

GatorQue commented 8 years ago

So am I correct in stating that the optional manifest arguments are to simplify the: repo push repo switch master.xml repo push --tags repo switch develop.xml

Steps into a single command: repo push master.xml develop.xml --tags Such that the develop, master, and tags all get pushed? That would imply that repo push is only pushing the currently selected branch.

smipi1 commented 8 years ago

Yes. Exactly. See #4.