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

81–90 of 144 posts

Re: Hitting every branch on the way down

#81

Post by tsimionescu »

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…

> 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 good mental model of git is useful.

This isn't a problem with the author or her mental model, it is a problem with `git log -p`. The output she is describing is exactly how merge commits show up there, with no other flags.

Re: Hitting every branch on the way down

#82

Post by xorcist »

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.

If you find yourself fixing the same rebase conflicts over and over again, because you for some reason need to work on conflicting changes simultaneously (which is of course best avoided for other reasons), use "git rerere".

Re: Hitting every branch on the way down

#83

Post by nerdponx »

nebulous1 wrote: post #74
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.

It's a shared responsibility.

Re: Hitting every branch on the way down

#84

Post by xorcist »

devjab wrote: post #22
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!

Wouldn’t you have the same amount of merge conflicts with rebase? Especially if you don’t do it often, which you frankly also should with merge? I have to admit that I never really understood the advantages of rebase, and what I mean by this is they I actually don’t understand how the dangers of rebase out-weighs any form of advantages. Especially because on of the major advantages of merge is that you can squash you…

> advantages of merge is that you can squash your local commit history

No, it's the other way around. Squashing is a type of rebase.

Most workflows involve both. Merges can also be fast-forward merges, which are indistinguishable from rebases. Choosing between a rebase and a merge operation is often the wrong question to ask. The question is what state you wish the repository to end up in.

> I’m actually curious if it’s wrong

Look at "git log". It is readable and easy to understand? It is obvious why each commit was made, and why alternative solutions were turned down?

Are you able to use "git bisect" to track down problems?

Then you're doing it right. If not, think about what a functional commit log would look like and how you would get there. Working together is culture, and what type of merges you decide to use is just a tiny part of that culture.

Re: Hitting every branch on the way down

#85

Post by xorcist »

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.

That's just regular "learning". It's just that for some people it's a bit out of fashion.

Re: Hitting every branch on the way down

#87

Post by Applejinx »

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…

It's such a spectacular Chesterton's Fence. Always so frustrating dealing with people who're like "from where I'm standing…" and then they go and make things better, meaning 'more abstract and/or fewer keystrokes'.

Re: Hitting every branch on the way down

#88

Post by quectophoton »

Feathercrown wrote: post #14
btilly wrote: post #11

Earlier quoted context omitted.

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.

I wouldn't consider rebasing your own local commits on top of a more recent remote master to be messing with history in any meaningful way, and that's the most useful method of rebasing.

I can give an example scenario.

Assuming "H" is the hash of the current state of the repository content, consider this initial state of the repository (most recent first):

    H(3) Implement feature B
    H(2) Implement feature A
    H(1) Initial commit
Now you implement "shiny feature", so your history in your branch looks like this:

    H(5) Shiny feature, improvements.
    H(4) Shiny feature, initial implementation.
    H(3) Implement feature B
    H(2) Implement feature A
    H(1) Initial commit
You tested H(4) and H(5), and everything looks good.

Then you `git pull --rebase`, and your history looks like this:

    H(10) Shiny feature, improvements.
    H(9) Shiny feature, initial implementation.
    H(8) Pulled commit C
    H(7) Pulled commit B
    H(6) Pulled commit A
    H(3) Implement feature B
    H(2) Implement feature A
    H(1) Initial commit
You test H(10) because it's the current state of your repo, looks good, and merge (or create PR, whatever).

With the usual pull request flows, `H(9)` (i.e. anything between your new "base" and your most recent commit) usually stays untested, entirely ignored by the developers, and you would only ever find out if you ever need to bisect.

Not usually a problem, unless you have a rule of "every commit should be verified/tested" and the untested commits have a change that doesn't prevent a build but still causes issues (e.g. something that's only visual, or a new config file was added to a "conf.d" directory and its presence changed some behavior, stuff like that).

Re: Hitting every branch on the way down

#89

Post by CoastalCoder »

xorcist wrote: post #80
roodrax wrote: post #68

Earlier quoted context omitted.

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.

I sometimes wish git supported hierarchical commits.

I.e., git can retain two representations of a sequence of commits: the original sequence, and also a larger commit that (a) produces the exact same code change as the sequence, and (b) has its own commit message.

Re: Hitting every branch on the way down

#90

Post by plq »

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 :)

Post reply on HN