search

drewdeponte / git-ps-rs

Official git-ps Rust implementation - the future of git-ps
https://git-ps.sh
MIT License
79 stars 8 forks source link

Add ability to back port a patch or series of patches (git ps bp) #18

Open drewdeponte opened 4 years ago

drewdeponte commented 4 years ago

The scenario is that you have had to make a hotfix branch and now that it is good and you bump the version and everything. It is time to add that hotfix back into mainline.

There are a couple options here.

  1. git co master and then git merge your-hotfix-branch, then git ps rebase to move your-hotfix-branch merge commit to the bottom of the stack, then submit that patch for review or publish if it is good

  2. What would be ideal would be if there was a way to have that hot fix branch merged into effectively/origin master and placed at the bottom of the patch stack so that you could then either submit for review or publish it.

RyanHedges commented 4 years ago

To riff on this a little, it might be cool to, from git-ps, do things as normal on master, and have a command like git-ps hot 2 23a81b which takes the index 2 and makes the hotfix branch.

RyanHedges commented 4 years ago

Also, I know this is a development process thing. In CI/CD world, wouldn't you not be working with hotfix branches? You'd just push a fix or change, run the checks, and roll it out?

drewdeponte commented 4 years ago

So, in terms of the git-ps hot 2 23a81b I personally like this option. It may be beneficial to figure out a more generic term than hot for the command but overall I think it is a good idea. There is a downside to it however. If we take a step back to understand the two general approaches with "hotfixes" they are as follows.

Back Port

  1. You make the fix ontop of all the new stuff in your patch stack on mainline (e.g. master). Then once you have gotten your fix working there you "port" that fix back (a.k.a. back porting) to a previous version of the app that you want to make a patch release of. This process is in alignment with your suggestion of git-ps hot 2 23a81b as it would effectively be making a branch to facilitate create the hotfix release.

Forward Port

  1. You create a hotfix branch on top of the release you want to patch. You add your commits (fixes) there and cut a release from there. Then you "port" that fix forward (a.k.a. forward porting) to the mainline of the app. This is effectively merging or cherry-picking the hotfix onto your patch stack. But cherry-picking on to the top of your patch stack is less than ideal because you have to deal with more potential conflicts than if it was a patch that was magically placed on top of origin/master and then your stack of patches placed on top of it. This is where some of these optimizations/opinions become more personal preference I think.

The Rub

Anyways back to the pros/cons of each one. It all really boils down to timing and when certain things happen. People generally prefer option 2 (forward porting) over option 1 (back porting) as first you are directly creating a patch for the state of the world that needs to be fixed fasted. Then you worry about forward porting and dealing with the potential conflicts with stuff that is in mainline that hasn't been released, when you have time to. With option 1 on the other hand you are building a patch based on the state of code in your patch stack (and mainline) and then as part of the back porting having to deal with any differences between your patch stack state and that of the previous revision you want to hotfix when you are under the gun in terms of time.

Back Porting w/ Patch Stack as is

  1. create a patch on top of your patch stack that fixes the issue
  2. create a hotfix branch on-top of the older release you want to hotfix
  3. cherry-pick your hotfix patch commit from your patch stack into the hotfix branch and resolve any conflicts
  4. follow your normal hotfix process for testing, tagging, and releasing the change

Note: This could be improved with @RyanHedges suggestion of a command like git-ps hot 2 23a81b that would take care of creating the hotfix branch for you and cherry picking the patch into it.

Forward Porting w/ Patch Stack as is

  1. create a hotfix branch on-top of the older release you want to hotfix
  2. create the commit to fix the issue on top of your hotfix branch
  3. follow your normal hotfix process for testing, tagging, and releasing the change
  4. merge your hotfix branch into your patch stack branch (master) or cherry-pick the hotfix into your patch stack and resolve any conflicts and organize your patches if you are prioritizing getting the hotfix into upstream mainline sooner than your other patches.

Note: This could be optimized if we took an opinioned position that the user would always want to prioritize getting the hotfix into uptstream mainline sooner than their other patches and build a command that would basically lift up your stack of patches, cherry-pick the hotfix commit effectively origin/master and then dropping the entire patch stack right on top of that commit.

Conclusion

This definitely isn't a blocker though as there are two pretty clearly defined paths for how users can deal with this situation.

It seems like we have two ideas around things git-ps could do, one to support each of these two paths. I would love to hear any additional ideas around these workflows and what we could do to improve them.

RyanHedges commented 4 years ago

I think the distinction of the back and forward porting is great. Thanks for clarifying!

In my head I was thinking about it as a back port way because of how I think about git-ps. I'm of the mindset that I'm working ontop of origin/master and git-ps helps me manage that. A thought I had was what if I had multiple stacks. It's kinda like making a branch, but it gives me the same management of commits, and if I wanted to, I can move the base of the stack wherever I want.

git-ps new origin/master hotfix - create a "new stack" on master. Feels like a branch.... git-ps new hotfix v1.0.3 - creates a "new stack" branch on the v1.0.3 tag? git-ps co hotfix - switch the current stack? git-ps ls - show the stacks of commits grouped by stack

origin/master
0    18239Z Add new function
hotfix
0 rr 228C13 Update README with new info

git-ps merge hotfix does the forward porting into mainline master.

We had a quick conversation, and maybe this can just be done through cherrypicking and branching which might be good info to share given this workflow. But it might be worthwhile to see if there is a patch stack mindset that the tool can help reinforce. I think somehow being able to create multiple "stacks" might be a step in the right direction, especially if we can identify a benefit that you gain that branches don't facilitate well.

drewdeponte commented 3 years ago

So with the evolution of uptech/git-ps-rs#17 which addresses forward porting of patches. Conveniently the subcommand as of right now is git ps fp.

Anyways, with that it makes me now thing maybe this ticket should be around adding something to facilitate back porting. This would be a command similar to what was discussed above.

git ps bp <patch-index> <destination-sha1> (e.g. git ps bp 2 a23f23)

drewdeponte commented 3 years ago

This is actually somewhat related to git ps rr because it is doing the same process. The difference is that it's destination where the patches will be cherry picked onto would be a specified location (sha1) rather than the base of the current Patch Stack.