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: Christian Grothoff
Subject: Re: [GNUnet-developers] Updating my git work-in-progess branch?
Date: Tue, 19 Mar 2019 18:55:47 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0

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 ;-).

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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