gnunet-developers
[Top][All Lists]
Advanced

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

Re: [GNUnet-developers] Updating my git work-in-progess branch?


From: ng0
Subject: Re: [GNUnet-developers] Updating my git work-in-progess branch?
Date: Tue, 19 Mar 2019 19:05:05 +0000

Christian Grothoff transcribed 5.4K bytes:
> On 3/16/19 10:32 PM, Florian Dold wrote:
> > I agree with what you've said about not encoding hierarchies in
> > gitolite.  I also think that either nobody or everybody should be able
> > to merge into master.
> > 
> > The model of "nobody should push to master" is great if you have the
> > right tooling on the server, but breaks GPG signing of commits by the
> > author, AFAICT.
> 
> Hmm. Are you sure? I understand that sometimes merging and rebasing
> requires re-signing, but I'm not 100% clear on which operations the CI
> would require, and if it is possible to do it with a subset which may
> not require re-signing. Breaking the GPG signing would be a major loss
> indeed.
> 
> > However, I very strongly disagree with what you said earlier about git
> > rebasing, there seems to be some misunderstanding there.
> > 
> > Rebasing a feature branch *on top of another branch* certainly doesn't
> > require a force push.  However, rebasing to clean up my own messy
> > history of some work in progress *does* requires a force push!
> 
> Ah, I was only talking about rebasing on top of another branch.
> 
> > Maybe this is a terminology issue, because "git rebase" is used for both
> > of these things ("merge"-via-rebase and WIP history cleanup).
> 
> Indeed, so not a disagreement, but a terminology issue ;-).
> 
> > Let's say I'm working on my feature branch $foo, branching off from
> > commit $xyz.  Now after I've made some progress, I want to clean up my
> > history, because there were a lot of useless "add/remove debug code" or
> > "WIP" commits.  If I squash/change the last N commits, I either need to
> > abandon this particular feature branch to push my WIP to a new branch
> > $foo2, or I need to merge my (possibly incomplete) feature into master.
> >  The latter is unacceptable, and the former creates lots of branches,
> > one for every history cleanup I'm doing on my WIP.
> > 
> > Especially with gitolite it's pretty trivial to allow force pushes only
> > to branches following a pattern such as "wip/$name", I do not see any
> > reason to not allow this.  Force pushes to all other branches should be
> > reserved for admins and avoided if at all possible.
> 
> Agreed.
> 
> > But please, don't take away my ability to push/save work-in-progress,
> > without having to clutter the whole repo with useless wip-flo-consensus1
> > wip-flo-consensus2 wip-flo-consensus3 and so on that I need to ask some
> > admin to remove.
> 
> Sure, and I'm also fine with allowing people to delete branches as long
> as they are scoped to their prefix, i.e. flo deleting the
> wip-flo-branches should be fine. (ng0: you suggested a nicer naming
> convention, that's also fine with me).
> 
> If someone knows how to encode this in the Gitolite config, please go
> ahead and just do it ;-).
> 

See my last message and read it. It depends on if this
is applicable. I'll spend tomorrow looking into the 2
codebases and deciding on if/how this can be applied
for us.

Unless I'm mistaken by gitolite's own documentation
and it's not just a matter of repo.or.cz branch
vs gitolite old branch.


> _______________________________________________
> GNUnet-developers mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnunet-developers




reply via email to

[Prev in Thread] Current Thread [Next in Thread]