Branches are Scary

Branches are Scary

[Phillip Lord]

I was wondering if anyone could describe the git setup wrt to branches
on the main Emacs git.

I always find deleting branches (that I have created) rather an unhappy
experience, as I worry that I will do the wrong thing, and accidentally
delete emacs-25.

At the same time, if I am understanding things correctly, I can't squash
and force feature and fix branches that I have pushed up, which means
that these have to get deleted unmerged cause I squash and merge locally.

Perhaps I am worried about this unnecessarily. Can I delete emacs-25 or
master by mistake? And, at the same time, is it possible to squash
things in other branches?

Phil

Re: Branches are Scary

[Ingo Lohmar]

Hi Phillip,

On Thu, Dec 17 2015 21:25 (+0000), Phillip Lord wrote:

> I was wondering if anyone could describe the git setup wrt to branches
> on the main Emacs git.

>
> I always find deleting branches (that I have created) rather an unhappy
> experience, as I worry that I will do the wrong thing, and accidentally
> delete emacs-25.

If you only delete local branches, that should not happen without your
explicit consent (unless you are using a fairly malicious interface on
top of plain git).

>
> At the same time, if I am understanding things correctly, I can't squash
> and force feature and fix branches that I have pushed up, which means
> that these have to get deleted unmerged cause I squash and merge locally.

It seems that *this* is the actual problem to solve.  The rule of thumb
is simple: Do not squash or rebase any commits you have pushed out, it
makes life hard for everybody else, that's why it's not allowed in the
repository.  If you still plan substantial cleanup of your commits, just
do not push them yet.

I am also unsure whether force-deleting branches in the emacs repo is
permitted, but it does not matter: Please do not try to work around the
restrictions by deleting branches.

>
> Perhaps I am worried about this unnecessarily. Can I delete emacs-25 or
> master by mistake? And, at the same time, is it possible to squash
> things in other branches?
>
> Phil

The concept of squashing is fairly unrelated to the concept of branches.
The rules are the same for all commits, wherever they are.

Ingo

Re: Branches are Scary

[Phillip Lord]

Ingo Lohmar <i.lohmar@gmail.com> writes:
>> I always find deleting branches (that I have created) rather an unhappy
>> experience, as I worry that I will do the wrong thing, and accidentally
>> delete emacs-25.
>
> If you only delete local branches, that should not happen without your
> explicit consent (unless you are using a fairly malicious interface on
> top of plain git).

I'm using magit. I don't know what will happen if I try, and obvious, I
don't want to try.


>> At the same time, if I am understanding things correctly, I can't squash
>> and force feature and fix branches that I have pushed up, which means
>> that these have to get deleted unmerged cause I squash and merge locally.
>
> It seems that *this* is the actual problem to solve.  The rule of thumb
> is simple: Do not squash or rebase any commits you have pushed out, it
> makes life hard for everybody else, that's why it's not allowed in the
> repository.  If you still plan substantial cleanup of your commits, just
> do not push them yet.

Makes it hard to get comments on them, I think. I had substantial
comments on one branch (couldn't have completed it without them) as well
as an effective code review before I merged. Possibly, the solution is
not to use the main emacs git for this form of collaboration, but to
publish my own repo, but this seems an obvious use to me.

Clearly rebasing on a branch with many people are working on would be
bad.

> I am also unsure whether force-deleting branches in the emacs repo is
> permitted, but it does not matter: Please do not try to work around the
> restrictions by deleting branches.

I'm not. Just trying to clean up after myself.

>
>>
>> Perhaps I am worried about this unnecessarily. Can I delete emacs-25 or
>> master by mistake? And, at the same time, is it possible to squash
>> things in other branches?
>>
>> Phil
>
> The concept of squashing is fairly unrelated to the concept of branches.
> The rules are the same for all commits, wherever they are.

Then I have learned something. Probably I can delete emacs-25 if I want.
Ah, well, I will just have to be careful.

Phil

Re: Branches are Scary

[John Wiegley]

>>>>> Phillip Lord <phillip.lord@russet.org.uk> writes:

> Then I have learned something. Probably I can delete emacs-25 if I want. Ah,
> well, I will just have to be careful.

Git supports blocking force pushes and branch deletions on the server-side;
this should be something we can setup on Savannah.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Branches are Scary

[Eli Zaretskii]

> From: phillip.lord@russet.org.uk (Phillip Lord)
> Date: Thu, 17 Dec 2015 21:25:35 +0000
> 
> I was wondering if anyone could describe the git setup wrt to branches
> on the main Emacs git.

There's no setup I could think of.  There are official branches where
development of to-be-released versions is going on, and there are all
the other branches people push to let others try experimental
features.

> I always find deleting branches (that I have created) rather an unhappy
> experience, as I worry that I will do the wrong thing, and accidentally
> delete emacs-25.

If you are afraid of deleting branches, don't.  Someone else will come
and do it eventually.

> At the same time, if I am understanding things correctly, I can't squash
> and force feature and fix branches that I have pushed up, which means
> that these have to get deleted unmerged cause I squash and merge locally.

Public branches are public branches; don't do there anything that will
cause pain to people who might track them.

> Perhaps I am worried about this unnecessarily. Can I delete emacs-25 or
> master by mistake? And, at the same time, is it possible to squash
> things in other branches?

I suggest to refrain from squashing on public branches.  Why do you
need it?

Re: Branches are Scary

[Eli Zaretskii]

> From: phillip.lord@russet.org.uk (Phillip Lord)
> Date: Thu, 17 Dec 2015 22:20:06 +0000
> Cc: emacs-devel@gnu.org
> 
> >> At the same time, if I am understanding things correctly, I can't squash
> >> and force feature and fix branches that I have pushed up, which means
> >> that these have to get deleted unmerged cause I squash and merge locally.
> >
> > It seems that *this* is the actual problem to solve.  The rule of thumb
> > is simple: Do not squash or rebase any commits you have pushed out, it
> > makes life hard for everybody else, that's why it's not allowed in the
> > repository.  If you still plan substantial cleanup of your commits, just
> > do not push them yet.
> 
> Makes it hard to get comments on them, I think.

How's that?  Can you tell more details how getting comments requires
squashing?

> Possibly, the solution is not to use the main emacs git for this
> form of collaboration, but to publish my own repo

That'd be less convenient, so I think we should avoid that as much as
possible.

> Clearly rebasing on a branch with many people are working on would be
> bad.

Why not merge instead?  That's what I do, and I have yet to see a
single problem.  What am I missing?

Re: Branches are Scary

[Yuri Khan]

On Fri, Dec 18, 2015 at 1:28 PM, Eli Zaretskii <eliz@gnu.org> wrote:

>> > If you still plan substantial cleanup of your commits, just
>> > do not push them yet.
>>
>> Makes it hard to get comments on them, I think.
>
> How's that?  Can you tell more details how getting comments requires
> squashing?

Getting comments doesn’t. Acting on comments sort of does.

Sure, you can push a follow-up commit with a “Post-review fix”
subject, but it makes history too detailed. Or you can squash fixes
into the commits that introduced the respective issues.

Re: Branches are Scary

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Fri, 18 Dec 2015 13:49:39 +0600
> Cc: Phillip Lord <phillip.lord@russet.org.uk>, i.lohmar@gmail.com, 
> 	Emacs developers <emacs-devel@gnu.org>
> 
> On Fri, Dec 18, 2015 at 1:28 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> >> > If you still plan substantial cleanup of your commits, just
> >> > do not push them yet.
> >>
> >> Makes it hard to get comments on them, I think.
> >
> > How's that?  Can you tell more details how getting comments requires
> > squashing?
> 
> Getting comments doesn’t. Acting on comments sort of does.
> 
> Sure, you can push a follow-up commit with a “Post-review fix”
> subject, but it makes history too detailed. Or you can squash fixes
> into the commits that introduced the respective issues.

I see, thanks for explaining.

So I think the too detailed history is not important for these
branches, since they eventually are going to be deleted.  Therefore,
my advice is just not to squash there.

Alternatively, one could push a new branch after each round of comment
adjudication, and have that new branch have all the changes squashed
into a single commit.  The previous branch would then be deleted.

Re: Branches are Scary

[Phillip Lord]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Yuri Khan <yuri.v.khan@gmail.com>
>> Date: Fri, 18 Dec 2015 13:49:39 +0600
>> Cc: Phillip Lord <phillip.lord@russet.org.uk>, i.lohmar@gmail.com, 
>> 	Emacs developers <emacs-devel@gnu.org>
>> 
>> On Fri, Dec 18, 2015 at 1:28 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> 
>> >> > If you still plan substantial cleanup of your commits, just
>> >> > do not push them yet.
>> >>
>> >> Makes it hard to get comments on them, I think.
>> >
>> > How's that?  Can you tell more details how getting comments requires
>> > squashing?
>> 
>> Getting comments doesn’t. Acting on comments sort of does.
>> 
>> Sure, you can push a follow-up commit with a “Post-review fix”
>> subject, but it makes history too detailed. Or you can squash fixes
>> into the commits that introduced the respective issues.
>
> I see, thanks for explaining.

Exactly. My patch to undo.c was a single commit, but was squashed from
about 20, some of which introduced C primitive functions which were
later removed again, and many of which were small changes.

> So I think the too detailed history is not important for these
> branches, since they eventually are going to be deleted.  Therefore,
> my advice is just not to squash there.

Is what I did. But that doesn't allow you to get feedback on the final
completed feature.


> Alternatively, one could push a new branch after each round of comment
> adjudication, and have that new branch have all the changes squashed
> into a single commit.  The previous branch would then be deleted.

Yes, that also works but is long-winded. Alternatively, have feature and
fix branches squashable, while emacs-* and master-* are not so.

Phil

Re: Branches are Scary

[Random832]

Eli Zaretskii <eliz@gnu.org> writes:
> So I think the too detailed history is not important for these
> branches, since they eventually are going to be deleted.  Therefore,
> my advice is just not to squash there.

If they get merged, the branch may be deleted but the history
stays forever, as part of the history graph of the branch it is
merged into.  I suppose you could squash (and rebase, so the
parent branch can be fast-forwarded) before merging, so that the
merge reflects the squashed history rather than the real history
that existed on the branch (and then never push the squashed
version to the feature branch).  Is that what you meant?

Seems... fiddly, to me.

Re: Branches are Scary

[Eli Zaretskii]

> From: Random832 <random832@fastmail.com>
> Date: Fri, 18 Dec 2015 10:48:48 -0500
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> > So I think the too detailed history is not important for these
> > branches, since they eventually are going to be deleted.  Therefore,
> > my advice is just not to squash there.
> 
> If they get merged, the branch may be deleted but the history
> stays forever, as part of the history graph of the branch it is
> merged into.

I see no problem with that, FWIW.

> I suppose you could squash (and rebase, so the parent branch can be
> fast-forwarded) before merging, so that the merge reflects the
> squashed history rather than the real history that existed on the
> branch (and then never push the squashed version to the feature
> branch).  Is that what you meant?

That's one possibility, yes.  Another produce diffs from the branch
and apply them to master (since you don't want the history, why do it
via Git?).  And I'm sure there's more.

Re: Branches are Scary

[Phillip Lord]

Random832 <random832@fastmail.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>> So I think the too detailed history is not important for these
>> branches, since they eventually are going to be deleted.  Therefore,
>> my advice is just not to squash there.
>
> If they get merged, the branch may be deleted but the history
> stays forever, as part of the history graph of the branch it is
> merged into.  I suppose you could squash (and rebase, so the
> parent branch can be fast-forwarded) before merging, so that the
> merge reflects the squashed history rather than the real history
> that existed on the branch (and then never push the squashed
> version to the feature branch).  Is that what you meant?
>
> Seems... fiddly, to me.

It's a fairly normal way of operating. Currently, the squashed version
has to be off the main git, though, because you can't force push. So the
last commit before the merge can't be reviewed by some else, at least
not on the branch that it started off from.

Phil