From: Junio C Hamano <gitster@pobox•com>
To: Johan Herland <johan@herland•net>
Cc: git@vger•kernel.org, jnareb@gmail•com, philipoakley@iee•org
Subject: Re: [RFC] pre-rebase: Refuse to rewrite commits that are reachable from upstream
Date: Mon, 20 Feb 2012 14:43:15 -0800 [thread overview]
Message-ID: <7vobstjfcs.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <1329772071-11301-1-git-send-email-johan@herland.net> (Johan Herland's message of "Mon, 20 Feb 2012 22:07:51 +0100")
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).
next prev parent reply other threads:[~2012-02-20 22:43 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-04 19:45 [RFD] Rewriting safety - warn before/when rewriting published history Jakub Narebski
2012-02-05 14:33 ` Ben Walton
2012-02-05 15:05 ` Jakub Narebski
[not found] ` <CAFA910035B74E56A52A96097E76AC39@PhilipOakley>
2012-02-05 16:15 ` Jakub Narebski
2012-02-05 17:29 ` Johan Herland
2012-02-05 20:46 ` Jakub Narebski
2012-02-05 22:49 ` Johan Herland
2012-02-06 14:44 ` Jakub Narebski
2012-02-06 15:59 ` Johan Herland
2012-02-06 17:14 ` Jakub Narebski
2012-02-06 20:16 ` Johan Herland
2012-02-07 14:31 ` Jakub Narebski
2012-02-07 15:09 ` Johan Herland
2012-02-10 19:38 ` Jakub Narebski
2012-02-10 20:19 ` Philip Oakley
2012-02-11 13:10 ` Johan Herland
2012-02-11 13:45 ` Jakub Narebski
2012-02-20 21:07 ` [RFC] pre-rebase: Refuse to rewrite commits that are reachable from upstream Johan Herland
2012-02-20 21:21 ` Johan Herland
2012-02-20 22:43 ` Junio C Hamano [this message]
2012-02-21 0:03 ` Johan Herland
2012-02-21 7:44 ` Junio C Hamano
2012-02-21 23:23 ` Johan Herland
2012-02-21 23:43 ` Junio C Hamano
2012-02-21 23:59 ` Dave Zarzycki
2012-02-22 7:09 ` Jeff King
2012-02-22 8:00 ` Dave Zarzycki
2012-04-07 15:01 ` [RFD] Rewriting safety - warn before/when rewriting published history Steven Michalske
2012-04-07 14:49 ` Steven Michalske
2012-02-07 17:27 ` Ronan Keryell
2012-02-06 0:57 ` Steven Michalske
2012-02-06 6:53 ` Johan Herland
2012-02-06 13:45 ` Jakub Narebski
2012-04-07 14:36 ` Steven Michalske
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vobstjfcs.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=jnareb@gmail$(echo .)com \
--cc=johan@herland$(echo .)net \
--cc=philipoakley@iee$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox