Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hitting every branch on the way down

rachelbythebay.com

Post reply on HN
Print view View original

71–80 of 144 posts

Re: Hitting every branch on the way down

#71

Post by nebulous1 »

zokier wrote: post #42

I don't want to victim blame too much, but this line stood out to me > There's no "body" to this commit. It's just a "Merge:" and two other commits Commits are snapshots of repository state, and merges "obviously" have differences from its parents. So not having "body" for a commit is bit nonsensical in git (yes, technically you can make empty commits but that's a special case). These sort of things are where having…

Merging a branch is one of the "special cases" where an empty merge commit can be used. Git will use fast forward by default but if you want to preserve the history as a separate branch you can use an empty merge commit instead.

Re: Hitting every branch on the way down

#72

Post by tsimionescu »

arghwhat wrote: post #25
datascienced wrote: post #2

I wont claim to understand C and the reason why is better than “”. I assume it is. But the fact that a merge can have arbitrary changes in it always bothers me! This is a case for rebase over merge if there are conflicts. You could have a merge of 2 empty repo parents where the result is the complete source of the latest version of Kubernetes!

All but the first commit has parents. All commits point to the state of the file tree at that point. A "merge commit" is nothing more than a commit claiming any number of parents greater than one. It is still its own file tree reference that decides how the tree looks, and nothing dictates that it should be related to the parents.

If that were true, then git log -p would have worked. The reality is that merge commits are treated differently from other commits by many parts of git. Saying that they are "just a commit with multiple parents" gives people the wrong impression.

Git is more than the data structure backing it. And many parts of git make all sorts of assumptions that treat things that are more or less identical in the data model as actually being different. Tags are not the same thing as branches, for example, even though they are stored in virtually the same way.

Re: Hitting every branch on the way down

#73

Post by shoo »

baud147258 wrote: post #45
thriftwy wrote: post #36

Earlier quoted context omitted.

And that's one of the reasons why I advocate against merges in the codebase on every project I work for and in every HN thread where the topic of merges is mentioned.

That might reveal the depths of my ignorance of Git, but how do you manage moving changes from one branch to the other if you don't use merge? Edit: continuing to read the discussion, it seems it's rebase? I have some reading to do

rebase is git's swiss army chainsaw.

i use rebase frequently, but i never remember which direction the operation goes in. do you need to checkout the source branch or target branch? truly, it is unknowable. my workflow is to type `man git rebase` and hit space to page through the manual until the first ascii tree surgery diagram appears. then i stare at it until i remember that i need to have checked out my feature branch and am meant to type `git rebase main`. i have trained myself to read the man page every time, perform the operation correctly, then immediately forget.

https://git-scm.com/docs/git-rebase

Re: Hitting every branch on the way down

#74

Post by nebulous1 »

rob74 wrote: post #43

So, someone at some point in some commit that we will never see because it got squashed with other commits thought it would be cooler to use absl::StrCat() instead of the "+" operator, and in the process of doing that, they went "what's this useless code using angled brackets instead of quotes?! It works with quotes too, let's delete it!". Or maybe that part was difficult to test, so they simply deleted it to increas…

Am I misunderstand or is this not on whoever abused the merge commit, whether they made the change personally or not.

Re: Hitting every branch on the way down

#75

Post by tsimionescu »

paulddraper wrote: post #10
ptsneves wrote: post #8

Earlier quoted context omitted.

Yes, except git log will show all the commits that got into the branch, while with merge you need git log -m otherwise there are invisible commits(and diffs) in a pretty common workflow. I don’t know why this is the default behaviour. Git log only shows one tree not parallel trees from the merge.

? Not sure what you mean. git log will show all ancestors. And git diff shows any difference between two refs. Nothing invisible unless you deliberately make it so.

The blog post explains it pretty clearly: git log -p doesn't show the diff for those merge commits like it does for a normal commit.

Re: Hitting every branch on the way down

#76

Post by cnity »

lmm wrote: post #59
cnity wrote: post #54

Earlier quoted context omitted.

Just use: > git pull --rebase

Right but assuming I have a branch that's diverged from theirs I have to do a fiddly git rebase --onto and likely resolve the same conflicts again.

This to me is a sign that some commits should be squashed, because it implies the same lines have changed multiple times in the commits that are ahead of the remote branch. It's worth doing the rebase interactively and squashing them up.

Re: Hitting every branch on the way down

#77

Post by throwawayffffas »

throwawayffffas wrote: post #70

> 7764c864b and 0264866ce, right? I should be able to sync to those with git checkout and see which one dropped it, yeah? Well, I'll spare you the effort and just say that BOTH OF THEM have the old code in it. When you make a merge commit, the merge commit contains all the changes. It's what happens when you fix a merge conflict. The fix for the conflict only exists in the merge commit. Similarly you can just add wha…

> That actually installed "protobuf-24.4,1" which is some insane version number I'd never seen before. All of my other systems are all running 3.x.x type versions.

They obviously changed their version numbering convention at some point, and this is protobuf 2.4.something.

Honestly, I see the shit she tripped on all the time. It doesn't even register anymore.

Re: Hitting every branch on the way down

#78

Post by thriftwy »

shoo wrote: post #73
baud147258 wrote: post #45

Earlier quoted context omitted.

That might reveal the depths of my ignorance of Git, but how do you manage moving changes from one branch to the other if you don't use merge? Edit: continuing to read the discussion, it seems it's rebase? I have some reading to do

rebase is git's swiss army chainsaw. i use rebase frequently, but i never remember which direction the operation goes in. do you need to checkout the source branch or target branch? truly, it is unknowable. my workflow is to type `man git rebase` and hit space to page through the manual until the first ascii tree surgery diagram appears. then i stare at it until i remember that i need to have checked out my feature b…

That's why I always use git cherry-pick for specific commits that I want.

It's essentially a "cp thing-i-want ."

Combined with git reflog your repo becomes as understandable as a floppy disk.

Re: Hitting every branch on the way down

#79

Post by xorcist »

rob74 wrote: post #43

So, someone at some point in some commit that we will never see because it got squashed with other commits thought it would be cooler to use absl::StrCat() instead of the "+" operator, and in the process of doing that, they went "what's this useless code using angled brackets instead of quotes?! It works with quotes too, let's delete it!". Or maybe that part was difficult to test, so they simply deleted it to increas…

Why do you think it was squashed? This article is clear about this being a merge commit. This person got a merge conflict and decided that this was the best way to fix it. It probably worked on their machine. Perhaps not necessarily the optimal fix when you have thousands of users depending on this code, but what do I know?

Re: Hitting every branch on the way down

#80

Post by xorcist »

roodrax wrote: post #68
skywal_l wrote: post #39

Earlier quoted context omitted.

And the best answer is: "Why do you do useless commits?". With `git amend` and `git fixup` you can arrange your commits to be clean, properly documented and self explanatory (and maybe atomic but that's a little harder). It takes a little time but it is hugely beneficial to code reviews and bug investigation.

totally agree here. commits are not for saving "your-current-work". Its about marking a definite step of change in the realm of the project itself. making commits atomic is harder because we tend to just write code, without first breaking up the requirement into atomic pieces

Commits are for saving your current work. Commit early, commit often. Just clean them up when you're done!

Don't push half-baked work on other people! You waste their compute cycles needlessly, from now until the end of time.

Post reply on HN