You forgot read-only filesystems
Ah yes, the vegetables and sports git merging strategies. I personally prefer rebase myself, but that’s okay.
Would that be stealing in baseball??
Can you get squash (juice concentrate) in the US? I took a shine to it in the UK, but all I can think that we have here is the frozen concentrate and maybe like some lemonade concentrate in a carton.
As long as it merges it’s fiiiine!
Nobody’s gonna notice
You might prefer working with rebases + fast-forward-only merges, if you want merge commits to be squashed…
(As in, there won’t be any merge commits. Your PR will look as if you forked, then coded real fast, and then opened the PR before anyone else pushed anything.)
I never thought about it and instantly wanted to reply “wait why can’t you do that‽” but now that I thought about it, what would you want the history to look like in that case? A slightly weird rebase? A single commit which seemingly copy pasted the entire other branch with no relation to it left behind?
I think it doesn’t really make sense. Because you can’t “squash” one commit. squash is taking multiple commits and making them one.
When you do a “squash merge” you are really saying “squash all the commits that are on this branch and not the target” then merge.
So you can’t “squash a merge commit” you need at least one additional commit to squash in.
I don’t work with merges, so maybe I’m way off base, but I thought they meant, they’re working on another branch or fork, then merging the base branch into theirs every so often to get the newest changes, and then that creates multiple merge commits, which they can’t squash at the end…?
I’m not sure, about that last part, but the rest, I’ve definitely seen with contributors that didn’t know to work with rebases (and unfortunately we’re on GitHub, which only half-assedly supports working with rebases by default).
Sometimes you really don’t want to look over the commit history of your colleagues. As long as it’s a small feature, a single commit is a pretty good option.
Rather than:
- implemented X
- forgot this
- oh, this was not needed
- now tests actually pass
- oops
- fixed this
- should be ready
It’s fine if the changes belong in a single commit. Otherwise, an interactive rebase to craft a clean, quality history before merging is much, much better.
That’s basically my commit history for every repo where I need the pipeline to run to see if everything works.
When I do that I always have a Dev branch that I use as the production branch to run the actual calculations.
When I get something working I merge it off, clean up the history a little bit, rebase main onto it and then rebase de onto main.
Yeah, I’m with you. I mean, git isn’t magic. You “can” squash anything, including a merge commit, by just being at the end result, running
git reset <commit you want to be squashed off of>and then running a manual git add and commit there. That’s basically all a squash is.But what you’ll be left with us a single commit that contains all of the code from the branch you’re squashing and also all the code pulled in from every branch you merged, all written as though it all came from this one commit. And maybe that’s what you want? But it feels like also maybe it’s not?
I’m not a fan of changing history in general. Rebase can also he dangerous.
I think ultimately it’s a matter of scale. Sometimes it can be useful to look into the details of the development of a single feature, but in a large project, that rarely happens. I’m not a fan of squashing, but for large projects, it helps to keep your history manageable.
Rebasing is not dangerous. You can always go back if something is not to your liking.
You don’t rebase shared history, you use rebases to craft a clean, quality commit history for your own branches before merging. If everyone does this, then squashing is unnecessary, because garbage commits don’t exist. It is the far superior way of doing things if you actually care about having good commits.
Keeping a quality history rather than squashing also makes many other git tools much better, such as
git blame,git revert,git bisect, and so on.That doesn’t make sense. There’s a world between “garbage commit” and “fancy new feature” and most of it is irrelevant to anything.
I don’t want git bisect to make me check if “run clang-format” broke anything. I don’t want to revert a feature but leave in unit tests that will fail (or worse, the opposite). I don’t care when git blame tells me “rename X to Y”, I want to see the context that motivated this change.
Squashed commits are atomic, built and tested. Anything in between is whatever reviewers let slip in. It’s easier to check a MR description is well written than 5 commit messages (that might get rebased without you noticing)
You’re right that there is a risk, that rebasing introduces compile errors or even subtle breakages. The thing is, version control works best, if you keep the number of different versions to a minimum. That means merging back as soon as possible. And rebases simultaneously help with that, but also definitely work best when doing that.
There may be reasons why you cannot merge back quickly, typically organizational reasons why your devs can’t establish close-knit communication to avoid conflicts that way, or just not enough automation in testing. In that case, merges may be the right choice.
But I will always encourage folks to merge back as soon as possible, and if you can bring down the lifetime of feature branches (or ideally eliminate them entirely), then rebases are unlikely to introduces unintended changes and speed you up quite a bit.
Rebasing is dangerous if you rebase shared history. If you rebase a local branch, you have to be aware of how much of that local branch you may already have shared.
On top of that, if you’ve got a lot of commits you’re rebasing in a merge conflict that can become extremely repetitive.
So ideally, you only rebase single commits that you haven’t pushed yet. As long as you do that: always pull main and rebase on top of that before you push single commits, rebasing is fine. But the more you deviate from that, the riskier it becomes.
You don’t share feature branches. So you always know precisely what is shared history: the commit you branched from.
The workflow is branch from shared history, rebase your branch as many times as necessary during development to craft a quality history, then merge back.
I rebase dozens of times a day and have never had a single issue with it.
If you’re bothered by repetitive merge conflicts (which, in my experience, are quite rare if you’re doing things correctly), that’s what git rerere is for.
Rebasing is for crafting a quality history of your own commits (or getting your branch up to date with the trunk). Merging is for integrating your commits with the shared history.
I often end up squashing all my changes into a single commit, rebase it, and then reset HEAD^ to rewrite some commit history.
Brute force, but better than resolving 10 conflicts in the same file over and over
But all intersections are squash.
I think the other intersections should exclude the non-overlapping circle.
+Veggie +Git -Sport: Prune
+Veggie -Git +Sport: Pickle
-Veggie +Git +Sport: I dunno… Does fetch count?
Pickleball?
And I guess there’s cherry-pick, but that’s considered a fruit.
I dunno, I love eating a nice fresh-grown water polo
If you were gonna replace something you should’ve replaced “vegetables” because squash is a fruit.
The term “vegetable” is a culinary term, and squash is prepared like a vegetable. For another example, tomatoes are fruits but are prepared like vegetables. Squash and tomatoes can be both fruits AND vegetables. This is my position on the “is X a fruit or vegetable?” issue.
I mean, the idea of a “vegetable” isn’t a well defined group of plant parts like fruits are. Vegetables are a mix of seeds, roots, leaves, stems, etc. all of which are quite different. It’s just “parts of a plant that can be cooked as part of a meal”:
“a usually herbaceous plant (such as the cabbage, bean, or potato) grown for an edible part that is usually eaten as part of a meal also : such an edible part” according to the Merriam-Webster dictionary https://www.merriam-webster.com/dictionary/vegetable (similar definitions exist for other dictionaries, some highlight that vegetables are usually used to make non-sweet dishes)
The TLDR is that vegetables are loosely defined as “plant parts that are used to prepare meals, usually non-sweet dishes” and is a culinary term rather than a botanical one like fruits can be. So an item (like tomatoes or squash) can be both a vegetable and a fruit, the former culinary and the latter botanically. They aren’t mutually exclusive.
Depends on which classification system you use. Botaically it is a fruit. But culinarily it is a vegetable.
Replicating git history for a file takes 1 merge commit and 3 commits, and this is propably one of the most complex workflows I have encountered:
(might not be correct...) git checkout -b work git mv file file.tmp git commit git checkout -b copy HEAD^ git mv file file2 git commit git checkout work # can be skipped if you merge "work" instead. git merge copy # "work" and "copy" must conflict, stage file.tmp and file2 and commit the result. git mv file.tmp file git commit <git blame is identical for file and file2>I would love to squash this into a single commit, but git doesn’t have a copy operation or detection. :(
You seem to be making this very complex. But it really isn’t. Yes, git doesn’t track renames. So you are working around it by splitting your operation into 2 commits.
- A pure rename.
- A file change.
This way 1 is always considered a rename and 2 is just a regular file change with the same path. You may also consider tweaking the default rename detection threshold with flags like
--find-renamesor options likediff.renameLimit.Would it be nice if Git tracked renames? Probably. But that isn’t how the data model works so it is unlikely to happen soon. But maybe they could add some metadata.
Huh. I have never in my 19 year career using git, ever wanted to copy a file and pretend all of the history of that file is also the history of the new file. I mean, I don’t think I’ve ever even wanted to copy a file? Why are you copying a file?
Like, maybe I’m just too familiar with git to see the forest for the trees, but what the heck are you doing over there? 😅
And just in case it’s useful, a tip is that you can use
git blame -Cto have the blame algorithm use a heuristic to try and find a “source” line if it was moved, including from another file, during a commit, and then continue following the history of that line, to try and get the real commit where this was written, not just the last time it was moved around.Why are you copying a file?
I’m splitting a several thousand LOC file, which I don’t have previous history in.
Like, maybe I’m just too familiar with git to see the forest for the trees, but what the heck are you doing over there?
Normally copying a file and committing transfers the authorship to you, because the copy just appears from nothing as a brand new file, never known to git. This would prevent browsing the per-line “who changed this last” history past the copy and obfuscate who wrote what and when.
(why the downvote?)
Interesting. Yeah, sounds like what
git blame -Cis for, so I’ve never made copies when splitting files, I’ve just moved lines between files naively. But I guess if one’s tools are limited and doesn’t have the ability to-C, then I guess I could respect the hack that is that solution?I mean, I’m 99% sure git doesn’t store blame or authorship info in the pack files, even as a convenience cache, and just guesses by traversing the patch log with heuristics live when you run blame anyway, so the history mostly doesn’t matter there, but the way you’ve done it does seem to have tricked the heuristics into doing what you want without relying on an option, so that’s neat! It’s an interesting hack, and I like interesting hacks 😛
By the way, if there are down votes, they’re not from me!
I’m not a copyright-lawyer, but I think there are implications on who has authored the code, so preserving this detail can be important. The fancy copy reduced my blame by +90% on the final result.
git blame output can be affected by e.g. ignoring white-space changes.
I can come up with some contrived examples. Maybe someone screwed up the history and they’re trying to repair it such that no one needs to worry about a rebase on their next pull? “compliance”/legal/cya reasons? I also wish to know!