Skip site navigation (1) Skip section navigation (2)

Re: Caution when removing git branches

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Caution when removing git branches
Date: 2011-01-27 17:19:17
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Thu, Jan 27, 2011 at 11:52 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> Robert Haas wrote:
>> On Thu, Jan 27, 2011 at 11:41 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>> >> Or for that we could just disable branch creation *completely*, and
>> >> then turn off that restriction that one time / year that we actually
>> >> create a branch?
>> >
>> > Well, branch creation can always be undone --- branch removal seems like
>> > the big problem because it can't.
>> As I've repeatedly said, branch removal CAN be undone.  I don't see
>> any evidence that we have an actual problem here that needs worrying
>> about.
> OK, someone removes a branch.  If it is still in his local tree, he can
> push it back.  If not, he has to go around and find someone who does
> have it, and who has the most recent copy?  Can master be removed too?

So if someone does this (which does not look at all likely to me):

git push origin :REL9_0_STABLE
git branch -r -D origin/REL9_0_STABLE
git branch -d REL9_0_STABLE

...then, yes, they will need to find someone who has run 'git pull'
since the last change that was made to that branch.  OR they could get
it back from the anonymous mirror of the canonical repository, which
should always be up to date, OR I think there's an automatically
updated mirror on github also.

The master branch can be removed the same as any other one - just
substitute master in place of REL9_0_STABLE in the above commands.
But why would you do such a nutty thing?  Worst case scenario looks to
me like you type the first of those commands and then go "oh crud".
And if any of our 19 committers were unaware of the hazards of
inserting random colons into their git commands, hopefully this
discussion has awakened them to the error of their ways.

Robert Haas
The Enterprise PostgreSQL Company

In response to


pgsql-hackers by date

Next:From: Bruce MomjianDate: 2011-01-27 17:22:26
Subject: Re: Caution when removing git branches
Previous:From: Greg SmithDate: 2011-01-27 17:18:37
Subject: Re: Spread checkpoint sync

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group