[Top][All Lists]

[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: Sat, 16 Mar 2019 13:22:37 +0000

Hartmut Goebel transcribed 3.6K bytes:
> Am 16.03.19 um 02:07 schrieb Christian Grothoff:
> > On 3/15/19 9:45 AM, Hartmut Goebel wrote:
> >
> >> Rebase also requiers a force push since the branch is not continuing the
> >> prior history.
> > Eh, according to how I understand Git, this is wrong. When you rebase
> > (against head), you move the commits of the branch on the end of the
> > prior history, and thus do not require a *force* push.
> When rebasing, no matter onto where, every commit gets a new parent.
> Thus it will be a *new* commit. The head-ref of your old branch will be
> set to your new (rebased) branch's head. The old branch does not have
> any connection to new one. The commit-graph will look like a tree. You
> can easily view this using "gitk --all" and pressing F5 after rebase.
> Thus you can not "forward" the old head-ref to the new. And this is why
> one needs to force-push.
> >
> >> I'm used to provide a series of patches for review, fix and clean up,
> >> them merge or rebase. So for review I need to use an external repo, e.g.
> >> at Not much of a problem for me, but this
> >> hinders the reviewers workflow.
> > I don't understand why what we do needs you to use an external repo.
> > Maybe I am not understanding something.
> Since I neither can delete me old work-in-progress (WIP) branch nor
> force-push on the gnunet-reps, this way of iterating does not work using
> the gnunet-repos. If I want to keep this style - which I consider useful
> to increase the code quality - I need an exeternal repo.
> >> So after merging a branch I need to ask an admins to remove the old
> >> branch? Is this a Arbeitsbeschaffungsma├čname?
> > Not intentionally, but I don't see a way to avoid this without also allowing
> > someone to do "damage" (deletion that cannot be easily undone). If there
> > is a way to do this differently, please let us know and we'll deploy it.
> One way would be to protect the important branches only. Or we could
> allow to delete and force-push all branches starting with "WIP-"
> Another, more complicated way would be to  agree in some naming scheme
> for branches, e.g. the one CorvusCorax suggested (username/...), and
> allow only the user to delelte/force-push the names in her namespace.
> Everyone needs to know her username than, though.

It's a bit more involved on the configuration side but we can do this
with gitolite for now.
As we are doing some maintenance work next week, let's do this the
following week after the maintenance work.
> (But anyway we are going to reinvent the wheel, as there are
> sophisticated tools for managing all this already. Gitlab is a prominent
> example.)

I think we wanted to try Gitlab. With the current move to Debian + Guix
instead of full GuixSD we could get there faster.
> -- 
> Regards
> Hartmut Goebel
> | Hartmut Goebel          | address@hidden               |
> | | compilers which you thought are impossible |
> _______________________________________________
> GNUnet-developers mailing list
> address@hidden

reply via email to

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