I haven’t tried it myself, but since you know commits A and B have already been rebased and had their conflicts resolved, can’t you instead rebase -i on top of the partial-rebase branch and then drop A and B?
I think this way at least you still benefit from the rebase --edit-todo, which you do not when cherry-picking C^..F.
Or easier, do an interactive rebase and mark the last commit which is in the partial-rebase branch for editing. Then, do `git reset --hard partial-rebase` and continue the rebase.
Huh, I’m pretty sure the version I use is the one from the post and it does have diacritics. (I’m not on my computer now but will check later.)
One thing that bothers me, though, is that “í” is oddly positioned and almost makes it look like there’s an extra space between it and the following character.
Huh, I guess that's true, even on wikipedia. I will have to stop using the word then. Though I'm pretty sure most people use it in day-to-day with much more abandon.
The metaphor, I think, is that your code is a mathematical function, and, to be even more specific and "toy example" about it, let's say it's a polynomial. If the old code was
x^2 + x z + y x + y z
then you notice that you can express the same polynomial as:
(x + y)*(x + z)
It's still the same polynomial, but you "separated concerns", turning it into a product of two simpler factors.
Similar ideas apply to sets of tuples. Perhaps you were given
{(1, 1), (1, 4), (2, 1), (2, 4), (3, 1), (3, 4)}
and you notice that this can be expressed more simply as the Cartesian product:
{1, 2, 3} x {1, 4}
Again, a literal factoring. You can imagine how variations of this idea would apply to database tables and data structures.
That's where I think the word "refactor" comes from.
If you change the polynomial, you change the order of calculations and hence change behaviour. You might get overflows in case of integers or different precision in case of floats.
Nice to learn where the word originates from. Often the meaning of words change over time. E.g. today no horses need involved in bootstrapping.
He said "I think" implying that he is not fully sure about the etymology. There is a history section on wikipedia for refactoring if you are interested.
You are right but in fact the maths are only a means to an end, a model that isn't exactly equal to the final real world implementation in analog or digital electronics.
Sure. Whenever you post on a forum it's half for anybody else reading, right? I just thought it was interesting to consider the underlying metaphor; maybe people don't think about it. Metaphors, connotations, etymologies -- I find these interesting.
> "Specific revisions should be documented, but documentation should not be limited to a specific revision."
I think this boils down to “what do you do if you realize the documentation for v1.1 says that some feature does X when it actually does Y, but you’re already on version 2.2?”
If v1.1 docs are tied to the version tag in VCS, that incorrect statement cannot be fixed.
And it seems that fixing that forces you into backporting documentation even if you don’t release and maintain parallel versions of your software, which… kinda sucks.
To be honest, I much prefer docs in the repo, because it facilitates code review — a good patch touches some implementation, some tests, and some docs.
The downside when only the latest few versions of the software are supported and only the very latest docs are maintained is that historical docs will probably not be fixed.
> If v1.1 docs are tied to the version tag in VCS, that incorrect statement cannot be fixed.
It can be fixed, just checkout the branch, git cherry-pick the updated change set, or even write it by hand, then do a re-release. You should have a process for this anyway as there might be a critical bug in that code that needs to be fixed and a re-release must happen.
Of course git's handling of branches leave much to be desired (I want mercurial to come back just for it's branch handling) and so developers often forget they can do this and it isn't really that hard. It is tedious though, and you will eventually have dual maintenance where you have to write the same code twice just because the two branches have diverged - this shouldn't be an excuse not to do it though.
Delivering the over-complicated feature and improving the performance of the over-complicated feature both seem to get more praise than shipping the simple version to begin with.
