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

101–110 of 144 posts

Re: Hitting every branch on the way down

#101

Post by pjc50 »

vundercind wrote: post #99
pjc50 wrote: post #57

Earlier quoted context omitted.

"Force push" is something that should be restricted to a very few senior people anyway; once you do that, you can't rewrite shared history any more and a lot of the worries go away.

This is a great way to get me to clutter the shared repo with throwaway branches that I’ll later replace (deleting the old one—if you let me).

This is fine! This is a normal part of several popular git workflows. After all, a branch is just a pointer to a commit.

(Our workplace has a mix of github flow, which is one branch per PR: https://docs.github.com/en/get-started/using-github/github-f... ; Atlassian Gitflow https://www.atlassian.com/git/tutorials/comparing-workflows/... ; and the completely different Gerrit flow which ends up very rebase and amend heavy: https://gerrit-review.googlesource.com/Documentation/intro-g... )

Re: Hitting every branch on the way down

#102

Post by RHSeeger »

iainmerrick wrote: post #47
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

When people talk about avoiding merges, I think they mean this: https://trunkbaseddevelopment.com The approach described on that site doesn't strictly rule out "git merge", but it emphasises short-lived branches and unidirectional commit flow. If you do things that way you find you just don't really need merges. The next step is to think "merges are rarely useful and sometimes dangerous, so let's just avoid them comp…

> Streaming small commits straight into the trunk

Gotta say, I find that horrifying. What about peer reviews? What about breaking up a change into smaller commits, none of which make sense until they're all together (changing the signature of a method, then changing the places that call that method, etc)?

It's worth noting that is mentions that work on a branch and the use of PRs are acceptable, but... the two statements appear to contradict each other. Why say "only do x" and "do thing that isn't x" on the same page?

Re: Hitting every branch on the way down

#103

Post by pjc50 »

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…

I use "branch.autosetuprebase=local" and/or --set-upstream-to ; then I can just type "git rebase" while on the thing I want rebased and not have to think about it. (Useful in the gerrit workflow which kind of forces you to have stacks of rebased changes)

Re: Hitting every branch on the way down

#104

Post by rob74 »

xorcist wrote: post #79
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?

Ok, maybe I'm misunderstanding the line "There's no explanation or other context. Presumably that all got squashed out when it was exported from whatever they use internally." - I was thinking about git squash, but it could have also been some other step in the process of transferring the code from Google's internal systems to GitHub.

Re: Hitting every branch on the way down

#105

Post by RHSeeger »

plq wrote: post #90
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…

In the chromium repository, the use of angle brackets in #include statements is banned -- they only use double quotes. They also don't use any system headers per se since their flavor of clang comes with their flavor of libcpp vendored in. So if the chromium repo is representative of the state of C++ in rest of Google, they ditched it silently like this probably because it's so natural to them :)

So, instead of using

> means system headers and "" means project headers (my naive understanding of the difference)

they just convert everything to a project header? That seems bonkers to me. It is intentionally removing useful information.

Re: Hitting every branch on the way down

#106

Post by ori_b »

saghm wrote: post #20

> I told it to install "protobuf" since I use that library in my build tool. 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. I was curious about this, so I took a look at the list of protobuf releases[0] and they're...confusing, to say the least. Chronologically, the most recent tags at the time I write t…

I think protobuf might just be a performance art piece, exploring the question of how much complexity it's possible to insert into a simple concept.

Re: Hitting every branch on the way down

#107

Post by ripe »

nvy wrote: post #4
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!

I believe that the semantics of vs "" is actually compiler-dependent but on every compiler that matters, #including with angle brackets is the semantic for "the system header" whereas using quotes gives preference to files in your local source tree. So for example if you #include then the compiler (actually the preprocessor, but whatever) looks in the system's standard location, whereas if you #include "foo" then it…

You are right; a good explanation of the rules is in the C FAQ [1], which points to a newsgroup posting by Kaz Kylehu [2].

I am posting the summary here, although please do read the original if you have time:

The most portable thing to do is to use "" for including files within your project, and to use only for implementation supplied files.

(Disclosure: I was one of the contributors to the C FAQ).

[1] https://c-faq.com/cpp/inclkinds.html

[2] https://c-faq.com/cpp/inclk.kaz.html

Re: Hitting every branch on the way down

#108

Post by BirAdam »

jeffrallen wrote: post #19

This reminds me of a comment my new boss made, "you like learning on hard mode". He meant that instead of following doc to learn, I want to go find out how it works from first principles and then follow the docs, maybe improving them, based on what I saw from "beneath them" looking up.

If more people did this (across many different industries) life would likely be substantially better. However, humans always optimize for the wrong things.

Re: Hitting every branch on the way down

#109

Post by squigz »

pjc50 wrote: post #48

Reminds me of https://github.com/protocolbuffers/protobuf/issues/1491 , which has effectively been WONTFIX (why does github not have this useful distinction?) because Google are happy with how it works and it's really difficult to make this particular thing work with the (also broken) Python module import system.

What distinction? Issues can have custom labels, and there is a default `wontfix` label

Re: Hitting every branch on the way down

#110

Post by danaris »

otherjason wrote: post #94
iainmerrick wrote: post #51

Earlier quoted context omitted.

Isn't "protect your main branch" still the answer to this? Your two feature branches would be unprotected so you can merge away if you like. When one of you wants to commit something to master, that's when you'd check for dodgy merges. Also, "git cherry-pick" is a good alternative to merging for this use case.

Protecting the main branch is definitely a good practice, but the other potential hazard is: - Having a developer on your team that rebases their own feature branch - Then tries to "git push", only for it to be rejected since a force push is required - Then performs a "git push --force", which will force-push all of their local branches, including feature branches from other developers that they may have checked out…

> - Then performs a "git push --force", which will force-push all of their local branches, including feature branches from other developers that they may have checked out previously

This is (part of) why, for most common operations, I use a Git GUI (SourceTree). Force pushing all branches can only be done by very explicitly selecting them all and initiating a force push; the default when pushing is to push only the currently active branch.

It's also overall much clearer and more intuitive to use than the Git CLI. I use it when I have to—there are things that I can't do through SourceTree, and a few things that are complicated enough that I just want to be 100% sure I know exactly what's happening—but for 99% of the Git operations I do, it handles them perfectly and without any worry that I've mistyped something or forgotten to specify a branch.

Post reply on HN