In typical blogger fashion you assume too much.

The idea being that the mistakes you make and correct in a single
afternoon (or maybe a week) are going to look more like noise than
information in the long run, and you’re better off just recording
history that’s designed to be easy to read. Whereas longer term, you
can’t keep the history in your head anymore, so you use the tool to
record the history that actually happened.

The end result is that when you look at the history, it’ll be
carefully composed in the small, and historically accurate in the
large.

It’s all rather like writing a diary. You edit and revise all you want
as you write each entry, but don’t touch the older ones.

As far as I can see, such a policy is a huge loss, because you lose all that development history. Which, let’s face it, is what a DVCS is supposed to help with.

This is more suited for a stable vs. development branch sort of thing.

Epistemology also somewhat contradicts that. There’s far more about science than its mere results. And often the path to the results is very complicated, sometimes quite convoluted. Having people think that the path of ideas that led to the results is the one exhibited in publications is detrimental to science.

git tag before-rebase-$(date +”%Y%m%d”)

then rebase. Git will remember the old branch, but use the new one.

You could also do use stacked git (stg). With stg you maintain a seri of patch on top of upstream, rebasing them when needed. Stg will remember, separately, the history of each patch.

I recall seeing a long mail from Linus (I can’t think of good terms to find it right now though), where he argues, that recording the work in progress in history is worthless and only the final changes, split into logical chunks, should be recorded.

Linus compared it to math assignment — you have a lot of papers with various calculations, but you only hand in the result and the direct calculation that leads to it. The rest is not interesting. And patches should be the same — you do the work in random order, change your mind a few times in the process, but you should only submit the final change, split into logical chunks. That makes it easier to review the changes. It eventually even makes the history more useful, because it is simpler.

Besides the history being easier to read , one practical upshot is, that you can then effectively bisect the history when looking for when bug was introduced. If you included the work in progress, the bisect would wind up somewhere in the middle of that with something hard to understand if it worked at all, because the guilty commit might be a work in progress state where something else is broken that prevents you from testing what you want.

Pardon my ignorance — may be I didn’t comprehend the problem in its entirety since I do not usually submit lots of patches off git repository.

Why not to keep branch upstream from which is branch-off your upstream-devel from which you generate and submit patches which modified or not accepted virtually in upstream (which you fetch and rebase or I just conventionally do merge origin/upstream which should result in simple rebase since I don’t modify upstream directly). Then simply merge origin/upstream also in your upstream-devel. If there was a change to your patch — there would be a conflict in that place which you can explicitly ‘resolve’ once and forever, and continue your hacking?
or if you hacked on top of it before upstream absorbed it, then branch-off temporary branch at the moment where you submitted your patch (let that commit be aaaaaaaa and new branch name upstream-devel-temp), merge origin/upstream into upstream-devel-temp, and then rebase your changes on top of merged upstream? (then remove prev upstream-devel and rename upstream-devel-temp into upstream-devel)…

or am I too confused and thus confusing others? ;-)