Johan Herland <johan@xxxxxxxxxxx> writes:
> Teach the pre-rebase sample hook to refuse rewriting commits on a branch
> that are present in that branch's @{upstream}. This is to prevent users
> from rewriting commits that have already been published.
If the user has configured an option to always create @{u} when creating a
branch from somewhere else, transplanting $n good commits from his master
that is forked from the shared master onto his maint would be done like
this:
$ git checkout -b copy master
$ git rebase -i --onto maint HEAD~$n
If these good commits have been published to 'master', because the
upstream of 'copy' is set to the local 'master', would the new mechanism
hinder this attempt to backport good fixes? Perhaps it is safer to
trigger only when @{u} exists and it is not local?
But because you wanted to discuss more about the issues than the
implementation, let me think aloud a bit, reviewing what I usually do.
I keep things simpler by sticking to a very simple rule. I allow myself to
rebase only what is not yet in 'next', so the logic becomes a simple "am I
creating a new commit based on what is already in 'next'?"
During the course of integration testing with 'next', however, I often
find a topic or two that I have merged to it is less than ideal, and of
course, the whole point of doing integration testing with 'next' is to
find such problematic topics before pushing 'next' out. I rewind 'next',
rebuild the problematic topics, and then rebuild 'next', and all of these
happen before 'next' is pushed out. The step that rewinds 'next' that
acquired problematic versions of the topics makes the topics eligible for
rebase.
That would mean that a configuration variable "rebase.bottomLimit = next"
is sufficient to implement such a check for me. No per-branch bottom is
needed, because everything is merged to 'next' and tested to see if they
do not need further rebases for fixing them up before they are published.
Perhaps "I mistakenly rebased something that I have already published" is
a mere symptom a bigger problem. The issue may not be that we do not give
them a good tool to help them to be more careful with less effort on their
part before they rebase. It may instead be that it is too easy to publish
branches that are not ready to be pushed out, and that is the real cause
of the "I realized I need to fix the topic and I fixed it, but I did not
realize that it was too late and I shouldn't have rebased" problem.
I wonder if it would be a more direct solution to the issue you are
raising to give them a good tool to help them to be more careful with less
effort on their part before they publish (not before they rebase).
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html