Stream: committers/git-help
Topic: how to keep a local "CI" build
Eric Haas (Sep 11 2018 at 17:53):
One issue that I have with the Git workflow is that:
1) The build takes a long time for example this morning:
BUILD SUCCESSFUL Total time: 95 minutes 33 seconds
and 2) I like to see the current state of my local build so the partial build is really handy.
so I can make a bunch of small commits to the main branch but still keep track of how it all renders locally continuously.
3) With Git, I am under the impression when I create a new branch for each commit means I can't use the the partial build each time but have to run a full build each time.
4) if that is the case I will be forced to create massive PR with lots of changes across several trackers instead of the preferred 1 change per tracker, because it will take too long to wait for a full build each time.
5) Besides not running a local build for each commit/branch/PR what other workflow is there so I can see the rendered output for each small change between branches?
Eric Haas (Sep 11 2018 at 17:57):
For a specific example, I have a tracker to change all OO resources from `.context
Eric Haas (Sep 11 2018 at 18:00):
back to .encounter. Ideally would create a new branch for each resource, make the edits, run the build , commit, make a PR , repeat until done. Now I'm not going to spend 12 * 95 minutes doing this but will make all the changes in a single branch and commit and make a PR covering a dozen or so resources.
Bryn Rhodes (Sep 11 2018 at 18:21):
If I understand your concern correctly, I think you can still take advantage of the partial build functionality. Switching to a new branch doesn't mean you have a different local directory, so it happens on the same set of files. Creating a new branch, for example, doesn't actually change any of the content of the local directory, it's a source control operation only. So the partial build should still work the way that you're used to.
Eric Haas (Sep 11 2018 at 19:06):
atom doesn't work that way so maybe I'm confusing the two. but my recollection working with igs is the ig-pub doesn't remember... I'll check it out.
Lloyd McKenzie (Sep 11 2018 at 19:08):
What impact does branch switching have on file timestamps? That's the real question that matters for the build
Josh Mandel (Sep 11 2018 at 19:18):
https://git.wiki.kernel.org/index.php/Git_FAQ#Why_isn.27t_Git_preserving_modification_time_on_files.3F has good context and an explanation. The bottom line is that git will make changes to timestamps only on files that actually change their contents when doing a checkout. At that point it sets the timestamp to the current time.
Josh Mandel (Sep 11 2018 at 19:18):
It's designed to support this kind of compilation process.
Grahame Grieve (Sep 11 2018 at 21:23):
the tricky thing is that once you commit a file, it then starts changing when you switch branches locally. It doesn't change if you haven't committed it. I'm finding that difference quite tricky in practice
Josh Mandel (Sep 11 2018 at 21:48):
In practice, you should think about merging one Branch into another (locally) if you want the same new files to appear in both.
Grahame Grieve (Sep 11 2018 at 21:59):
but then you can't do a push to a remote branch from it?
Josh Mandel (Sep 11 2018 at 22:05):
sure you can.
Josh Mandel (Sep 11 2018 at 22:05):
The branches will look just as they do locally.
Grahame Grieve (Sep 11 2018 at 22:13):
but then they'll include incomplete work from the other branch, not just the work I want to push
Josh Mandel (Sep 11 2018 at 22:14):
Sure. This workflow only makes sense if you're going to wait until the work is complete before you merge.
Josh Mandel (Sep 11 2018 at 22:14):
But you can push at intervals as you make progress.
Josh Mandel (Sep 11 2018 at 22:15):
The bottom line is that you want the state of the repository locally to look the same as it will on the build server.
Josh Mandel (Sep 11 2018 at 22:15):
So anytime you would lie on untracked files you are violating that expectation -- it is likely to lead to surprising disagreements between what you see locally and what you see on the build server.
Grahame Grieve (Sep 11 2018 at 22:19):
so this isn't a solution. I have 2 different things going on - a bug fix, and some bigger development. I have committed files to the bigger development, but it's not done yet. I lose all them if I switch to a new branch for the bug fix. But if I merge the committed changes to the bug fix branch, then, when I push it up, I'll get all the incomplete work as well
Josh Mandel (Sep 11 2018 at 22:21):
In this scenario, does the bug fix depend on the bigger development?
Josh Mandel (Sep 11 2018 at 22:21):
Normally I would expect to do a bug fix in isolation and push a very small change just for that.
Grahame Grieve (Sep 11 2018 at 22:23):
no, it doesn't depend on it, and yes that's right. But switching to the branch for the bug fix changes the state of the local workspace so it doesn't include anything committed for the other work, but does still include things not committed. Don't you see how troublesome that is?
Rob Hausam (Sep 11 2018 at 22:25):
That's where stash could help, I think - when you need it in a case like that.
Grahame Grieve (Sep 11 2018 at 22:25):
how does it help?
Josh Mandel (Sep 11 2018 at 22:25):
I don't usually run into this, but if you need to make a quick switch for this kind of bug fix, the incantation of https://stackoverflow.com/a/835561 should help -- git stash --all before switching branches to the bug fix
Rob Hausam (Sep 11 2018 at 22:25):
yes
Grahame Grieve (Sep 11 2018 at 22:26):
how does it help?
- it leaves all my changes in place? (right)
- it completely removes my changes? (wrong)
Josh Mandel (Sep 11 2018 at 22:26):
Then when you come back to your work in progress branch you can git stash pop
Josh Mandel (Sep 11 2018 at 22:26):
It hides your changes so you can do the bug fix in isolation.
Grahame Grieve (Sep 11 2018 at 22:26):
but (Josh) we discussed why losing my changes is impossible....
Josh Mandel (Sep 11 2018 at 22:27):
I may not have followed this part.
Grahame Grieve (Sep 11 2018 at 22:27):
I keep coming back to this: GIT does not support the workflow I need to function
Josh Mandel (Sep 11 2018 at 22:27):
If the bug fix is really independent, you should not want other unrelated changes present when you make and test it.
Grahame Grieve (Sep 11 2018 at 22:27):
I don't have that choice
Grahame Grieve (Sep 11 2018 at 22:28):
typically, I am doing bug fixes while debugging something. Can't remove everything the debugger is running on while running it.
Josh Mandel (Sep 11 2018 at 22:28):
The thing that really puzzles me here is that git is incredibly flexible when it comes to work flow. If you want, you can just make all your changes on a Graham WIP branch and merge that into Master occasionally.
Grahame Grieve (Sep 11 2018 at 22:28):
what is hard about this? Surely this is how everyone works? What else to do? twiddle thumbs?
Josh Mandel (Sep 11 2018 at 22:28):
I wouldn't consider that to be a best practice but you can emulate anything you do in svn that way.
Rob Hausam (Sep 11 2018 at 22:28):
right
Grahame Grieve (Sep 11 2018 at 22:28):
If you want, you can just make all your changes on a Graham WIP branch and merge that into Master occasionally.
But then you can't commit stuff for things one at a time
Grahame Grieve (Sep 11 2018 at 22:29):
I'm just trying to emulate my existing workflow I'm dependent on, and the advice is: can't do that
Josh Mandel (Sep 11 2018 at 22:29):
You can commits individually. You might just wind up merging groups of features at once.
Josh Mandel (Sep 11 2018 at 22:29):
So you can have a bug fix commit on your general work-in-progress branch.
Grahame Grieve (Sep 11 2018 at 22:30):
in other words: once I start working on something, I cannot also do a bug fix and commit it in isolation
Rob Hausam (Sep 11 2018 at 22:31):
I think we're mixing commit and push here, and that's making it more confusing
Josh Mandel (Sep 11 2018 at 22:31):
You can absolutely do that. when you say commit in isolation, do you mean commit and merge to the master branch in isolation from the work you are doing in a future branch? And without changing branches ever?
Josh Mandel (Sep 11 2018 at 22:31):
Yes, we are mixing commit, push, and merge.
Grahame Grieve (Sep 11 2018 at 22:32):
I don't have any idea what you think I'm mixing. I'm asking a really simple question to me: I'm doing some big changes, partially committed. I'm also making a bug fix. I want to get the change for the bug fix up to the master without committing the unfinished work, and without having to lose it from my local workspace
Grahame Grieve (Sep 11 2018 at 22:32):
I never made an svn commit without that being true
Rob Hausam (Sep 11 2018 at 22:34):
I think what you really want to do in that case is cherry-pick the bug fix commit and merge it (and it alone) into master.
Josh Mandel (Sep 11 2018 at 22:34):
The typical workflow is to make a bug fix Branch off of Master, fix the bug, push it up, and merge this branch into your feature branch.
Josh Mandel (Sep 11 2018 at 22:34):
The challenge for Grahame is he wants to do this without ever running "git checkout". So as not to cause some files to disappear from his debugger.
Grahame Grieve (Sep 11 2018 at 22:34):
but I can't switch to the branch for the bug fix without trashing my local local
Grahame Grieve (Sep 11 2018 at 22:34):
yes
Josh Mandel (Sep 11 2018 at 22:37):
The best suggestion I have for you here is to suspend the debugger while you commit on another branch and merge that branch into your feature branch.
Grahame Grieve (Sep 11 2018 at 22:39):
this is entirely not a workable response for me
Josh Mandel (Sep 11 2018 at 22:39):
Or maybe better: edit the file locally but don't push until you have the debugger session over with.
Rob Hausam (Sep 11 2018 at 22:44):
If you want to do everything in a single "work" branch (I'm still not sure if that's actually what you want to do), you can make the bug fix commit in the midst of everything else that you are doing and then cherry-pick that commit alone directly into the master branch (with no pull request - we might have turned the ability to do that off, but it could be enabled). That will get the fix published separately and will not mess with anything else that you are doing. I don't think it's considered to be very "orthodox" from the git perspective, but I think it should work.
Grahame Grieve (Sep 11 2018 at 22:45):
I think that there might be a place for committing directly to master but it must very much be a special case. And not for this workflow.
Rob Hausam (Sep 11 2018 at 22:53):
It's not exactly committing directly to master (although a new commit is also created there), as you've first committed it in your work branch (or wherever). Other than the "extra" commit to master I think it's not too different from what we're always doing now in svn. I'm not saying I recommend it, but something to consider.
Grahame Grieve (Sep 11 2018 at 22:54):
well, yes, it's not too different. It's not too different in an important and bad way: the whole point of all this was to protect the build, which we didn't have in svn
Rob Hausam (Sep 11 2018 at 22:56):
Can't disagree there, either. So to achieve that the workflow has to change. But maybe you could be the only one allowed to do this - for when it really is a better workflow for you (and is also sufficiently safe to do)?
Grahame Grieve (Sep 11 2018 at 23:01):
I think we all know that it's not that safe for me to do, based on experience
Grahame Grieve (Sep 12 2018 at 00:32):
https://stackoverflow.com/questions/42467062/commit-a-single-file-to-another-branch
Grahame Grieve (Sep 12 2018 at 00:32):
that's my case right there
Grahame Grieve (Sep 12 2018 at 00:32):
as I said, does not everyone do this?
Josh Mandel (Sep 12 2018 at 03:02):
I guess not -- or perhals just not in a context where running "git checkout"' is an issue.
Last updated: Apr 12 2022 at 19:14 UTC
