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. :(
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.
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’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.
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
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.
Haha same. But that’s why you do it in another branch, and then squash-merge.
I like squash merge on small changes, but when larger code changes are there it becomes a huge commit which is difficult to review if you ever have to go back.
Right… for sure… but then if you don’t want to squash, then it doesn’t matter you can’t squash a merge commit.
But all intersections are squash.
I dunno, I love eating a nice fresh-grown water polo
Pickleball?
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.
