> On 16. Mar 2019, at 21:17, Christian Grothoff wrote:
>
> On 3/16/19 11:39 AM, Schanzenbach, Martin wrote:
>>
>>
>>> On 16. Mar 2019, at 02:18, Christian Grothoff
>>> wrote:
>>>
>>> On 3/15/19 5:06 PM, Corvus Corax wrote:
Only maintainers had the ability to merge into "master"
Florian Dold transcribed 1.3K bytes:
> On 3/19/19 8:05 PM, n...@n0.is wrote:
> > Christian Grothoff transcribed 5.4K bytes:
> > 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
On 3/19/19 6:55 PM, Christian Grothoff wrote:
> On 3/16/19 10:32 PM, Florian Dold wrote:
>> 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
On 3/19/19 8:05 PM, n...@n0.is wrote:
> Christian Grothoff transcribed 5.4K bytes:
> 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.
Please see
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
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
n...@n0.is transcribed 16K bytes:
> I'd have to cut lots of context, so I'll be excused for top posting:
>
> Certain parts of the code base would not allow hirachical structural
> access if we wanted it to happen.
> Documentation, which is code on it own, encoding knowledge about
> the software
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
On 3/16/19 11:39 AM, Schanzenbach, Martin wrote:
>
>
>> On 16. Mar 2019, at 02:18, Christian Grothoff wrote:
>>
>> On 3/15/19 5:06 PM, Corvus Corax wrote:
>>>
>>> Only maintainers had the ability to merge into "master" or
>>> "next" ("master" was always frozen between releases, so we merged
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.
Am 15.03.19 um 11:41 schrieb n...@n0.is:
> Hartmut Goebel transcribed 1.3K bytes:
>> I think we never established a branch based workflow.
IC. So this might be the root-cause :-)
Subversion is still in our minds.
> Our default is to never delete branches.
Huh? Really? even merged ones? These
On 3/15/19 5:06 PM, Corvus Corax wrote:
>
> Only maintainers had the ability to merge into "master" or
> "next" ("master" was always frozen between releases, so we merged into
> "next" for new features to be tested until the next release cycle,
> while developers would regularly merge "next" back
On 3/15/19 9:45 AM, Hartmut Goebel wrote:
>
> Am 15.03.19 um 09:19 schrieb Christian Grothoff:
>> Force pushes are never allowed, you must always rebase.
>
> Rebase also requiers a force push since the branch is not continuing the
> prior history.
Eh, according to how I understand Git, this is
Schanzenbach, Martin transcribed 6.2K bytes:
> I think this is a good idea. We should decide on and document branch naming
> and conventions. Then regularly (e.g. when releasing) do housekeeping.
> Further, access control rights could be handled more lax then for branches
> and for the 1-3
I think this is a good idea. We should decide on and document branch naming and
conventions. Then regularly (e.g. when releasing) do housekeeping.
Further, access control rights could be handled more lax then for branches and
for the 1-3 "main" branches we have stronger protection mechanisms.
If I may add a suggestion.
On some other projects I worked on, we used relatively strict
namespacing rules. Branches pushed to the repo should have the name
/ (with further subdirectories possible
depending on whatever the developer considered apropriate. often in the
form of
/ISSUE--
but that
> On 15. Mar 2019, at 09:45, Hartmut Goebel
> wrote:
>
>
> Am 15.03.19 um 09:19 schrieb Christian Grothoff:
>> Force pushes are never allowed, you must always rebase.
>
> Rebase also requiers a force push since the branch is not continuing the
> prior history.
>
> I'm used to provide a
Hartmut Goebel transcribed 1.3K bytes:
>
> Am 15.03.19 um 09:19 schrieb Christian Grothoff:
> > Force pushes are never allowed, you must always rebase.
>
> Rebase also requiers a force push since the branch is not continuing the
> prior history.
I think we never established a branch based
Am 15.03.19 um 09:19 schrieb Christian Grothoff:
> Force pushes are never allowed, you must always rebase.
Rebase also requiers a force push since the branch is not continuing the
prior history.
I'm used to provide a series of patches for review, fix and clean up,
them merge or rebase. So for
Force pushes are never allowed, you must always rebase.
AFAIK only admins can delete branches that have been pushed to the server.
On 3/15/19 8:55 AM, Hartmut Goebel wrote:
> Hi,
>
> I tried updating my work-in-progress branch for gnunet-core using
> force-push: This was "denied by fallthru".
>
Hi,
I tried updating my work-in-progress branch for gnunet-core using
force-push: This was "denied by fallthru".
Then I tried to delete the branch to be able to push it again: This was
"denied by fallthru", too.
How can I update my WIP branch?
Side-qeuestion: How can I delete a branch which is
21 matches
Mail list logo
