delete remote branch

Geoffrey Mainland mainland at apeiron.net
Wed Sep 11 20:29:04 UTC 2013


Hi Herbert,

On 09/08/2013 04:43 AM, Herbert Valerio Riedel wrote:
> Hello Nicolas,
>
> On 2013-09-08 at 09:41:04 +0200, Nicolas Frisby wrote:
>> I just merged in my -fdicts-strict work, so I was deleting the old
branch…
>> but it's rejected for some reason.
>>
>> $ git push origin --delete dicts-strict
>> remote: performing tab-check...
>> remote: + refs/heads/dicts-strict ghc <my-username> DENIED by fallthru
>> remote: error: hook declined to update refs/heads/dicts-strict
>> To ssh://git@git.haskell.org/ghc.git
>>  ! [remote rejected] dicts-strict (hook declined)
>> error: failed to push some refs to 'ssh://git@git.haskell.org/ghc.git'
>>
>> Git gurus chime in? Thanks.
> The current configuration doesn't permit risky operations, such as
> deleting branches and/or non-forward-updates (imagine someone would
> delete or rebase branches such as 'master' or 'ghc-7.6'). Moreover,
> having commits disappear causes headaches with other facilities
> (e.g. git submodules).
>
> Moreover, it was planned to define a Git ref namespace, where those
> operations would be allowed to everybody, something like 'wip/*' (see
> [1] for an example). Those branches could then also be made to be
> ignored by the Git email notifier, so that rebasing commits doesn't spam
> the Git commits mailing list.
>
> In the long-term, we should avoid cluttering the top-level branch
> namespace[2] with topic branches, and move to a more structured naming
> scheme, which leaves the top-level namespace to release branches.
>
> Long story short, I've deleted the 'dicts-strict' branch for you
>
> Cheers,
>   hvr
>
>  [1]: https://git.gnome.org/browse/glib/
>  [2]: http://git.haskell.org/?p=ghc.git;a=heads

Maybe you can help me out with my workflow in light of the changes
brought about by the gitolite migration.

For the simd and new-th branches, I periodically rebase my work and push
to the main repo so others can see/review my work. These are necessarily
non-fast-forward pushes. Then, once the branches are rebased and ready
to merge, I plan to perform an empty (comment only) merge commit so that
the merges are obvious in the git history.

But it looks like I can no longer push my work to the repo if I want to
rebase. Not rebasing my branches is a terrible choice. The other options
are to either never push my branches, or to push my branches somewhere
other than to the main repo, e.g., github. Those are both also
undesirable.

Is there any chance we could get the wip namespace up and running soon?

Thanks,
Geoff




More information about the ghc-devs mailing list