Thanks Herbert. Whom should I email you again when I'm ready to delete my other branches? You? Austin? On Sun, Sep 8, 2013 at 3: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

Got it. Thank you, gentlemen. On Sep 10, 2013 8:45 PM, "Austin Seipp" wrote:

Nick, just keep the ActiveBranches[1] page on the wiki up to date. I plan on deleting all the dead branches (and sending out a warning beforehand) after the 7.8 release. We'll be doing other cleanups then too.

On Tue, Sep 10, 2013 at 2:07 PM, Nicolas Frisby wrote:

...

Thanks Herbert.

Whom should I email you again when I'm ready to delete my other branches? You? Austin?

On Sun, Sep 8, 2013 at 3: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

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

-- Regards, Austin - PGP: 4096R/0x91384671

Hello Geoffrey, On 2013-09-11 at 22:29:04 +0200, Geoffrey Mainland wrote: [...]

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

Sure, I've enabled it right now (and we can change the "wip/" branch-prefix lateron should we come up with a better naming); there's only the problem that everytime you push a rebased commit, the email notification will be re-run, and the script will think the rebased commits are completely new; just take that into account when pushing a rebased commit :-) hth, hvr

I haven't a clue what this wip thread is about, but I hope that in due course someone may update the Git Wiki page http://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git, (or wherever) to describe common workflows. I am regularly confused by submodules, and I have no clue about wip stuff. (Probably some of it only needs to be known by super-users.) Thanks Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Herbert | Valerio Riedel | Sent: 12 September 2013 09:40 | To: Geoffrey Mainland | Cc: ghc-devs@haskell.org | Subject: Re: delete remote branch | | Hello Geoffrey, | | On 2013-09-11 at 22:29:04 +0200, Geoffrey Mainland wrote: | | [...] | | > Is there any chance we could get the wip namespace up and running soon? | | Sure, I've enabled it right now (and we can change the "wip/" | branch-prefix lateron should we come up with a better naming); there's | only the problem that everytime you push a rebased commit, the email | notification will be re-run, and the script will think the rebased | commits are completely new; just take that into account when pushing a | rebased commit :-) | | hth, | hvr | _______________________________________________ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs

On 09/12/2013 05:06 AM, Jan Stolarek wrote:

...

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. One more choice is to create a new branch with -vX appended to the name (where X is version number), rebase it on top of master and push that rebased branch:

git checkout my-branch-v1 git checkout -b my-branch-v2 git rebase master git push -u origin my-branch-v2

This workflow has a nice property of avoiding upstream rebasing, which is kinda important if you're not the only person working on a branch (man git-rebase, section RECOVERING FROM UPSTREAM REBASE gives a good description of the problem, if someone is interested). Of course at some point you will probably want to delete older branches, so this doesn't avoid the problem of privilages. Nor does it address the problem of resending commit messages to the list.

Yes, it's not clear that this is a better approach. I'm only rebasing branches for which I am the sole author. I believe Simon M. used a workflow similar to mine for the new codegen branch at one point.

BTW. Why do consider storing code on github to be undesirable? I find github to be much more reliable (in terms of uptime) than our servers + I can do whatever I want with the branches (e.g. I don't store tens of branches from the main repo, just mine branches).

For someone who is as busy as Simon PJ, it's easier to provide a branch in the repo he's already using rather than force him to add yet another remote just to have a look. Especially now that I am now also remote :( I have nothing against github :) Geoff