It makes sense sometime, but not always. Group commits by files. For example, Most of one core change is in multiple files, it will be very bad to commit by files group
I disagree. It's not difficult to stage single lines using the right tool.
A Better Git Flow
41–50 of 115 posts
Re: A Better Git Flow
#42> do the work first, clean up the commits later I'm not sure this gives the right impression. Yes rename/squash/interactive rebase if necessary to tidy, however I still believe you should strive to create clear, separate commits as you go. If you have to regularly make major changes to history before review, I could be a sign that your process/approach is disorganised.
> If you have to regularly make major changes to history before review, I could be a sign that your process/approach is disorganised.
Right. Next time think before do.
Re: A Better Git Flow
#43What 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.
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.
Re: A Better Git Flow
#44> do the work first, clean up the commits later I'm not sure this gives the right impression. Yes rename/squash/interactive rebase if necessary to tidy, however I still believe you should strive to create clear, separate commits as you go. If you have to regularly make major changes to history before review, I could be a sign that your process/approach is disorganised.
> If you have to regularly make major changes to history before review, I could be a sign that your process/approach is disorganised.
Of course my process is disorganized! I'm an extremely disorganized person. I like to try out wild tangents in my coding, experimenting with some crazy idea or another and saving my place before and after I do so. I even have a separate .txt file of stream-of-consciousness writing about my coding, to keep track of the tremendous amount of complexity I have to deal with on a regular basis.
My reflog reads like a personal diary of failings, dead-ends, "FINALLY COMPILES!" commits, etc etc. I use `git branch someNewBranch` really often, keeping a namespace of local branches under the name `deadend/*` to mark tombstones of approaches I tried in code but didn't work out, and I `reset --hard` back to a previous commit after I save the branch. I like it this way, it maps better to my totally disorganized brain.
But I'm also a firm believer that none of my colleagues should be able to tell how disorganized all of this is, because by the time I make a PR, I squash it all down and write a very long, detailed commit message of what exactly I did, why I'm doing it, and how it works (sometimes, albeit rarely, spread across multiple logical commits in one PR.) They never get to see my private commit history.
Why does it matter to anyone how much I have to prune my commit history before a PR? That's like complaining to another student in class that their short-form handwriting is hard to read, in their own personal notes they're taking during class, when said student is acing all the tests. It's simply not the metric you should be judging people on.
Re: A Better Git Flow
#45The 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…
Rebase is great, but it's usefulness really depends on the commit history. If your branch consists of 10 commits of trying various things, then the sum of changes in all the commits can easily become significantly larger than the final branch diff. In that case resetting is orders of magnitudes faster than fiddling with rebase.
> If your branch consists of 10 commits of trying various things
Use fixup commits.
Re: A Better Git Flow
#46The 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…
Rebase is great, but it's usefulness really depends on the commit history. If your branch consists of 10 commits of trying various things, then the sum of changes in all the commits can easily become significantly larger than the final branch diff. In that case resetting is orders of magnitudes faster than fiddling with rebase.
That's the point of squashing commits - Many of your changes will ultimately pare down into just a few logical thoughts, adding function X to feature A, then using that in function Y in feature B etc... It's not something that comes for free, of course, but if you make many small commits and try to get each file to compile each time you can often basically just squash by file or directory.
Re: A Better Git Flow
#47My two cents: I just always squash commits when merging to master/main. That way the main branch has clean commit messages and it's easy to revert later. I think cherry-picking commits after the fact can also be very time-consuming, especially if you do a lot of refactoring or "clean as you go" as I like to call it. However, I could see it being worth it for open-source.
> easy to revert later Depends on what you want to revert? git revert accepts more than one commit!
You can even revert a merge commit, if you specify the parent.
Re: A Better Git Flow
#48The 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…
Rebase is great, but it's usefulness really depends on the commit history. If your branch consists of 10 commits of trying various things, then the sum of changes in all the commits can easily become significantly larger than the final branch diff. In that case resetting is orders of magnitudes faster than fiddling with rebase.
I would reject a merge from a branch that does more than one thing at a time as you've described during code review. It's okay to have a branch that does a bunch of things at the same time, but come time to merge back to `main` this should be broken up in to several different PR's.
I would probably branch off my branch for each logical change I wanted merged and use `rebase -i` to wholesale drop commits that I didn't want on the branch anymore.
This is also an example of where stacked diffs are far superior to PR's but that's a separate issue.
Re: A Better Git Flow
#49What 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.
This is what we're doing as well. No merged commits to master
Re: A Better Git Flow
#50Earlier quoted context omitted.
1. `git rebase -i` to the commit before the one you want to split 2. mark the commit you want to split as an `edit` 3. remove the file(s) you want to edit from the index so that it's part of your working tree 4. use `git add -p` to stage the hunks you want in the first commit (assuming you want to split commits in a single file) or just commit the files you want in the first commit first, second commit second.
> 4. use `git add -p` I strongly recommend tig
what's the advantage over partial?