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

61–70 of 144 posts

Re: Hitting every branch on the way down

#61

Post by planede »

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…

Merges of course should have changes, but IMO they shouldn't have changes that are not resolving conflicts (either actual conflicts marked by git, or conflicts that manifest in failing tests, etc...). An entirely unrelated change stuffed into a merge commit is inappropriate.

Re: Hitting every branch on the way down

#62

Post by lmm »

iainmerrick wrote: post #52
lmm wrote: post #32

Earlier quoted context omitted.

Right but that doesn't help if you've done your own work on top of their changes.

I think rebase is generally the correct approach here. If you've done your own work on top of their old changes, rebase your work on top of their new changes.

That's possible but it requires a bunch of manual tracking and results in wasted/duplicate effort with people resolving the same conflicts multiple times.

Re: Hitting every branch on the way down

#63

Post by ansible »

btilly wrote: post #11
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!

One idiot with rebase destroys history with no trace. I worked with such an idiot in a parallel team. I can't say how many weeks of work randomly got destroyed by said idiot. I hate rebase on shared code I don't care how clean jt looks. Don't mess with history.

Didn't you guys have filesystem backups of a shared git repository?

This is exactly what backups are for.

Re: Hitting every branch on the way down

#64

Post by lloydatkinson »

microtherion wrote: post #40

Rather than the sed post-processing, the author could also have used -iquote for the place where protobuf is installed, which makes it findable by quoted includes.

Is this a common solution or documented in obvious places?

It wasn’t until I just read her article that I’d even considered some systems/distros doing weird things like rewriting C include syntax for questionable reasons.

What a terrible thing to deal with, simply frustrating.

Re: Hitting every branch on the way down

#65

Post by arghwhat »

robin_reala wrote: post #56
arghwhat wrote: post #25

Earlier quoted context omitted.

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.

Technically you can have multiple first-commits in a Git repository. For example, Linux had 4 initial commits in 2017: https://www.destroyallsoftware.com/blog/2017/the-biggest-and...

Indeed, through commits with multiple parents (merges), you can end up having multiple orphan commits (initial commits).

Multiple initial commits are a bit rarer, usually stemming from merging in entirely different git repos with their own separate history as part of consolidation.

Re: Hitting every branch on the way down

#66

Post by thriftwy »

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…

That's why reasonable projects limit their usage to the smallest reasonable scope, and use rebase/squash. You don't have to adopt a hard problem.

It actually escapes me why Linus decided to make git a merge-first VCS in the first place. There aren't many projects which are more linear in nature than Linux kernel.

Re: Hitting every branch on the way down

#67

Post by noirscape »

Groxx wrote: post #3
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!

Yep. Stuff like this is part of why I'm a rebaser. Rebase is simple . Always . The end result is obvious and clear and can only be interpreted in one way. Merge has lots of little sharp edges and surprises if you don't know every single tiniest detail. Almost nobody knows it in that level of detail, so it's a terrible choice for interacting with anyone else. If you're on your own, sure, do whatever - many things are…

My personal preference is merge but using the --no-ff flag. That way you get all the advantages of a rebase (since all your original commits are rebased into the target branch) but you also get a merge commit to confirm that all those changes were a part of the same set of patches.

That can often help a lot to figure out why something ended up the way it did, but you also don't turn your entire history into a flat pile of disparate commits.

Re: Hitting every branch on the way down

#68

Post by roodrax »

skywal_l wrote: post #39
zilti wrote: post #37

Earlier quoted context omitted.

"But it is littering the commit history with useless commits!" is what I always hear

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

Re: Hitting every branch on the way down

#69

Post by PhilipRoman »

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.

Git log (and many other tools as well) pretend that merge commits do not introduce changes. I learned about it in the hard way when someone managed to implement an entirely new feature, contained within a hidden merge commit.

It's only partially the fault of Git - the entire idea of a merge requires new concepts like 3-way diff, which are not needed for rebased commits. I'm not even sure that most software like GitHub can display such a diff.

Re: Hitting every branch on the way down

#70

Post by throwawayffffas »

> 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 whatever you want in the merge, and it won't appear in any other commit.

Post reply on HN