Stream: committers/git-help
Topic: Still confused
Eric Haas (Sep 21 2018 at 15:32):
Lloyd told me I could commit from a single branch so I could use the the same build and thus the partial build. Once I push and create a pr and the pr is accepted
Eric Haas (Sep 21 2018 at 15:32):
Can I make subsequent pushes and or from that same branch?
Josh Mandel (Sep 21 2018 at 15:35):
You can, though it's not necessarily a recommended practice. (Two weeks ago we changed our default merge strategy to avoid squashing/rebasing, which makes pushing to an already-merged branch less of an outright mistake -- but I still don't recommend this unless you know what you're doing and why you need to.)
Lloyd McKenzie (Sep 21 2018 at 15:46):
Eric's reason is the same as Grahame's. He's working on multiple issues, the local build takes 45 minutes to run and he can't afford to switch branches to work on something else while the build's still chugging.
Josh Mandel (Sep 21 2018 at 15:58):
OK. I thought Grahame's biggest issue was with running a java debugger / editing source code. It's not as clear to me that this would apply to content changes or just running the build.
Lloyd McKenzie (Sep 21 2018 at 16:43):
How would it not apply to content changes? If I'm running the build, I can't switch branches without risking a problem with the build choking.
Eric Haas (Sep 21 2018 at 17:11):
I could work on unrelated issues in separate branches though it stresses st my local system to run concurrent builds.
Eric Haas (Sep 21 2018 at 17:13):
Would like to run the build in the cloud for editing too before commuting.
Eric Haas (Sep 21 2018 at 18:14):
Er...committing
Grahame Grieve (Sep 21 2018 at 21:57):
yes it's not just the debugger. That's just the easiest to describe.
Grahame Grieve (Sep 21 2018 at 21:58):
the real painful thing is the way git takes it upon itself to make changes to your local space when you switch branches without getting you to review
Josh Mandel (Sep 21 2018 at 22:42):
I still can't seem to see it this way -- a Branch is an atomic workspace configuration, so switching branches makes your entire workspace match the branch you're switching to.
Josh Mandel (Sep 21 2018 at 22:43):
Maybe a better workflow for you would be to keep branching off of your latest feature branch, so "git checkout -b mynewfeature" would never cause any files to disappear
Josh Mandel (Sep 21 2018 at 22:53):
image-14883e57-30a6-4d07-98f2-06f197fa7981.jpg
Josh Mandel (Sep 21 2018 at 22:54):
Merging in these incremental branches roughly in the order of creation, or just merging in the final one. Either way, this comes down to using good commit messages and treating these as the key unit of documentation.
Grahame Grieve (Sep 21 2018 at 23:59):
git checkout -b mynewfeature
But I want to commit the incremental branch without committing the base.
Josh Mandel (Sep 22 2018 at 00:54):
You mean your want to push it? Or merge it? Or just you want the commits to appear earlier?
Grahame Grieve (Sep 22 2018 at 06:34):
I want to push the fix I'm making immediately while I keep working on the thing I'm working on
Rob Hausam (Sep 22 2018 at 13:42):
If you only commit the changes that you are ready to push and then push them immediately, I think you can do exactly what you want.
Lloyd McKenzie (Sep 22 2018 at 14:36):
Right. But that only works because we allow multiple merges to the same branch and we don't require separate branches per feature
Josh Mandel (Sep 22 2018 at 14:41):
This is possible today.
Rob Hausam (Sep 22 2018 at 15:30):
yes
Lloyd McKenzie (Sep 22 2018 at 19:01):
Right. But it diverges from "recommended practice". I was just explaining why we have that divergence and that what Eric was asking for is allowed/appropriate - at least in the FHIR core space.
Last updated: Apr 12 2022 at 19:14 UTC
