From: Johan Herland <johan@herland.net>
To: git@vger.kernel.org
Cc: Johan Herland <johan@herland.net>,
gitster@pobox.com, 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 22:21:12 +0100 [thread overview]
Message-ID: <CALKQrgcY1dVNP0U0NsmDTuZwb6MLNKzmdHxuAb05UmnUcAXf4A@mail.gmail.com> (raw)
In-Reply-To: <1329772071-11301-1-git-send-email-johan@herland.net>
On Mon, Feb 20, 2012 at 22:07, Johan Herland <johan@herland.net> wrote:
> 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 branch has no @{upstream}, or the commits-to-be-rebased are not
> reachable from the upstream (hence assumed to be unpublished), the rebase
> is not refused.
>
> This patch is not an ideal solution to the problem, for at least the
> following reasons:
>
> - There is no way for the user to override this check, except skipping
> the pre-rebase hook entirely with --no-verify.
>
> - The check only works for branches with a configured upstream. If the
> user's workflow does not rely on upstream branches, or uses some other
> method of publishing commits, the check will produce false negatives
> (i.e. allow rebases that should have been refused).
>
> - The check only applies to rebase. I wanted to add the same check
> on 'commit --amend', but there's no obvious way to detect --amend
> from within the pre-commit hook.
>
> - There may be other rewrite scenarios where we want to do this check,
> such as 'git reset'. Maybe a pre-rewrite hook should be added?
>
> - Some (including myself) want this check to be performed by default,
> since it's mostly targeted at newbies that are less likely to enable
> the pre-rebase (pre-rewrite) hook, so maybe the check should be added
> to core git instead.
>
> Discussed-with: Jakub Narebski <jnareb@gmail.com>
> Signed-off-by: Johan Herland <johan@herland.net>
> ---
I forgot to explain that this patch is not really submitted for
inclusion, but rather to continue the discussion of getting rewrite
safety properly implemented in git. As such, the problems noted in the
above commit message are probably more important than the patch
itself...
Also, this implements only a small subset of what has been discussed
regarding 'public' and 'secret' properties of commits in the preceding
thread. However, I believe solving this part of the problem
(preventing upstreamed commits from being rewritten) will make 90% of
users happy, and that it's worth fixing on its own merits.
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
next prev parent reply other threads:[~2012-02-20 21:21 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 [this message]
2012-02-20 22:43 ` Junio C Hamano
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=CALKQrgcY1dVNP0U0NsmDTuZwb6MLNKzmdHxuAb05UmnUcAXf4A@mail.gmail.com \
--to=johan@herland.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jnareb@gmail.com \
--cc=philipoakley@iee.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).