Re: [RFC] pre-rebase: Refuse to rewrite commits that are reachable from upstream

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 20, 2012, 22:43 UTC
Message-ID: <7vobstjfcs.fsf@alter.siamese.dyndns.org>
In-Reply-To: <1329772071-11301-1-git-send-email-johan@herland.net>

Johan Herland <johan@herland.net> 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).