61–70 of 115 posts
Earlier quoted context omitted.
> 4. use `git add -p` I strongly recommend tig
what's the advantage over partial?
I wrote a similar suggestion in 2011: https://sandofsky.com/workflow/git-workflow/ As far as I could tell, this was the recommended workflow from the earliest users of git. Look at the Linux kernel's public history. When git gained widespread adoption, it was sold as "Subversion, but with cheap branching." People don't realize that this power requires discipline, otherwise you end up with complicated history that mak…
> Treat yourself as a writer and approach each commit as a chapter in a book. Writers don't publish first drafts. Michael Crichton said, "Great books aren't written-- they're rewritten."
This is a more succinct and poignant way of describing my workflow, and why "just put a PR up with all your WIP commits" is so difficult for me. I don't want people to see how long I spent getting this one unit test to pass when the answer was staring me in the face the whole time. I don't people to see just how badly I wrote the first draft of my code, when my approach was basically "make it work e2e first, no matter how bad of a hack it is, then actually figure out how the code should be laid out later."
Folks say "your PR can just be squashed when merging anyway", but it misses the point: My private commit history is very, very, intensely personal to me, and I don't want anybody seeing it, ever.
What a waste of time and effort. Squash when merging to master and be done with it. Every PR/commit merged to master should be a clean logical unit. That means not fixing a bug in a branch where I'm doing something else. Those will be two separate PR's. The second problem shouldn't exist IMO.
I think you underestimate just how much stupid garbage I have in my commit history. It's embarrassing. Even if you squash when merging the PR, the squashed commit message is gonna have a ton of messages that look like "Why the hell isn't this compiling?", "wtf?", "FINALLY PASSES!" etc etc etc. I could avoid creating those commits in the first place, but asking me to only commit my local changes when I have something…
Nothing forces you to keep the messy commit messages either - keep the short commit message and make sure it's good, then delete the combined individual commit messages from the long message field, done.
The reset part seem superfluous, most of this can be handled via rebasing. In fact, this is exactly what we do at . Much like the thesis of this article, the goal is to have a set of well organized commits so that when it comes time to do a PR review, you have 1-3 logical units of change and it also improves the ability to do reverts. But you can very easily do this just by rebasing instead of resetting and re-commit…
Fix-ups are nice. I developed a script that takes the all staged content and breaks them up into separate fix-ups that fixup the last commit that changed those lines. I find it pretty handy
Why commit at all if you're going to reset? Sounds like the intermediate commits are just used as a backup method. The real trickery is mentioned in the last part, if commits don't break up tidily along file boundaries you'll have to commit hunks somehow and then go back and test whether the code works. Either way, in the end it's up to developer discipline to make clean commits, git doesn't really help all that much…
Because committing is useful? It saves my work. I can get to a point where my code finally compiles, make a quick commit, then do some more dangerous refactoring. If something breaks, I can `git diff` to see what changes I've made since it last compiled.
I'll turn this around and ask you: Why do you feel like you can only make a commit if you have something that's reviewable? Is your code writing style so perfect that it all works the first time? Or do you just not bother committing anything until your work is done? (That personally sounds terrifying to me... I really need to be able to say "what have I changed since 10 minutes ago when this compiled?" on a very regular basis.)
Earlier quoted context omitted.
I think you underestimate just how much stupid garbage I have in my commit history. It's embarrassing. Even if you squash when merging the PR, the squashed commit message is gonna have a ton of messages that look like "Why the hell isn't this compiling?", "wtf?", "FINALLY PASSES!" etc etc etc. I could avoid creating those commits in the first place, but asking me to only commit my local changes when I have something…
It's true that messy commits happen, that's why squash is there. Nothing forces you to keep the messy commit messages either - keep the short commit message and make sure it's good, then delete the combined individual commit messages from the long message field, done.
Why commit at all if you're going to reset? Sounds like the intermediate commits are just used as a backup method. The real trickery is mentioned in the last part, if commits don't break up tidily along file boundaries you'll have to commit hunks somehow and then go back and test whether the code works. Either way, in the end it's up to developer discipline to make clean commits, git doesn't really help all that much…
> Why commit at all if you're going to reset? Because committing is useful? It saves my work. I can get to a point where my code finally compiles, make a quick commit, then do some more dangerous refactoring. If something breaks, I can `git diff` to see what changes I've made since it last compiled. I'll turn this around and ask you: Why do you feel like you can only make a commit if you have something that's reviewa…
Earlier quoted context omitted.
The problem comes when you have a related set of changes where you both want to see how everything eventually fits together and where you still want to keep small "clean logical units." You can see this kind of thing play out frequently in, for example, Linux changesets, where you might have a 24-patch series of changes that need to go in for a feature.
There's no such thing as "clean logical units". There's a product you work on. There are bugs. The prodct needs some features, good UX, performance requirements. Spending effort on managing git is mental effort you don't spend on solving your actual problems. By far the best experience I've ever hadeith git was: everyone works straight on the dev branch, just rebase, fix your stuff, test often, and if you're doing so…
The advice I try to live by, is that however messy my work was leading up to a PR, I make sure the end result is something somebody can review without additional context. Commits should have lengthy descriptions of changes that describe the "why" and "how" of a particular change, in a way that makes it easy to digest for a reviewer. Sometimes multiple commits make sense (like if you're renaming a module/class, put that in a single commit, then put the actual code change in the next one), sometimes they're not necessary. But it's worth it to put in the effort here if it means it helps a reviewer, IMO.
What a waste of time and effort. Squash when merging to master and be done with it. Every PR/commit merged to master should be a clean logical unit. That means not fixing a bug in a branch where I'm doing something else. Those will be two separate PR's. The second problem shouldn't exist IMO.
I think you underestimate just how much stupid garbage I have in my commit history. It's embarrassing. Even if you squash when merging the PR, the squashed commit message is gonna have a ton of messages that look like "Why the hell isn't this compiling?", "wtf?", "FINALLY PASSES!" etc etc etc. I could avoid creating those commits in the first place, but asking me to only commit my local changes when I have something…
If someone else is doing the merge and you’re unsure if they will you can preemptively squash your whole branch so there’s only one commit in the pr.
Earlier quoted context omitted.
I think you underestimate just how much stupid garbage I have in my commit history. It's embarrassing. Even if you squash when merging the PR, the squashed commit message is gonna have a ton of messages that look like "Why the hell isn't this compiling?", "wtf?", "FINALLY PASSES!" etc etc etc. I could avoid creating those commits in the first place, but asking me to only commit my local changes when I have something…
You can remove those messages from the final commit when you squash. If someone else is doing the merge and you’re unsure if they will you can preemptively squash your whole branch so there’s only one commit in the pr.
I agree! And that's what I do. But OP said that would be "a waste of time and effort", hence my reply.