Hi Jiaxun,
On Wed, Oct 09, 2019 at 09:10:57AM +0800, Jiaxun Yang wrote:
> >> I found that there is a typo in the title, please change CFUCFG to
> >> CPUCFG, thanks.
> >>
> >> Huacai
> >
> >It's too late for that - the email you replied to was telling you that
> >the patches have already been applied to mips-next, and I'm not going
> >to
> >rewrite the mips-next branch for something so minor.
>
> Hi Paul,
>
> I think it is worthy to fix this by rewriting mips-next tree. As it
> haven't PR to upward next tree and this typo may lead to confusion in
> future when reviewing git log.
I disagree.
It's fairly common good practice to not rewrite history that has been
shared. Quoting Documentation/process/7.AdvancedTopics.rst:
> Excessive use of this capability can lead to other problems, though,
> beyond a simple obsession for the creation of the perfect project
> history. Rewriting history will rewrite the changes contained in that
> history, turning a tested (hopefully) kernel tree into an untested
> one. But, beyond that, developers cannot easily collaborate if they
> do not have a shared view of the project history; if you rewrite
> history which other developers have pulled into their repositories,
> you will make life much more difficult for those developers. So a
> simple rule of thumb applies here: history which has been exported to
> others should generally be seen as immutable thereafter.
>
> So, once you push a set of changes to your publicly-available server,
> those changes should not be rewritten. Git will attempt to enforce
> this rule if you try to push changes which do not result in a
> fast-forward merge (i.e. changes which do not share the same history).
> It is possible to override this check, and there may be times when it
> is necessary to rewrite an exported tree. Moving changesets between
> trees to avoid conflicts in linux-next is one example. But such
> actions should be rare. This is one of the reasons why development
> should be done in private branches (which can be rewritten if
> necessary) and only moved into public branches when it's in a
> reasonably advanced state.
Rewriting history can complicate things for developers working atop
mips-next (which is something I want to encourage, not make difficult)
and it would mean commit references such as those included in the
"applied to mips-next" emails I send out would become incorrect.
So when commts to mips-next are pushed to kernel.org, I generally won't
change them unless there's something majorly wrong. A single character
typo in a commit message doesn't count as majorly wrong, so no - I won't
be rewriting history to fix it.
Thanks,
Paul
