Hi!

On Tue, Jun 16, 2020 at 02:09:37PM +0100, Jonathan Wakely wrote:
> I see no harm in rebasing public branches as long as nobody expects
> otherwise. A public branch on gcc.gnu.org under refs/heads that is
> being pulled by unknown persons and used in unknown forks for unknown
> purposes shouldn't be rebased, because you don't know who you're
> causing problems for by doing so.

You can cause *inconvenience* for people not expecting it.  But you
cause problems only for people who merge your branch.  Which they
shouldn't do at all, only ever where that is the agreed workflow (so
for GCC, that means never).

> But a personal branch like Segher's
> could disappear at any time. If we're going to discourage rebasing, we
> should also discourage deleting personal branches. But I don't see any
> benefit to that.

It is very simple to work with a branch that rebases.  First you always
fetch it with a +, which works fine on GCC, you should have something
like
        fetch = +refs/users/*:refs/remotes/fsf/users/*
anyway.  And then you just rebase the branches which are on top of other
people's branches when those changed, on top of the new one.  This is
Git 101.

> If I create a branch refs/users/redi/work-in-progress for somebody

That needs to be refs/users/redi/heads/work-in-progress.  Sigh.

> else to look at and then delete it, do I have to remember never to
> create another branch using that name in future, in case somebody
> pulled the old branch before I deleted it?

Heh.  Well, they will still have their copy, and they can rewind history
if they need to as well.

> Randos on the internet aren't going to be basing work on those
> branches accidentally, they're not fetched by default so you have to
> make some non-trivial effort to even fetch them. If you do that, you
> should know you're not using an official GCC branch, but one that
> Segher can rebase or completely delete at any time.

It wouldn't even be *useful* *at all* otherwise.

(All "non-trivial work" that is needed is manually adding back the stuff
that was hidden, like
        fetch = +refs/vendors/*:refs/remotes/fsf/vendors/*
        fetch = +refs/users/*:refs/remotes/fsf/users/*
and adding
        prune = true
and that is all that is needed -- and Git itself tells you if you forgot
the latter, even).

> I think only the owner of a personal branch should decide what
> workflow and rebasing policies apply to that branch.

There *is* no workflow requirement in general, just like not for trunk
or the release branches.  There are a few rules what can and cannot go
in a commit, and that is all.  And that is good.  On user branches
there are even fewer rules, which also is very good (I don't write
changelog entries before I send patches to gcc-patches@, generally.
This is less work, much higher quality changelog, and it forces you to
consider if you structured the patches and the patch series well).


Segher

Reply via email to