Problem

  • Whenever I have to rebase a branch in my sandbox against the latest HEAD of the originating project (Drupal core), then I have to use this strange combination of commands, because git.drupal.org globally denies non-fast-forward pushes:

    $ git push --delete platform extension-disco-sun
    To sun@git.drupal.org:sandbox/sun/1255586.git
     - [deleted]         extension-disco-sun
    
    $ git push -u platform extension-disco-sun
    Counting objects: 364, done.
    Delta compression using up to 4 threads.
    Compressing objects: 100% (270/270), done.
    Writing objects: 100% (283/283), 43.45 KiB, done.
    Total 283 (delta 186), reused 0 (delta 0)
    To sun@git.drupal.org:sandbox/sun/1255586.git
     * [new branch]      extension-disco-sun -> extension-disco-sun
    Branch extension-disco-sun set up to track remote branch extension-disco-sun from platform.
    

Proposed solution

  1. Allow non-fast-forward pushes for sandbox repositories.

  2. Simply identify sandbox repositories by the pathname in the repository URI; i.e., /\bsandbox\//

    → I'm aware (AFAIK) that the URIs are just filesystem aliases, so it is theoretically possible to push to a sandbox repo in order to update an official repo - in which case the non-fast-forward protection would be skipped. However, I'm interpreting this entire protection only as a convenience feature in the first place. That's fine, but it shouldn't be git.drupal.org's job to ensure a 100% safe/reliable protection.

Comments

sdboyer’s picture

the solution isn't even that complicated. i delete one line from one file in puppet, and this works.

sdboyer’s picture

and there is no aliasing that would allow the perms from sandboxes to bleed into full projects. totally separate.

sun’s picture

Even better :) That would be fantastic.

damiankloip’s picture

Yes, +1. This sounds like it could make sandbox management a bit easier.

tim.plunkett’s picture

Oh huge +1. I wish I'd have thought to file this issue, I just didn't want to make things more complicated.

sun’s picture

Is there anything I could do to help to move this issue forward?

Rebasing a core sandbox branch sometimes has unique benefits over merging the latest 8.x — e.g. when files are moved to new locations.

Mixologic’s picture

Issue tags: +Git Daemon
drumm’s picture

Status: Active » Closed (cannot reproduce)

I’m pretty sure this was allowed on all non-release branches recently with our legacy Git setup. It is definitely allowed on non-release branches now with GitLab.