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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Feb 20, 2012 at 22:07, Johan Herland <johan@xxxxxxxxxxx> 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@xxxxxxxxx>
> Signed-off-by: Johan Herland <johan@xxxxxxxxxxx>
> ---

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@xxxxxxxxxxx>
www.herland.net
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]