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

51–60 of 144 posts

Re: Hitting every branch on the way down

#51

Post by iainmerrick »

lmm wrote: post #27
saagarjha wrote: post #23

Earlier quoted context omitted.

Yeah so you have them go through the workflow that doesn’t ruin things, like pull requests?

I don't want to have to go back and forth with someone to pull their branch. I want to just be able to pull anything they've pushed.

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.

Re: Hitting every branch on the way down

#52

Post by iainmerrick »

lmm wrote: post #32
NewJazz wrote: post #29

Earlier quoted context omitted.

I'll often just do a git reset --hard origin/branch-name

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.

Re: Hitting every branch on the way down

#53

Post by iainmerrick »

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.

I like to think of that as "actually learning"

Re: Hitting every branch on the way down

#55

Post by wdfx »

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.

Some people however see using features like amend, squash, and force push as potentially destructive actions in the hands of a novice, which can lead to loss of not only the author's work but also other people's. Using merge almost never results in any sort of loss and is easier to work with for those who still don't quite understand the risks.

Re: Hitting every branch on the way down

#56

Post by robin_reala »

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.

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...

Re: Hitting every branch on the way down

#57

Post by pjc50 »

wdfx wrote: post #55
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.

Some people however see using features like amend, squash, and force push as potentially destructive actions in the hands of a novice, which can lead to loss of not only the author's work but also other people's. Using merge almost never results in any sort of loss and is easier to work with for those who still don't quite understand the risks.

"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.

Re: Hitting every branch on the way down

#59

Post by lmm »

cnity wrote: post #54
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.

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.

Re: Hitting every branch on the way down

#60

Post by lmm »

iainmerrick wrote: post #51
lmm wrote: post #27

Earlier quoted context omitted.

I don't want to have to go back and forth with someone to pull their branch. I want to just be able to pull anything they've pushed.

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.

> Isn't "protect your main branch" still the answer to this?

No, the feature branches need to be protected or something, to enforce that they only rebase locally and don't rebase the parts that I've merged into my branch (and vice versa).

> Also, "git cherry-pick" is a good alternative to merging for this use case.

No it isn't, it means you get multiple unrelated commits for the same change, which causes conflicts and can be disastrous if a commit is deliberately reverted.

Post reply on HN