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: Hartmut Goebel
Subject: Re: [GNUnet-developers] Updating my git work-in-progess branch?
Date: Sat, 16 Mar 2019 13:04:16 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1

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 gitlab.digitalcourage.de. 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.

(But anyway we are going to reinvent the wheel, as there are
sophisticated tools for managing all this already. Gitlab is a prominent
example.)

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | address@hidden               |
| www.crazy-compilers.com | compilers which you thought are impossible |





reply via email to

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