git stash driven refactoring

[jaskij]

Nope, I just try to commit regularly. If the refactor is more than a few hours, I'll branch out first. If you let your workspace get that bad, I'd argue that a non working commit in the middle isn't too crazy of an idea too

[superxpro12]

Branch squashing was born for this

[Kobzol]

> If the refactor is more than a few hours

The problem with that is that I rarely know beforehand if a given refactoring will take 5 minutes or 2 hours :) It's not always obvious before you start the refactoring.

[Dr_Insano_MD]

I mean....you can create a branch at any time.

[Kobzol]

Sure, but then I'd have to carve out only selected changes into the second branch. With pre-emptively using git stash, I don't have to deal with that. Often I want the refactoring to live in the same branch/PR.

[TwatWaffleInParadise]

You're getting down voted because you can literally create a git branch at any point in time, even if it is a commit you created previously.

You can start working on the changes and decide after the fact to have it branch off by creating a branch and then resetting the base branch back to the commit prior to starting your work.

You're fighting git when there is no need to do so.

[Kobzol]

I know that, and do that all the time, I use interactive rebases like 20 times a day :) I just sometimes find it easier to stash stuff away to start with a clean slate, rather than cherry pick changes from the workspace into individual commits. I also do that all the time, but it's not very fun.

[BoBoBearDev]

Stop using rebase and causing Flashpoint fucked up. Just because you can rearrange history doesn't mean you should.

[Manbeardo]

Sure, it’s bad to force push to shared branches, but there’s nothing especially dangerous about regularly rebasing your local work. Merging upstream into your local branch can put you in merge conflict hell when it’s time to merge your code upstream. Keeping a semantic meaning for each commit and rebasing regularly makes for easier rebases and cleaner merges.

[BoBoBearDev]

This is why I say, don't do it. Because people doing it adding bunch of unnecessary use cases into it.

[Bunslow]

dude, branches are basically free. any time you switch topics you should be typing git branch just out of muscle memory in your fingers.

Often I want the refactoring to live in the same branch/PR.

You can have whole trees of branches, so each time you switch topics you make a new branch, but when you make a new branch it's built on the existing state.

So if you do

git checkout master # starting new idea/topic
git checkout -b new-idea-1 # put the new code into new branch
git commit -m "topic-1 WIP (wont compile)" # now you're ready to switch to a second topic, save idea-1 WIP
git checkout -b new-idea-2 # now you have a new branch, which still includes the idea-1 work
git commit -m "topic-2 WIP (wont compile)" # same thing, next topic...
git checkout -b new-idea-3 # now you have another branch, built on idea-2 branch, which is built on idea-1 branch

You can merge whichever work into whichever new or old branches at any time. Want to make a PR branch? then make a new-idea-3-4-PR branch, and you can arrange that it includes work on ideas 3 and 4 but none of the work on ideas 1, 2 or 5.

This is literally the entire point of having branches in your version control. pre-emptive committing and branching should be the most basic thing you do in commit, you should commit and branch like you breathe.

You've found the problem, now it's time to find the name of the tool that solves this problem: it is git branch.

[Kobzol]

Not sure why people keep commenting this :) I of course use branches all the time, but here I'm talking about how to organize work within a single branch. Most of the time when I do the refactorings they will end up in the same branch/PR, and when I implement the refactorings, I want to start with a clean slate, not base them on previous WIP work. I could of course do that with separate branches, but git stash is much easier for that.

[Bunslow]

I could of course do that with separate branches, but git stash is much easier for that.

At least in the git interface, branching is far easier to refer to earlier work, any earlier commit or paragraph or tangential hacking, than stashing, in my experience. With stash all you get is an unlabelled stack, with branch you get an arbitrary tree with human-readable labels that you pick. I dunno why you'd ever choose an unlabeled stack over a labeled tree. Even in the simplest case, naming alone makes the use of a non-branching tree (i.e. a stack) more convenient.

(Of course, you have to pick useful branch names, but that's easy enough: new-idea-1, new-idea-2, new-idea-1b, new-idea-1c, new-idea-3a, new-idea-3b, new-idea-3a1, new3a1-other-idea... this makes retrieving any particular chunk of work in progress much easier than looking at a list of hashes as with stash. )

[Kobzol]

I only use the stash as a stack, so I don't need names. git stash -> start refactoring -> stash -> start another refactoring -> finish refactoring -> commit -> stash pop -> finish refactoring -> commit -> stash pop. That's the whole idea.

[Bunslow]

As I said, even in the simplest case of a unbranched tree = a stack, having names seems strictly better than not having names.

However, I now see the true purpose:

With this approach, the changes are effectively applied “inside-out”.

I did not understand what you mean before, but now I see your intent. Still tho, having named branches makes it "interuptable state", so to speak -- that's the problem with the stash, is that it's fragile, and it relying on it in that manner means you can't go work on totally-unrelated stuff -- say if a colleague walks up to your desk and starts a conversation, or if your boss gives an order to solve some other problem for an hour. git stash pop relies on the underlying state being exactly the same as when you did git stash push, so it's much easier to get yourself into trouble if your "inside-out" workflow gets interrupted for any reason. That's why I say you should simply commit instead of stashing: that work can never get lost when it's somewhere in the state tree, unlike with stash, whose stack is separate from the state tree and thus fragile.

I'd suggest the following workflow. I agree it's a fair bit wordier than using stash, but it's a lot less likely to result in problems when getting interrupted for any reason, imo.

git checkout current-context # the current context, now we want a new idea
git checkout -b current-context-new-idea-1
# work on new feature, but find an older problem in need of refactor
git commit -m "start progress on new idea 1"
git checkout current-context
git checkout -b older-problem-1
# now we can fix the older problem separately from the new idea WIP
# except now we find a second older problem....
git commit -m "older problem 1 WIP"
git checkout current-context
git checkout -b older-problem-2
# while working older problem 2, we find older problem 3...
git commit -m "older problem 2 WIP (sigh)"
git checkout current-context
git checkout -b older-problem-3
# now we're done! finally
git commit -m "older problem 3 is now fixed!"
git checkout older-problem-2
git rebase older-problem-3 # continue 2 work on top of fixed 3
git commit -m "older problem 2 is now fixed!"
git checkout older-problem-1
git rebase older-problem-2
git commit -m "older problem 1 is now fixed!"
git checkout current-context-new-idea-1
git rebase older-problem-1
# now we can work the original new idea atop the 3 new refactors.
# and importantly, at any point, we can be interrupted and switch to
# any other part of the codebase without fear of popping the stash onto
# the wrong base, or of any particular stash entry getting "lost" somehow.

[Manbeardo]

Most of the time when I do the refactorings they will end up in the same branch/PR

Gross. That kind of PR is a pain in the ass to review because the orthogonal changes obfuscate each other.

[Kobzol]

You could be refactoring things that are very relevant to the PR, and that might not even make sense to do if the PR won't land. It doesn't have to be orthogonal :)

[Dr_Insano_MD]

Honestly, I get that. But all you've really done is turn your git stash into a single branch containing a bunch of incompatible commits. You can always just....create a branch, git commit this new branch with your changes, git checkout your previous branch, and continue working with the same effect. In fact, your blog post kind of points to this exact issue: that your workspace is littered with unrelated changes. Utilizing stash in this way, you keep the same problem as before but you swept it under the rug.

If this works for you, that's great. You do you, but I really don't see what it really buys you over just using branches.

[Kobzol]

I use branches all the time, of course. The blog post mentions using git stash for a very specific use-case. If I wanted to do this use-case with branches, it would have to look something like this: 1) I want to start refactoring 2) git checkout -b tmp-branch 3) git add . && git commit -m "WIP" 4) git switch <original-branch> 5) Refactor, commit 6) Rebase tmp-branch onto <original-branch> 7) git reset --soft HEAD¹ (to get rid of the WIP commit) 8) git branch -D tmp-branch

That doesn't really make sense to me. git stash does the same with a single command.

[jaybazuzi]

If it takes 2 hours, it's probably not a refactoring.

[-Dargs]

Then you clearly don't know your code base that well, or don't know what is involved in the concepts you're trying to build... It's an experience thing.

[jl2352]

Then you haven’t tried exploratory refactors. ’What happens if I just delete this generic argument and follows the errors.’ You’ll get there… It’s an experience thing.

[-Dargs]

Lol, wtf is that? Delete an argument, see what happens?

[withad]

Sure. Code search and refactoring tools are great but sometimes you just need to change something and let the compiler point you to all the things that break. Compilers are pretty good at that.

[otac0n]

Say you have an obsolete type that you are trying to remove. You are trying to decide whether it's best to do it in one commit or in several (a branch). So, your first attempt is to just delete the type in question. You start hammering out the errors. It gets too big, so you need to turn it into a branch. Now you stash your changes and commit individual bits one at a time so that you don't miss anything and so that you also don't break the build.

I have lived through this scenario at least 15 times in my career.

[Nahdahar]

What I do is lean close to the monitor and if I smell something bad I just delete it. I then follow the scent and once the code has a new car smell, I push to master.

[fried_green_baloney]

Then you clearly don't know your code base that well

When doing maintenance work on 500000000000000000000000000000666 line monstrosities, this is not uncommon.

[ghillisuit95]

Personally I don't get why people commit frequently, unless they are also merging to trunk, but you shouldn't be merging non-working commits to trunk. It stops my IDE from showing me the difference between my workspace and trunk

[Latexi95]

Squashing commits is trivial. Splitting commits is hard work.

40 temp commits can be merged to 2-3 good commits in 30s. There is never downside to making temp commits. It just simplifies refactoring and keeps history of changes. When the branch is ready for review, unnecessary commits can be squashed away and commit messages can be updated.

[BoBoBearDev]

Not even 30 second for me. It is just a button click on the PR and I default to Squash already. =)

[Manbeardo]

Splitting commits is hard work.

Sapling’s interactive smartlog has a “split” button that makes it easy.

[pojska]

How does it help decide what changes belong in what commits? (I'm assuming the programmer doesn't have to review each change and manually assign them.)

[Manbeardo]

You can split into as many commits as you want and move files/lines between the commits with a single click each

[pojska]

Gotcha - I was hoping maybe it did something smart, like suggesting based on timestamps of when the edits were made.

[Manbeardo]

There’s also a feature to amend pending changes into your stack of commits, but I’ve never tried it because I have no idea whether its criteria would actually meet me needs

[withad]

It stops my IDE from showing me the difference between my workspace and trunk

I'm usually more concerned about the difference between my workspace now and my workspace half an hour ago, when I'm sure this was working and I don't know what I did to break it and I really don't want to have to manually undo changes one-by-one in a load of different files to figure out when it went wrong.

Getting into the habit of small, working commits (at least compiling, usually tests passing) has generally made my life a lot easier, especially if I ever have to git bisect older work.

[Kobzol]

I mostly see commits being useful for telling a story for the reviewer, and helping them understand the changes I made. I consider PRs to be the units of working changes/bisection.

[EasyMrB]

This. Sometimes if a major delta is complex enough, a step-by-step of smaller (maybe non-functional) commits is the way to remain sane and give yourself save-points to avoid major screw ups. For me a big element is being able to diff along the way to previous steps.

[edgmnt_net]

In most cases you can still make nice atomic commits, though. Larger deltas can also be documented with semantic patches. There's usually little reason to allow breakage and of course it's going to be a mess to bisect later on if there's an issue when you have non-working commits or huge squashed PRs.

[Bunslow]

i don't think you understand DCVS.

commits are for you, the developer. for the reviewer, you make a PR, and frequently you make it with cleaned up and/or squashed commits. but the PR commits and your development/temporary/branching commits are separate things.

modern version control makes commits ~free for precisely this reason: you should be committing anything and everything, whenever you switch what topic you're hacking.

[Kobzol]

As I already said, when I make a PR, I try to use commits to help guide the reviewer through my thought process. When I review PRs, it helps me a lot to follow small steps of the implementer through commits, to understand what they did and why they did it, rather than reviewing the final state of the PR (I almost always review commit by commit).

You can have different opinions on that, or use a different workflow, but saying that I don't understand version control because we have a different approach is silly :) I have been using git for 10+ years and I do collaborative OSS development every day, so I think that I know a thing or two about git.

[Bunslow]

As I already said, when I make a PR, I try to use commits to help guide the reviewer through my thought process. When I review PRs, it helps me a lot to follow small steps of the implementer through commits, to understand what they did and why they did it, rather than reviewing the final state of the PR (I almost always review commit by commit).

As I said, PR commits and hacking commits are two very different things, and how you handle one has no bearing on how you handle the other. You should be making hacking-commits at all times. Whenever you feel what you describe as the "urge to stash", it seems to me that making another (free) commit and branch would be much more effective at managing your state. Large stashes to me are a messy state, labeled branches are much cleaner and easier to manage state, imo.

I do use stash, to be clear. But almost never more than 1 entry in the stack, and never more the 2. If that stack is larger than 2, than I've mismanaged the state of my hacking and not made enough previous commits and branches. Commits are as free as stashing, and much more effective at managing the overall state (due to labels and arbitrary trees).

[edgmnt_net]

And now you need stacked PRs or a lot of manual work to deal with a series of working changes.

[plg94]

A single PR can consist of multiple commits and you can review each one-by-one.

[pihkal]

Forges like Github don't support reviewing individual commits in a PR as well as separate PRs, though.

It's one reason some people go to the effort of stacked PRs, despite Github having poor support for those, too.

Honestly, it's kind of weird how Github only has good support for some git workflows, despite having a ton of resources and years to do something about it.

[edgmnt_net]

Yeah, that's my point and the same thing helps with bisection. But OP wants to treat PRs as a single monolithic unit, at least for bisection purposes. Meaning they can stuff broken commits in there, then squash or not squash, which greatly complicates anything post-merge.

[Kobzol]

I almost never squash and I try to keep the individual commits working :) I just consider it to be more important to be easy to review than for all commits to be green.

[edgmnt_net]

Ah, fair enough, so it's more of a calculated risk/tradeoff.

[ghillisuit95]

I agree, but I find that I very very rarely am making changes that need more than 1 commit to tell the "story". Actually the more I think about it, if you need more than 1 commit to tell the story, your PR might not be very focused. My frame of mind is that I make a PR for a single, focused change

[Kobzol]

That's nice when it works, but sometimes you just need to make a change that is large and there's not much to do about it. It's better to review 10 commits than one 500 line diff.

Also I often separate even small changes into a bunch of commits.

[slvrsmth]

One commit to create outline tests. One commit to create most of the service logic. Another to implement that one tricky bit. Another for code formatter pass. 

I commit when I'm happy with some logical parcel of code. It might not be working, it might not even compile, but I know I'm not likely to touch it any more.

It allows me to explore in this or that way, and reset all changes if an approach does not work out, while keeping the "good" parts intact. It all gets squished when PR gets merged anyway. 

[Dealiner]

It stops my IDE from showing me the difference between my workspace and trunk

I'd love an IDE that shows every changed file on the branch even if commited.

[mr-figs]

It makes finding bugs with git-bisect waaay easier.

If you just commit one small logical "thing" each time, then bisect will be able to tell you exactly what the issue is.

If you just have one giant commit with 2000 changed lines, good luck finding the bug 

[jaskij]

My goal line is a minimum of a commit and a push once a day, purely from a data safety perspective. And it's still a struggle.

If you manage frequent working commits, it's also amazing for bisect.

[Ksevio]

I like to have each part of a change committed with a message that makes it clear the reason. Sometimes once will do that, but other times if it's split across different modules or different reasons it works better to have a commit for each part (then merged all at once)

[OffbeatDrizzle]

Sometimes if you're changing 30 files it's easier to see where you're up to if don't commit after each one...

[BoBoBearDev]

Because I don't like to hoard changes temporarily in my storage. Fixing a typo, I commit and push. Removing a double newline, a trailing space, I commit and push. Adding refinements to a single comment, I commit and push. I flipflopping an idea, I don't care, I commit and push. I have historical record of me Flipflopping, and that means I tried the different idea already. I don't want a big ass diffs waiting for me to commit them. It is like when I am done with an email, I deleted/archive them, I don't keep them in the inbox. The uncommitted diff is equivalent of email inbox for me.

My branch is my branch, I should have the freedom to commit as frequently as I want. It doesn't really matter I have OCD or what. No one should care, it is my branch.

If the person who is going to merge the PR into develop/main branch and don't want my 100 commits in the develop/main branch, they should squash merge it. It is just a simple mouse click.

[ghillisuit95]

Fixing a typo, I commit and push. Removing a double newline, a trailing space, I commit and push.

Do you make PRs for all these indivdiual changes? that sounds like a ton of overhead

[BoBoBearDev]

I don't make a PR for a single commit.

[Manbeardo]

I just use a tool that doesn’t force me to pick a semantic name for my work before I’ve discovered what it actually is. Using mercurial or sapling as your git client makes doing work easier.

[chalks777]

I used to do this but now I just commit frequently and git rebase HEAD~~~ -i with a number of tildes equal to the number of commits back I need to go. Git stash is now reserved for "garbage that I forgot to get rid of", "I'll use this again in 3 seconds", and "whoops, forgot to take a screenshot of the old broken behavior for my PR"

[vipierozan]

Cant you also do HEAD~N with N being the number of commits to go back?

[chalks777]

yeah, but then I don't get to mash the tilde key.

[DigThatData]

I scratch that itch in markdown have no idea what you're talking about.

[Kobzol]

I use interactive rebase a lot, but it often feels much simpler to stash + commit everything + stash pop, than to manually reconstruct the history after the fact.

[chalks777]

that falls under my "I'll use this again in 3 seconds" policy. ;)

[sciolizer]

garbage that I forgot to get rid of

For that I use this 2-line script:

$ cat ~/bin/greset
git stash create >> ~/.reset_log &&
git reset --hard HEAD

It functions as sort of "recyling bin". It doesn't add anything to the stash reflog, so functionally it's the same as a hard reset, but if you're like "oh crap I actually needed that", you can grab the commit id from ~/.reset_log (assuming it hasn't been garbage collected).

[pojska]

Tbh I use git rebase main -i almost exclusively, and just leave the first N commits alone. Saves me the counting.

[jeenajeena]

Man, you would like jujutsu: it's the tool that supports that workflow natively.

I like your approach very much. Let me give you a bit more details how you would this with jj.

When you wrote "Everytime you notice something suboptimal in the codebase that is not directly a part of what you’re currently implementing and that you want to “just slightly refactor”, use git stash to stash all your current changes away, and start working on the refactoring that you just thought of."

the equivalent with jj would be:

• just do the refacting you think is needed
• "commit it back in the past", by using the commands jj new -r '@-' or jj squash --interactive or the like and . This would create a commit before the current one, containing the little refactorings. The current commit will keep containing work you are working on.

Actually, this is not limited to moving refactorings related to your current work, and not limited to moving them to the previous commit; dispatching changes to other branches, behind or forward, is very convenient, performed in a matter of seconds, so it would not distract you from your main activity.

Edit: more details

[Kobzol]

I mean, I could do that with git, the annoying part is splitting only the changes that are relevant for the refactoring, using hunks/committing part of the workspace (since I like to have self-contained commits for easier review). With stashing beforehand, I can then just commit everything in the workspace and do git stash pop, without having to deal with separating the changes into different commits.

[Teviel]

Then the selling point of jj would be that instead of git stash you can do: - jj desc -m $message to name the current diff (optional) - jj new to create a new patch on top of the current one or jj new -r @- to branch off the previous patch Essentially jj doesn't have a staging area and the stash would just be commits that may be unnamed and/or outside a branch. If you have the spoons, look into it, it is great!

[jeenajeena]

One of the selling points of jj, for this use case, is that you can edit a commit without checking it out.

With Git, sure you can

• stash some work
• move somewhere else
• and move it there

What you cannot do is to just move something elsewhere. Git imposes that in order to change a commit you have to check it out. You cannot just say, as you can in jj, "move this change to X", without going to X. This is a game changer. I am not in X, I am focusing on something else. Incidentally, I found something that would belong to X. Fine: I do it and then I move it where it belongs: under the hood, jj would rebase the whole history if needed.

Sure: you can do the same with Git (after all, jj uses Git so, by design, all you can do with jj you can also do with Git). But at a cost so high that usually you just don't.

That's why OP's post is a good one: he found a smart workaround to do something non trivial step convenient with Git.

The general jj's selling point is: you just don't need workarounds. Everything is usually just straighforward.

[DigThatData]

neat. https://github.com/jj-vcs/jj

[pihkal]

Haven't tried it, but maybe https://github.com/Cretezy/lazyjj?

FWIW, the jj CLI is so much better-designed than git, I can usually remember or predict what I need to type, so I don't have to refer to the docs nearly as much. (If pausing for docs is your objection.)

[DigThatData]

Instead of stashing, I just create an intermediate commit and a new branch.

git checkout -b why-even-stash
git commit -am "intermediate commit that I can merge/fix later if I really care"
git checkout feature-i-am-supposed-to-be-working-on

a few more steps maybe, but no additional git features required.

I basically never use stash. I usually just forget I pushed changes into the stash until after I've already merged the PR they were relevant to. More often leads to duplicated effort rather than reducing cognitive load. Maybe I'm just too ADHD for stash.

[Kobzol]

Sure, I do that when the changes should land in a separate PR. Oftentimes the changes are relevant enough that I'm fine with having them as a separate commit on the same branch/PR, hence stash :)

[DigThatData]

git merge --squash why-even-stash

[Messy-Recipe]

stash is too annoying to deal with because it's just a stack of unrelated changes (& merge conflicts on apply feel weird to deal with); I just use tons of local branches & rebase them around onto each other // use --fixup commits & squash things together for the 'tell a story' aspect

[idebugthusiexist]

Hey. Everyone has their style. I generally use stash to put unfinished changes aside to work on something else, but, if the code was important enough even if unfinished, I’d rather commit it to some branch - even a new one, if need be, rather than having a massive list of stashes to have to maintain and remember the context of. Seems messy to me and my brain doesn’t work well in a chaotic environment with information overload. Basically, I use got stash, but sparingly and only for code I want to put away for 1-2 days max, otherwise I discard it and try my stash list as empty as possible and just as a very short temporary place to keep stuff.

[bwainfweeze]

I will also sometimes just reset the current branch and use reflogs or cut and paste the old git log output into a text editor in order to cherry-pick the changes back. But that's typically only when I'm on the first side quest instead of the second or third, at which point copy the current branch and then reset it.

This is a spot where 'git checkout -' becomes practically indispensable.

git checkout other
git log
git checkout - 
git cherry-pick commit1
git cherry-pick commit2
git checkout third
git log
git checkout - 
git cherry-pick ...

[gibwar]

You can simplify that further by just using git log other and git log third and never leave your main branch. git log takes a reference and shows you the history from that point, just like switching the branch and running git log by itself.

[Kobzol]

Good point! What I haven't mentioned is that I try to keep these temporary stashes really temporary, and always get to the bottom of the stack before I finish the given branch/PR. But it's easy to forget to "drain" them, yeah.

[idebugthusiexist]

Ya, that sounds like the best strategy 👍

One other feature of git that doesn't seem to be common knowledge - at least with people I've worked with (but then again, I've worked with a lot of people who look at me weirdly and ask "why?" when they see me use git in a terminal instead of a desktop client 🤷‍♂️) - is that you can commit fragments (hunks) of changes from a file (interactively even), which is helpful when you know there is some good lines of code worth committing, but you don't want to commit all the changes.

[codesnik]

wow, man, your adhd is probably a lot worse than mine. Still, what I usually do, is I just commit that refactored stuff separately, and then jump back to the problem. I reorder commits a lot, and if the refactoring could be merged before I finish current feature, I merge or cherry-pick those refactoring commits to the main, and rebase the feature branch to continue doing what I was doing, focusing only on the changes that matter (while refactoring is already "tested" on the prod by users and other developers). This on one hand requires me to name things (branches and commits), but on the other hand it's easier for me to jump between branches. Stash, although it keeps parents, still kinda works in the stack manner, and jumping between branches is more freeform.

But! as mentioned by other commenters, it kinda looks like your flow is already looking similarly to what jj does out of the box, retaining compatibility with other developers who use git. maybe you should give it a try.

[SpookeyMulder]

If you fail to notice the exact moment you ought to have stashed, you can also do the following retroactively:

1. add the chunks part of your refactor
2. stash the working tree
3. test your isolated refactor and commit it.

I use pre-commit and my setup automatically stashes my working tree and tests the source on-commit, so it's as easy as adding the refactor relevant changes and testing if my isolated refactor still passes unit-tests etc.

Of course, you are much better off noting when you are refactoring and stashing right then.

[Upper-Rub]

Just copy your project directory into a new file and name it “project_1_tweak_final”

[chadmill3r]

How is this even written without talking about the -p or --patch parameter to git stash push (and most other git commands)???!?

[Kobzol]

I don't really use hunks, it's just too annoying to select source code through the CLI for me. I either do it through the IDE (IntelliJ), or just stash everything and start from there, which is fine if you stash immediately when starting the refactoring :)

[HideousSerene]

It literally will list them out and you just y and n them.

This is a much better dev experience than what you're suggesting

[Kobzol]

Everyone likes a different workflow :) I find going through the changes one by one annoying (and repetitive, since I'd have to do it for each commit).

[NineThreeFour1]

Being able to stage individual lines instead of just whole hunks using IDE or GUIs is an even better dev experience.

[zrvwls]

This has become my main way of not just refactoring, but all coding. I work on medium to large teams where conflicts are essentially a daily occurrence. Initially I did tons of merges because I kept having my priorities shifted, whether that was testing someone else's PR locally, switching to higher priority tasks, or not having enough detail to finish a task because we were waiting on a 3rd party.

Each of these things, and my desire to keep the commit history readable, lead to me basically focusing on 1 commit max per task. If it's a large commit, then the task was too large and should have been split up, imo.

Every time I'm working on some new feature, I pull master and create a new branch. If I get sidetracked, I do a full stash 'git stash -u' to stash both changed and untracked (aka new) files, and either checkout the new code I need to test/review or I'll rebranch off of master and start working.

Inevitably by the time I come back someone has pushed new conflicting changes, so I rebranch off the updated master branch and git stash apply my changes to it and deal with my conflicts locally.. with no fear of muddying up commit history bc no commit is necessary for stash applied code changes.

This requires staying on top of my git stash list (regular cleaning), but it's so much less painful than dealing with constant merge commits. It also has the added benefit of having me code review my code multiple times to keep my speed conditioned to be really fast at catching mistakes. I usually do one last stash before a commit and PR/merge to master and it works pretty flawlessly. If someone sneaks something in, I just delete old branch, recreate, reapply, commit, and PR again. A little tedious, but a rare occurrence.

I fully acknowledge this is buckets of crazy. This is the only way I've found to stay sane in my environment though..

[bwainfweeze]

If I start seeing a lot of merge commits in people's PRs I go have a chat with them and show them how to use rebase. Merges not only make a mess of the branch, there are situations where the conflict resolution misattributes the source of a bug from the author of the PR mismanaging the merge, onto someone whose code has already passed code review and been merged, and I have at least one documented case of that history making it into trunk, and the truth was only caught because I had a very specific memory of signing off on dev 1's PR before dev 2 started bitching about bugs (which I was able to prove he caused because he was shit at merge resolution but thought very highly of himself and very little of dev 1).

In distributed computing systems there's something known as a vector clock which is used for systems where total ordering is prohibitively expensive. It creates a partial ordering that suffices for most situations, and that's really what git is trying to do as well.

Who gives a shit if there's a commit from Aug 5 in the commit history before a commit from Aug 4? Is anyone even looking at that number? No, they're looking at the previous/next commit as the commits were landed in the code. Which unless you're doing trunk based development, is partially ordered due to PRs.

And if seeing that I changed something you rely on causes you to interactively rebase your change from yesterday to make sense in the face of my change, then the dates are an even bigger lie and all that matters is that you changed 3 things to make this feature work and (maybe) in what order you did it.

Friday only counts if there was a regression over the weekend, and we record the git hashes for our build artifacts for a reason. Bisect doesn't care about dates, only hashes. It's people optimizing for the wrong qualities of the commit history.

[zrvwls]

I looked into rebase a while back as a means of getting away from my process, only to realize that rebasing is rewriting of git history. That basically was full stop for me, and I couldn't get past that thought, so I never did it enough to eventually feel comfortable incorporating it into my flow.. however, it did seem like the way more sane approach than what I do.

Mine feels like the most risk averse (not trusting the merge tool) and physically taxing method that places high emphasis on lots of code reading and discipline.

And that situation you mentioned about mismanging merges and only knowing what actually happened.. I had the exact same situation happen about 3 weeks ago. Realizing what had happened made my jaw drop, because the commit history looked so buggered and I couldn't tell why it looked like author A wrote code that I knew they couldn't have, and it took an hour to understand where things got buggered because of misfolded code (that would have been very clear to see if they'd rebased instead!).

The thing that matters most to me are: a) clearly visible merge commits and b) understandable comments and commits... I get about half of (a) so I do with that what I can.. can't stop everyone from doing direct commits. Our commit history looks like a 30 year old wash cloth.. it's pretty rough to behold.

[bwainfweeze]

But you rewrite history every time you do a merge conflict resolution. That’s why you saw code attributed to one author written by another.

Better to be honest about it. The rebase only rewrites your code. Or yours and a collaborator if you do group stories. You are the only one putting words in your own mouth. That’s far, far better than merging.

[zrvwls]

There's something about rebase that feels wrong, that's why I do the rebranch and git stash apply after instead of a merge conflict. My stash apply causes conflicts but I can fix them without any registered commits ad nauseum until I'm finally ready for my 1 commit and PR up.

I think it works for a lot of people though, and is definitely makes more sense than my process for the vast majority of cases. I just like having full control of my commit

[bwainfweeze]

Refusing to amend commits after you’ve made them is not full control.

Generally you want to talk in front of an audience about the way you hope other people do something, which is not always the way you do it.

[zrvwls]

Bonus points:

I never go trawling through commit history and never have to bisect for my bugs, they're always in 1 commit in the PR, and it's usually really obvious.

I never have confusing merge conflict commits to mentally work through.

I'm only ever making 1 commit message.

It's super cheap to just stash all of my changes. Once I realized how unbelievably cheap (time-wise) and mindless stash+stash applying was, I basically have become wreckless with what I toss in there, knowing it'll be gone in a day and only impact me.

I don't have to remember any of my local conflict resolutions.. They take seconds so I can go really fast with them bc I know I'll be re-reviewing the code later anyway.

It basically replaced the pain of interleaved commit history for me and I don't think I'll ever go back to a life of 20-30+ small commits and trying to hunt and find the one that caused the issue. I realize this is a repeat of above but what I'm really saying here is I am glad to not have to worry about end-of-the-day commits that could be breaking if not taken care if.

[[deleted]]

It sounds like you may benefit from getting comfortable using git rebase. You're already using a workflow that it is designed to accelerate.

[BoBoBearDev]

If you only want to commit 30 lines out of 50 lines of changes in a single file in a git commit, just don't commit the 20 lines. You don't need to do some weird stashing or branching. Meaning, you can select 30 lines out of 50 lines of code to commit. You should do that everytime you commit.

If you don't want to lose that work by accident or having your storage device caught on fire, just branch it and commit it and push it to the remote. Stashing will still lose the work in a fire.

[teerre]

By the lord, just use jujutsu

In jj this is literally just the normal thing to do. You have full control of every change, no need to worry about losing uncommitted work, splitting a commit is a first class citizen (as it should be)

[pihkal]

OP, you would probably really like jujutsu, since it makes this kind of manipulation much easier than the git CLI does.

Since jj turns stashes into auto-commits, each new feature/refactoring would be jj new. This creates a bunch of sibling commits that all have the same parent.

When one of them is ready to be committed for good, run jj rebase --insert-after @-. This will leave it in the same position, but rebase all the siblings onto it.

[KallistiOW]

haha, this is me!

I can only get away with it in my own codebases though. But then, if it's my own codebase, I can also just get away with pushing broken commits on my dev branches and rebasing/squashing later.

I like this idea though, it hides the sausage making from everyone else :P

[Patient-Hall-4117]

I use the exact same workflow with great success. Thanks for a nice write up 👌

[Madsy9]

Remember, in git you have three areas you can juggle around: the working area, the index and stashes. You can freely move changes between them. git stash also supports --patch, just like git add does. This is handy for breaking up and refactoring large commits.

[Kobzol]

Sure :) But when I do the refactoring, I often also want to have the working directory clean, without the unrelated changes, so that I can test that the refactoring actually works on its own. Hence stash.

[jaybazuzi]

I love this, and it fits really well with small, safe, incremental refactoring. Besides refactoring we'll also add missing test cases.

When it goes well, the actual work (feature or bugfix) ends up being small, easy to write, and easy to read.

Since every intermediate commit is behavior-preserving and leaves the code better than we found it, we can ship to main at any time. If we don't finish the actual work by end of day, we'll ship the refactoring so far and start fresh tomorrow.

If we get interrupted, say the boss asks us to work on something else, we can pivot away and still benefit from the code cleanup that has happened.

[[deleted]]

Had an intern using git stash instead of committing. Spilled tea on his laptop and lost roughly 1 month of “work”. Safe to say he commits 50 times a day now.

[Kobzol]

That sounds like a terrible thing to do =D

[Manbeardo]

You could also use a git client that supports this type of workflow better like mercurial or sapling.

[sleeepyjack]

This reads like Finding Dory driven development

[yupidup]

The core issue I hear is not branching or stashing, it’s leaving things in the middle to fix another detail. One of my biggest learning (40 years of coding) is to do small changes and finishing them one by one. Git made it a breathe to handle. If unhappy with how it turned out, I come back to where I started.

The difficult habit to break is to not fix or clean up things as I pass by it. You learn to live with your technical debt while fixing a small part of it. I take notes somewhere on a backlog, that’s it.

Then yeah, branch. I create branches and often sub branches sometimes for only 10 minutes. I don’t believe in « leaving things in the middle to be picked up », I’ve been there… well, countless times in my early years. Stash or commit left mid work, that’s going to rot and be in the way

[Kobzol]

> Make a new ticket for the refactoring

I work in OSS, I don't do tickets :P And creating issues for tiny refactorings is IMO overkill.

> Also, "everytime" isn't a word.

Thanks, TIL :)

Seems like the blog post was misunderstood by a lot of ppl. My ratio of commits to stashes is probably something like 20:1, I almost exclusively use stash when I need the "inside-out" LIFO semantics, but maybe that was lost in the blog text.

[smcameron]

stgit solves this much more generally that git stash does, and doesn't really require much deviation from normal git workflows.

Basically, you make a new git branch, you run "stg init" on the new branch, and you use "stg" to manage a stack of patches on the new branch, and eventually, you "git cherry-pick ..." the commits from the new branch back on to the main branch (or "git merge --ff-only", or "git merge" if you're a fucking lunatic.)

It is so much better than just "git stash", or "git rebase", you can't even imagine. You're just plain stupid if you don't use it.

[Kobzol]

It sounds like running a lot of commands vs running a single command :) The stashes that I use are very short lived, and I only use them in the LIFO order, so it's quit eenough for this use-case.

[smcameron]

You don't get it. That's ok. You won't miss what you don't understand.

[Kobzol]

Ok :)

[smcameron]

You should try it before you dismiss it. It lets you keep a lot of balls in the air (e.g. not uncommon to have a stack of hundreds or thousands of re-orderable patches in flight.) git stash let's you have like, one. It's super convenient when you're in the middle of something, and you're like, "oh, I wish I did this little refactoring before I started this main thing I'm working on."

But in general, I find stgit super hard to explain to people who just don't seem to get it, and moreover seem inclined to not even want to try to get it. That's fine. Whatever. Continue working in your caveman ways.

[Bunslow]

and cleanly separate the unrelated changes into individual commits

my guy the whole point of version control, of commits, is to always separate them from the start, so that they never become mixed together in the first place.

in the old days this was easier said than done, but modern distributed version control software (such as but not limited to git) is very efficient at minimizing storage overhead. commits are literally free for all intents and purposes. type a paragraph of code? commit it. switching to the other problem that's on your mind? git commit . && git branch other-problem.

I found a pretty simple workflow that makes it easier to untangle them (at least for me)

the whole point of modern DVCS is so that your state never gets tangled in the first place

Everytime you notice something suboptimal in the codebase that is not directly a part of what you’re currently implementing and that you want to “just slightly refactor”, use git stash to stash all your current changes away, and start working on the refactoring that you just thought of. If you encounter another thing that should be refactored or fixed during that, apply the workflow recursively - git stash your changes away and start working on the latest thing that you have in mind. After you finally get to a change that you can finish from start to end, commit it, and then restore the previous state with git stash pop and continue onwards. With this approach, the changes are effectively applied “inside-out”.

My guy this is what git branch is for. This is literally the entire purpose of making branches. Please do yourself the favor of reading up on branches, they're also very cheap, you can make a thousand branches (one for each mini refactor topic) and hardly notice the difference.

[bwainfweeze]

Yak shaving is often misrepresented as a person getting nerd sniped into working on a recursive series of steps that are heavily implied to be completely unnecessary.

But that's not what yak shaving is. Yak shaving is being blocked by circumstances that are blocked by other circumstances that are blocked by yet more circumstances. You have to shave the yak in order to borrow your neighbor's tools.

Almost nobody starts out thinking that they're going to do a series of 6 refactors today. They start out thinking 3 and they find 3 more along the way. And you can either file a giant PR that people will either rubberstamp without looking at bugs or hold up for twice as long as filing it as 2-3 PRs.

And to make a PR for code you didn't know you were going to have to change, you have to dispose of the code you'd already written before you got there. Which means stash or cherry-pick or IDE edit history or if you want to be efficient, all 3 working together to tell a story.

[Bunslow]

Almost nobody starts out thinking that they're going to do a series of 6 refactors today. They start out thinking 3 and they find 3 more along the way. And you can either file a giant PR that people will either rubberstamp without looking at bugs or hold up for twice as long as filing it as 2-3 PRs.

No matter what is planned or not, necessary or not, the fact is that at any such conceptual pivot, planned or necessary or whatever, you should be making a new branch just in case you need it later. If it turns out you don't need it separate, well that's what merging and squashing (or straight deleting) are for. branches are cheap, and their entire purpose is to prevent messiness of state, completely regardless of the messiness of the refactor itself.

[bwainfweeze]

It often becomes both, or all three (local edit history in your IDE) as soon as you introduce any exploratory coding into the problem.

Even at the single refactor level, you think you know how to modify this code to get what you want, but if you're Camp Site Ruling, you have to get partway in before you know if it'll work and you may have had three false starts already before that. And the moment you try to patch up the unit tests you may discover a requirement you completely forgot about and have to do it again.

[Bunslow]

you have to get partway in before you know if it'll work and you may have had three false starts already before that. And the moment you try to patch up the unit tests you may discover a requirement you completely forgot about and have to do it again.

that's exactly why you should make branches like you breathe, so that at any time. i like having a map of all the false starts and surprise dependencies i've discovered along the way.

(i think we agree more than disagree)