git-phlow
git-phlow copied to clipboard
devx-cafe
Shouldn't swap branch after deliver
When we run a deliverwe're immediately taken to the default integration branch
The expected behaviour is more that we stay on the branch - I know it's renamed, but never the less -I would rather stay on it.
Setting me back to the integration branch makes me loose te files I just edited - and if I have jekyll or sass running in watch mode - it start rebuilding again.
I know @JKrag shares my opinion on this one.
I agree that this is also the behavior I want in the end. It will also make git phlow web take me to the current issues, so I for example can see that issue being closed properly and click on my commit.
So when I run git phlow deliver of any kind, I want to stay on the renamed delivered branch.
That way of working also support our fast feedback loop, where I just need to grab a cup of coffee while the integration process run, and then it is verified or deployed. So when I start my next task with workon and the integration branch is updated before merging I get that feature I just delivered. I would be odd to be taken immediately to the integration branch where my feature isn't found yet.
I disagree. I would expect git phlow deliver to take me back to the integration branch. Because then I am ready to type my next git phlow workon command.
I should have no further business on my feature branch after delivering, unless the pipeline fails.
@martinmosegaard and you realize the taking you back to the integration branch will reset your code changes back to something before your changes? Also that if you have a debugger or say jekyll process running it will rebuild?
No matter if you are on the integration branch or stays on the delivered branch, you're ready to do the next git phlow work at any time.
So you still disagree? Isn't it just a matter of taste?
Regarding resetting the code changes: I assume they have been delivered (pushed to remote) so I can forget about them.
Regarding debugger/jekyll, that has not been a use case for me, but conceptually, I would still start a new debugging session. Because I am done with the previous issue and ready to work on the next issue, so I no longer need to debug anything related to the previous issue.
Regarding your last point, I thought it was best to do git phlow workon from the integration branch. As I understood it, the ideal is to always branch off from the integration branch (not from another feature branch)?
If I depend on my previous issue, the PIP integration should put in on master within a couple of minutes anyway. I can probably use that time to think about the next issue to work on.
Still, it could be a matter of taste :)
we can make this a flag in stead? eg. git phlow deliver --local --stay for staying on the delivery branch?
This has many different consequences and sets of scenarios.
Where can I find the user stories or the spec that we are trying to implement?
Which branch you work on your next task on has consequences for the following scenarios:
- Successful integration with more than one commit squashed
- Failed integration
- Will end up in different scenarios depending on what the merge strategy is on the ci server
Basically my point is that this will not only have workflow consequences it will also have history consequences.
This also corresponds to the are we trying to say "You only need these five commands to work efficiently" or are we trying to supplement already Git skilled people.
What branch you are on after delivering and doing workon has big impact on how to resolve the rainy-day scenarios.
If we suppose that I'm isolating my work on a feature branch, feature branch on top of feature branch should not be wanted. Also what happens if I try to deliver on a feature branch of a feature branch, after having the first feature branch integrated. Might give a nasty rebase :)
@RandomSort Our thought was that staying on the delivered branch should make it less confusing for the user (as it prevents all the users nice work from disappearing in front of their eyes).
workon would still create new branches from [master] as always, so we are not suggesting "feature branch off of a feature branch" cases.
@groenborg and I have just brainstormed a new feature (coming as a new issue later today) that would support something like git phlow workon <xyz> --wait. This would stay here on your previous work, and wait for your delivered changes to arrive on master before creating a branch for the next issue. In this way you could continue editing your live blog immediately. (yes, this issue might need some grooming and POC, but lets take that discussion on the upcoming issue).
@martinmosegaard It is not so much about debugging, but about
a) automatic rebuilding of my entire project because my files change when i deliver, and
b) my changes are gone, so I can not continue work based on these. Lets say issue 13: create a new function and issue 14: use this new function. The moment I deliver 13, the function will be gone, and I have to wait for it to "come back". This is very annoying, also for live blogging and frequent sharing during report writing.
It would make sense to change the default behaviour of git phlow, so it does not change workspace whenever you run deliver. Given how workon works (creating a branch from origin/master), it does not make any difference in terms of how git behaves because the branch you are on have no effect on the workspace you create. It imply boils down to the user experience.
in @lakruzz case and @JKrag case where they use the workflow for blogging and Jekyll related work, it is a bad experience because Jekyll recompiles 😞, for my work it can be a irritating because I do not get to continue my work which in fact is possible given the non-disruptive behaviour of workon.
In edge cases it can make sense to change branch, but that would be case where the delivered changes are non-continuous.
Therefore I will conclude that we will solve this problem by using a --home flag that will take the user home if they want to wait to update their own master branch with the integrated changes from GitHub.
But if it bases the workbranch on master then your changes Will still "disappear"?
Den 24. nov. 2017 3.24 PM skrev "Simon Grønborg" [email protected]:
It would make sense to change the default behaviour of git phlow, so it does not change workspace whenever you run deliver. Given how workon works (creating a branch from origin/master), it does not make any difference in terms of how git behaves because the branch you are on have no effect on the workspace you create. It imply boils down to the user experience.
in @lakruzz https://github.com/lakruzz case and @JKrag https://github.com/jkrag case where they use the workflow for blogging and Jekyll related work, it is a bad experience because Jekyll recompiles 😞, for my work it can be a irritating because I do not get to continue my work which in fact is possible given the non-disruptive behaviour of workon. In edge cases it can make sense to change branch, but that would be case where the delivered changes are non-continuous.
Therefore I will conclude that we will solve this problem by using a --home flag that will take the user home if they want to wait to update their own master branch with the integrated changes from GitHub.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Praqma/git-phlow/issues/264#issuecomment-346839402, or mute the thread https://github.com/notifications/unsubscribe-auth/AAjjq5PNPviMfwH1Qb0VyNM5iveDrSwUks5s5tGQgaJpZM4P7orH .
@RandomSort That depends a lot on when you do the workon. You can continue reading your code/text for a few minutes (without rebuild) and then do the workon when the changes have been integrated. As far as I can judge, you could even start working, making local changes, before you do workon to create the new feature branch. This might have to require a temporary stash-unstash, but that could easily be incorporated in the tool. My favourite git up extention for instance does this every single time a update.
Also have a look at #286 and #285 which would potentially enable you to do a blocking wait for the changes, all while still keeping your workspace intact to avoid confusion and rebuild.
Thanks for all the input - issue is on hold until we have defined how we actually want our phlow to work.
I will make the decision that we do not switch branch.. The way the tool works makes it that solution work really well.
@groenborg you're not going to implement this issue... you added labels It is not in scope.