Hitting every branch on the way down
rachelbythebay.com
Hitting every branch on the way down
1–10 of 144 posts
Re: Hitting every branch on the way down
#2I 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!
Re: Hitting every branch on the way down
#3I 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 not built solo though.
Re: Hitting every branch on the way down
#4I 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 looks in the local tree.
Re: Hitting every branch on the way down
#5I 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!
What I find strange is that traditionally included system header files and "" included local files. They used different include paths, so you could have a header file in your sources with the same name as the system header file and then could control whether you are including one or the other based on using or "".
Anyway, I thought the distinction was lost in later compilers in favor of a single include path and then just taking the first file found when looking at potential matches through include path.
It seems the author of that merge thought the same thing. So, the distinction is actually still used by compilers?
Re: Hitting every branch on the way down
#6I 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!
But a rebased commit can also have arbitrary changes!
---
P.S. Any commit can have any change. Or no change.
A "commit" is a version...a message, a tree, some metadata, and 0 or more parents. In fact it's not even a change/diff/patchset per se. Though will often compare it against its assigned parents. If it has multiple parents, you'd have to choose which to compare. If it has zero parents, you can't compare against any parents.
Re: Hitting every branch on the way down
#7 $ git show d85c9944c55fb38f4eae149979a0f680ea125ecb | wc -l
11067
$
Presumably the author would have been happier using the -m-flag in addition to -p.
Re: Hitting every branch on the way down
#8I 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!
But a rebased commit can also have arbitrary changes! --- P.S. Any commit can have any change. Or no change. A "commit" is a version...a message, a tree, some metadata, and 0 or more parents. In fact it's not even a change/diff/patchset per se. Though will often compare it against its assigned parents. If it has multiple parents, you'd have to choose which to compare. If it has zero parents, you can't compare against…
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.
Re: Hitting every branch on the way down
#9[deleted]
Re: Hitting every branch on the way down
#10Earlier quoted context omitted.
But a rebased commit can also have arbitrary changes! --- P.S. Any commit can have any change. Or no change. A "commit" is a version...a message, a tree, some metadata, and 0 or more parents. In fact it's not even a change/diff/patchset per se. Though will often compare it against its assigned parents. If it has multiple parents, you'd have to choose which to compare. If it has zero parents, you can't compare against…
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.