I really recommend that this be a companion piece to Linus Torvald's own advice, here:
People can (and probably should) rebase their _private_ trees (their own
work). That's a _cleanup_. But never other peoples code.
That's a "destroy history"
Exactly. The kernel community has lots of wisdom built up around rebase vs. merge, and the way I think about it is, imagine a tree of developers with Linus at the top, maintainers in the middle, and leaf nodes at the bottom.
- leaf nodes can and should rebase to ensure whatever they submit is "bisect clean"
- everyone else should never rebase because you'll destroy history
As a leaf node, you should always be committing and submitting the cleanest patches possible. The prime directive is "do not break bisect". There's much more wisdom in:
stgit is a nice tool to manage your patches as a leaf node. It lets you go back and clean up individual patches in your history so that everything you submit is clean.
Maintainers don't rebase, period.
And recently (past 18 months or so), Linus has been yelling at them to not merge from mainline back into their proposed branch before pull request. The rationale is that when you do so, your pull request is now based on untested code.
Most dev communities will never scale as large as lkml, so not all the lkml conventions make perfect sense to adopt. However, like I said, there is still a lot to be learned from the community that's been using git the longest and pushing it the hardest.
Evolve for Mercurial (starting to show up in core mercurial) is trying to cleanly solve this.
It provides (safe) mutable history for local changes (the VCS tracks what is safe and what isn't), and a way to still be able to collaborate on changes without "surprising" the people who pull from you.
The vision was to have phase as the foundation for evolve.
We had some discussions as far back as mid-2010, at the time the feature was called LiquidHg. The first step was phase (differentiate between changeset states), and now it's evolve (make it flow).
Meanwhile I have had to use git for years to get around this lack in mercurial. I can't see what incentive I will have to switch to mercurial's tool when it is fully cooked.
This feature looks nice. I imagine its a bear to safely do :)
I always wished that darcs was usable "in the real world", as the concept of composability is very appealing. Perhaps there is a compromise to be reached here (local patchs with key sequence points?)
I think it looks like a trap, frankly. Give me a good definition for "local". If I mail a patch to someone and they apply it to their tree, what breaks and for whom if one of us then "publishes" it?
I'm sure there's an answer to that question, but I'm equally certain it's not the only question. It's not that git solves all this stuff perfectly, or that it does it in the best way possible, it's that lots of problems in SCM are human communication issues that simply cannot be solved by software. One of git's virtues is that it knows its own limitations.
I was referring to Python doctests (documentation narrative with interspersed Python statements and embedded reference output).
The text looked to me like one could extract all the commands, run them and check their output against the embedded reference output automatically. I don't know, it had such a rigid structure.
On a second look, the output contains timestamps, so what looks like shell output is probably only shell output the author has copied once into their text.
Please keep your comments in place, especially when you receive feedback. If you couldn't contact the person you were trying to give advice to, I suggest you write a post about it rather than inject a piece of text only to delete it an hour later. Your original aim of not cluttering the thread is, well, not that apparent now.
Honestly, this type of pedantry is pointless. We all understood what he meant. English is an evolving language, and many of the things that are "correct" today were similarly "incorrect" yesterday.
Quite. This kind of attachment to the peculiarities of Standard English rarely matters outside highly formal settings - it is as much an enemy of effective communication as its servant.
Example of advise used as a noun, a snowclone most of us have probably encountered: An X's advise to his/her Y (based on the eponymously authored 1811 "Lord Chesterfield's Advise to His Son"), which loses its impact in print if you don't use the not-very-archaic spelling.
He then gives specific advice.