#5622 [RFE] Allow user to (create/)delete private branches
Closed: Can't Fix 2 years ago Opened 6 years ago by vondruch.

I'd like to be able to manage my private branches. For example, in preparation for Ruby 2.0 release, I was pushing my changes to .spec file into Ruby's repository in dist git, into ruby-2.0 branch. This branch is already merged into master for some while and I'd like to delete it, but it is forbidden:

{{{
$ git push -f origin :ruby-2.0
remote: + refs/heads/ruby-2.0 ruby vondruch DENIED by fallthru
remote: error: hook declined to update refs/heads/ruby-2.0
To ssh://vondruch@pkgs.fedoraproject.org/ruby
! [remote rejected] ruby-2.0 (hook declined)
error: failed to push some refs to 'ssh://vondruch@pkgs.fedoraproject.org/ruby'
}}}

Would it be possible to allow some development branches, which can be created and deleted as well, without need of opening rel-eng tickets etc?

Thanks


  • related: ticket:5843 - Create koji plugin to allow building only from whitelisted git branches

afaics, the ruby-2.0 branch is not moved into the master branch btw.

Replying to [comment:2 till]:

afaics, the ruby-2.0 branch is not moved into the master branch btw.

It does not really matter. It is obsolete as well as private-ruby-2.1 and private-ruby-2.2 branches.

Replying to [comment:3 vondruch]:

Replying to [comment:2 till]:

afaics, the ruby-2.0 branch is not moved into the master branch btw.

It does not really matter. It is obsolete as well as private-ruby-2.1 and private-ruby-2.2 branches.

If your private branches are merged, they can be deleted, because it guarantees that now commits from which something might have been built is lost. It was more a note for me that nothing can be done here till we have better tools.

@till wrote

If your private branches are merged, they can be deleted, because it guarantees that now commits from which something might have been built is lost.

AFAIK, you can not do "production" builds against private branches, can you elaborate on the issue?

If maintainer merges private branch into "production" branch than from that point nothing really serious can be lost ... So the point is to allow us maintainers to execute git push origin :private-... command (and also git push --force into private branches, do we need separate ticket for this?).

It was more a note for me that nothing can be done here till we have better tools.

Nope, removal of private branches can be allowed even now, that's just a matter of policy in my opinion.

@praiskup you are wrong about some of your assumptions. there is nothing in koji stopping anyone from doing a build from any branch or commit. people can do a build for a release or rawhide from a private branch. there is nothing stopping that from happening.

I am going to close this as can't fix we can look at it again when koji has the ability to control where builds come from

Metadata Update from @ausil:
- Issue close_status updated to: Can't Fix
- Issue status updated to: Closed (was: Open)

2 years ago

@ausil wrote:

there is nothing in koji stopping anyone from doing a build from any branch or commit

Uh. That's certainly issue per se, isn't it? Where is (should be) this tracked?

Anyways, not allowing people to remove the garbage from git branch -a output doesn't help at all with this rel-eng weakness. So I'm not sure why we can not allow it in the end and I tend to reopen.

Anyways, it doesn't really matter whether you allow removing branches or not. I'm sure we have disabled git's garbage collector .. so the data wouldn't be removed from remote git repositories even if we removed the branches, right?

@ausil, ping? Yeah, I'm bit aggravating here, but this needs to be fixed, there's nothing we can't actually fix. If there are blocking issues, I can fill a "blocking" issues on pagure too.

Btw., pagure has also the "cool" misfeature as github -- of not-allowing users to reopen the ticket; I'm curious whether I have to open a new one ...?

That's certainly issue per se, isn't it? Where is (should be) this tracked?

Actually no, and with the idea of going into a more flexible dist-git branching model such as the one proposed by the modularity folks, this is most likely not going to be changed.

Meh. I'm bit disappointed with all this discussion... the reasoning is rather ridiculous:

  • good: packagers are able to create private braches, where branch is just alias for git hash
  • unacceptable!: koji allows production builds against arbitrary branch, how?
  • bad: we don't know how to disable git's garbage collector
  • bad: because of ^^^, packagers are not allowed to drop the private branch (just an "alias" to git hash which persist)

What am I missing?

Well, maybe I should hack on, package and propose on @devel some trivial tool for "requesting branch removal" to make private branches a bit more convenient, as that sounds like a way around this.. Is that acceptable?

unacceptable!: koji allows production builds against arbitrary branch, how?

This is easy, koji doesn't check the branch, all you say is: please koji build this hash from this commit in this tag, kthanksbye

Well, that's acceptable for scratch builds, but for production builds? OK ... I moved off topic.
When we both agree that "building against git hash" is used by Koji, how this is related to the original issue "pretty please, allow me to drop private branches I created"?

We need to make sure that all commits used to build something are preserved in git but we do not have any tools that help us to identify these commits. See also the previous comments such as:
https://pagure.io/releng/issue/5622#comment-406423

We need to make sure that all commits used to build something are
preserved in git

If you don't trust us (packagers), which is weird -> then please turn off
the garbage collector..

but we do not have any tools that help us to identify these commits.

The hash reference is available in koji database, isn't it? What
tool are we talking about?

See also the previous comments such as:
https://pagure.io/releng/issue/5622#comment-406423

I've seen that comment, but TBH I still don't understand the problem. Now I
started build from master branch, and koji tell me:

Parameters
Source: git://pkgs.fedoraproject.org/rpms/multilib-rpm-config?#23edc2081f7bb01a00931831b6afbf9602090336
Build Target: rawhide

I trust the packagers that they would not do this intentionally but mistakes happen and people might have built packages from the wrong branch in the past. The commit needs to be preserved for compliance with the GPL license as far as I know.

The information about the commits is in koji and the database, but there is no tool to easily git a list of all commit hashes for a package. And then there would need to be a second tool that checks for a private branch of a package that there are no commits from the list only in the branch to be deleted.

I trust the packagers that they would not do this intentionally but
mistakes happen and people might have built packages from the wrong
branch in the past. The commit needs to be preserved for compliance
with the GPL license as far as I know.

Agreed -> the commit needs to be preserved, and it will be ->
regardless whether you removed the branch (alias to commit) or not.

The information about the commits is in koji and the database, but there is no
tool to easily git a list of all commit hashes for a package.

Koji gives us "list of builds", which means "list of git hashes". Once
you disable remote git's gc, on the git server you still can do
'git log <sha_hash>'. So nothing is really lost.

More, if there's 'cgit' running (for our dist-git there is cgit), then you can
reference remote <sha_hash> simply through web browser (even if that
hash isn't referenced by any refspec).

I think cgit/git is enough to not loose any important data.

And then there would need to be a second tool that checks for a private
branch of a package that there are no commits from the list only in the
branch to be deleted.

This doesn't really matter. For example, I removed "deleted-branch" from
[1] but you still can see the commit [2] (which is not referenced by
branch anymore). That will work till the commit is garbage collected
(this is server-side configurable).

[1] https://github.com/praiskup/git-gc-test
[2] https://github.com/praiskup/git-gc-test/commit/f6798011beb10a0896e

Also, to get the list of commits - from [2] you could go "up" through
"parent" links.

I'm still interested!

I do not understand the abilities of the infrastructure as well as @praiskup or any of you guys, but If his ideas in the previous message are right, I'm totally giving him '+1' on that!
I'd love to get branches in name format of "private-*" managable.

@till @pingou any updates after a year ?

Login to comment on this ticket.

Metadata