31–40 of 178 posts
why do people rebase so often? shouldn't it be excluded from the usual workflows as you are losing commit history as well?
why do people rebase so often? shouldn't it be excluded from the usual workflows as you are losing commit history as well?
And in the feature branches/merge requests, I don’t merge, only rebase. Rebasing should be the default workflow. Merging adds so many problems for no good reason.
There are use cases for merging, but not as the normal workflow.
Earlier quoted context omitted.
I write really poopy commit messages. Think "WIP" type nonsense. I branch off of the trunk, even my branch name is poopy like feature/{first initial} {last initial} DONOTMERGE {yyyy-MM-dd-hh-mm-ss} Yes, the branch name literally says do not merge. I commit anything and everything. Build fails? I still commit. If there is a stopping point and I feel like I might want to come back to this point, I commit. I am violentl…
Isn't your tale more about squashing than rebasing?
why do people rebase so often? shouldn't it be excluded from the usual workflows as you are losing commit history as well?
But even if i wasn't using gerrit, sometimes its the easiest way to fix branches that are broken or restructure your work in a more clear way
Earlier quoted context omitted.
> I don't want to commit something that doesn't build. This is a really interesting perspective. Personally I commit code that will fail the build multiple times per day. I only care that something builds at the point it gets merged to master.
so basically, not adhering to atomic commits. That's fine if it's a deliberate choice, but some people like me think commits should stand on their own. (i'm assuming your are not squashing when merging, else it's pretty much the same workflow)
What do you do when you are working on something and are forced to switch to working on something else in the middle of it?
This was a really interesting read. I'd highly recommend it for anybody who's setting up (or currently maintains) a pre-commit workflow for their developers. I want to add one other note: in any large organization, some developers will use tools in ways nobody can predict. This includes Git. Don't try to force any particular workflow, including mandatory or automatically-enabled hooks. Instead, put what you want in a…
> This includes Git. Don't try to force any particular workflow, including mandatory or automatically-enabled hooks. And with git, you can even make anything that happens on the dev machines mandatory. Anything you want to be mandatory needs to go into your CI. Pre-commit and pre-push hooks are just there to lower CI churn, not to guarantee anything. (With the exception of people accidentally pushing secrets. The CI…
Earlier quoted context omitted.
I write really poopy commit messages. Think "WIP" type nonsense. I branch off of the trunk, even my branch name is poopy like feature/{first initial} {last initial} DONOTMERGE {yyyy-MM-dd-hh-mm-ss} Yes, the branch name literally says do not merge. I commit anything and everything. Build fails? I still commit. If there is a stopping point and I feel like I might want to come back to this point, I commit. I am violentl…
Isn't your tale more about squashing than rebasing?
Rebasing is kind of a short hand for cherry-picking, fixing up, rewording, squashing, dropping, etc. because these things don't make sense in isolation.
Yep, all that and they’re also annoying. Version control tools are not supposed to argue - do what you’re told. If I messed up, the branch build will tell me.
Earlier quoted context omitted.
so basically, not adhering to atomic commits. That's fine if it's a deliberate choice, but some people like me think commits should stand on their own. (i'm assuming your are not squashing when merging, else it's pretty much the same workflow)
Honestly, i find that a really weird view. I use (Local) commits for work in progress. I feel like insisting on atomic commits in your local checkout defeats the entire purpose of using a tool like git. What do you do when you are working on something and are forced to switch to working on something else in the middle of it?
I usually put it on a branch, even if this project otherwise does all its development on the main branch. And I commit it without running precommits, and with a commit message prefix "WIP: ". If it's on a branch you can even push it to not lose work if your local machine breaks/is stolen.
When it's time to get it into the main branch I rebase to squash commits into working ones.
Now, if my final commit history of say 3 commits all actually build at each commit? For personal projects, no. Diminishing returns. But in a collaborative environment: How fun will it be for future you, or your team mates, to run bisect if half the commits don't even build?
I have this workflow because it's so easy to add a feature, breaking 3 tests, to be fixed later. And formatting is bad. And now I add another change, and I just keep digging and one can end up in a "oh no, how did I end up here?" state where different binaries in the tree need to be synced to different commits to even build.
> I feel like insisting on atomic commits in your local checkout defeats the entire purpose of using a tool like git.
WIP commits is hardly the only benefit of git or other DVCS over things like subversion.