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
On 3/15/19 4:06 PM, Schanzenbach, Martin wrote:
> No it was not.
> I am pretty sure that instead of calling gnunet-uri as a binary from a binary
> is pretty nonsensical.
Why? I see nothing wrong with that. It's not like this matters for
performance or that starting gnunet-uri has any other real
Am 15.03.19 um 06:34 schrieb Christian Grothoff:
> Looks good to me. Could you please push it to gnunet-*, libextractor,
> libmicrohttpd and the taler-* Git repos? Thanks! -Christian
I added the .dir-local.el to gnunet-...
cocoa dbus ev ext fuse gtk guile guile2 java-ext java nim python
rest-api
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
No it was not.
I am pretty sure that instead of calling gnunet-uri as a binary from a binary
is pretty nonsensical.
Instead, gnunet-qr should just do what gnunet-uri does with the uri.
If we need to share code between them, fine, then refactor. But imitating
python behavior here is not good
> 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
13 matches
Mail list logo
