Caution when removing git branches
For those of you using git, I wanted to point out that it is fairly easy
to remove git branches. For example, I can easily remove a branch on
my github repository using:
$ git branch -d :branch_name
I don't believe that is revertable. What is scarey is that this could
be done on our 'origin' as well.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
On Wed, Jan 26, 2011 at 11:26:04AM -0500, Bruce Momjian wrote:
For those of you using git, I wanted to point out that it is fairly easy
to remove git branches. For example, I can easily remove a branch on
my github repository using:$ git branch -d :branch_name
I don't believe that is revertable. What is scarey is that this could
be done on our 'origin' as well.
Note: -d only works if the branch is considered "fully merged". You
need -D to override that check.
Also, it is revertable, sort of. If you know the commit ID it was, you
can:
$ git checkout <commit-id>
$ git branch <branchname>
$ git checkout <branchname>
This will work as long as "git gc" hasn't been run since the delete. If
it's referenced from somewhere else then it will work even after
garbage collection.
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
Show quoted text
Patriotism is when love of your own people comes first; nationalism,
when hate for people other than your own comes first.
- Charles de Gaulle
On 01/26/2011 11:26 AM, Bruce Momjian wrote:
For those of you using git, I wanted to point out that it is fairly easy
to remove git branches. For example, I can easily remove a branch on
my github repository using:$ git branch -d :branch_name
I don't believe that is revertable. What is scarey is that this could
be done on our 'origin' as well.
The ability to remove branches is a feature. I strongly encourage you to
create topic branches for development work, then merge them onto the
main branch, and then delete them. I almost never work directly on, say,
REL9_0_STABLE or master, except for quite trivial changes.
I thought we had some hooks on gitmaster to help prevent accidents like
inadvertent branch deletion.
I at least still keep rolling backups of the main repo. I'm sure I'm not
alone.
cheers
andrew
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
On Wed, Jan 26, 2011 at 11:26:04AM -0500, Bruce Momjian wrote:
For those of you using git, I wanted to point out that it is fairly easy
to remove git branches. For example, I can easily remove a branch on
my github repository using:$ git branch -d :branch_name
I don't believe that is revertable. What is scarey is that this could
be done on our 'origin' as well.Note: -d only works if the branch is considered "fully merged". You
need -D to override that check.
Right, but if I had done 'git merge origin', I could use -d, right?
Also, it is revertable, sort of. If you know the commit ID it was, you
can:$ git checkout <commit-id>
$ git branch <branchname>
$ git checkout <branchname>
Oh, so the commit-id identifies the branch too.
This will work as long as "git gc" hasn't been run since the delete. If
it's referenced from somewhere else then it will work even after
garbage collection.
OK. What happens if :master is deleted? (I don't want to try it, even
on my github).
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
On Wed, Jan 26, 2011 at 11:26 AM, Bruce Momjian <bruce@momjian.us> wrote:
For those of you using git, I wanted to point out that it is fairly easy
to remove git branches. For example, I can easily remove a branch on
my github repository using:$ git branch -d :branch_name
I don't believe that is revertable. What is scarey is that this could
be done on our 'origin' as well.
The colon in that syntax is flat wrong. But branch deletes won't
automatically propagate between repositories. I do things like this
all the time:
git branch -d REL8_4_STABLE
Doesn't delete it from the master at all, and I can recreate it
whenever I like using:
git checkout REL8_4_STABLE
In fact, even I do this, it's harmless:
git branch -r -D origin/REL8_4_STABLE
Because it'll be undone the next time I do this:
git pull
Now, there IS an incantation to destroy a branch from the upstream
repository (using git push with an argument) but even if that
happened, it wouldn't propagate to cloned copies, so someone else
could easily put it back.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Andrew Dunstan wrote:
On 01/26/2011 11:26 AM, Bruce Momjian wrote:
For those of you using git, I wanted to point out that it is fairly easy
to remove git branches. For example, I can easily remove a branch on
my github repository using:$ git branch -d :branch_name
I don't believe that is revertable. What is scarey is that this could
be done on our 'origin' as well.The ability to remove branches is a feature. I strongly encourage you to
create topic branches for development work, then merge them onto the
main branch, and then delete them. I almost never work directly on, say,
REL9_0_STABLE or master, except for quite trivial changes.
Yes, I did that for the contrib-links patch I posted to my github, and
it was easy, and nice to be able to post incremental diffs as I modified
things. I have just deleted that branch locally and on github, which
was easy, and got me thinking about accidental deletion on the origin.
I thought we had some hooks on gitmaster to help prevent accidents like
inadvertent branch deletion.
That would be nice.
I at least still keep rolling backups of the main repo. I'm sure I'm not
alone.
OK, thanks.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
Robert Haas wrote:
On Wed, Jan 26, 2011 at 11:26 AM, Bruce Momjian <bruce@momjian.us> wrote:
For those of you using git, I wanted to point out that it is fairly easy
to remove git branches. ?For example, I can easily remove a branch on
my github repository using:? ? ? ?$ git branch -d :branch_name
I don't believe that is revertable. ?What is scarey is that this could
be done on our 'origin' as well.The colon in that syntax is flat wrong. But branch deletes won't
Sorry, I was wrong. The syntax is:
pggit push github :branch_name
which is even easier to mistype.
automatically propagate between repositories. I do things like this
all the time:git branch -d REL8_4_STABLE
Doesn't delete it from the master at all, and I can recreate it
whenever I like using:git checkout REL8_4_STABLE
In fact, even I do this, it's harmless:
git branch -r -D origin/REL8_4_STABLE
Because it'll be undone the next time I do this:
git pull
Wow, that removes it just from your local tree --- interesting.
Now, there IS an incantation to destroy a branch from the upstream
repository (using git push with an argument) but even if that
happened, it wouldn't propagate to cloned copies, so someone else
could easily put it back.
OK, thanks.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
On Wed, Jan 26, 2011 at 11:49 AM, Bruce Momjian <bruce@momjian.us> wrote:
Robert Haas wrote:
On Wed, Jan 26, 2011 at 11:26 AM, Bruce Momjian <bruce@momjian.us> wrote:
For those of you using git, I wanted to point out that it is fairly easy
to remove git branches. ?For example, I can easily remove a branch on
my github repository using:? ? ? ?$ git branch -d :branch_name
I don't believe that is revertable. ?What is scarey is that this could
be done on our 'origin' as well.The colon in that syntax is flat wrong. But branch deletes won't
Sorry, I was wrong. The syntax is:
pggit push github :branch_name
which is even easier to mistype.
Yeah, true. It's good to avoid inserting a spurious colon there.
Fortunately, that only removes it from the *remote* side, so in the
event that you want to put it back, you can just rerun the command
without the colon.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Robert Haas wrote:
On Wed, Jan 26, 2011 at 11:49 AM, Bruce Momjian <bruce@momjian.us> wrote:
Robert Haas wrote:
On Wed, Jan 26, 2011 at 11:26 AM, Bruce Momjian <bruce@momjian.us> wrote:
For those of you using git, I wanted to point out that it is fairly easy
to remove git branches. ?For example, I can easily remove a branch on
my github repository using:? ? ? ?$ git branch -d :branch_name
I don't believe that is revertable. ?What is scarey is that this could
be done on our 'origin' as well.The colon in that syntax is flat wrong. ?But branch deletes won't
Sorry, I was wrong. ?The syntax is:
? ? ? ?pggit push github :branch_name
which is even easier to mistype.
Yeah, true. It's good to avoid inserting a spurious colon there.
Fortunately, that only removes it from the *remote* side, so in the
event that you want to put it back, you can just rerun the command
without the colon.
I would love to know who thought that magic colon was a good idea? Is
its use even logical there?
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
On Wed, Jan 26, 2011 at 12:07 PM, Bruce Momjian <bruce@momjian.us> wrote:
Robert Haas wrote:
On Wed, Jan 26, 2011 at 11:49 AM, Bruce Momjian <bruce@momjian.us> wrote:
Robert Haas wrote:
On Wed, Jan 26, 2011 at 11:26 AM, Bruce Momjian <bruce@momjian.us> wrote:
For those of you using git, I wanted to point out that it is fairly easy
to remove git branches. ?For example, I can easily remove a branch on
my github repository using:? ? ? ?$ git branch -d :branch_name
I don't believe that is revertable. ?What is scarey is that this could
be done on our 'origin' as well.The colon in that syntax is flat wrong. ?But branch deletes won't
Sorry, I was wrong. ?The syntax is:
? ? ? ?pggit push github :branch_name
which is even easier to mistype.
Yeah, true. It's good to avoid inserting a spurious colon there.
Fortunately, that only removes it from the *remote* side, so in the
event that you want to put it back, you can just rerun the command
without the colon.I would love to know who thought that magic colon was a good idea? Is
its use even logical there?
The logic of it is that you can do this:
git push github localbranchname:remotebranchname
This takes the local branch called "localbranchname" and pushes it to
the remote repository under the name "remotebranchname", so the local
and remote sides needn't match.
If you simply write:
git push github branchname
...then the branchname is used as both the local and remote branch
names, which is usually what you want, since it's typical to call the
branch the same thing everywhere.
In the case where you want to delete a branch, you leave the local
name empty, meaning "push <nothing> on my side to remotebranchname on
the remote side".
I agree it's a little funky, but it's not completely illogical.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Wed, Jan 26, 2011 at 17:37, Andrew Dunstan <andrew@dunslane.net> wrote:
On 01/26/2011 11:26 AM, Bruce Momjian wrote:
For those of you using git, I wanted to point out that it is fairly easy
to remove git branches. For example, I can easily remove a branch on
my github repository using:$ git branch -d :branch_name
I don't believe that is revertable. What is scarey is that this could
be done on our 'origin' as well.The ability to remove branches is a feature. I strongly encourage you to
create topic branches for development work, then merge them onto the main
branch, and then delete them. I almost never work directly on, say,
REL9_0_STABLE or master, except for quite trivial changes.I thought we had some hooks on gitmaster to help prevent accidents like
inadvertent branch deletion.
We have hooks to prevent a number of things, but not the removal of
branches (or tags). We'll send an email to committers telling you it's
been done, but we don't prevent it.
It would probably be pretty easy to add a hook preventing it though -
do we want that? (we could still delete branches of course - but it
would require an admin to do it directly on the git server, which is
highly unlikely to happen by mistake)
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On Thu, Jan 27, 2011 at 11:13 AM, Magnus Hagander <magnus@hagander.net> wrote:
On Wed, Jan 26, 2011 at 17:37, Andrew Dunstan <andrew@dunslane.net> wrote:
On 01/26/2011 11:26 AM, Bruce Momjian wrote:
For those of you using git, I wanted to point out that it is fairly easy
to remove git branches. For example, I can easily remove a branch on
my github repository using:$ git branch -d :branch_name
I don't believe that is revertable. What is scarey is that this could
be done on our 'origin' as well.The ability to remove branches is a feature. I strongly encourage you to
create topic branches for development work, then merge them onto the main
branch, and then delete them. I almost never work directly on, say,
REL9_0_STABLE or master, except for quite trivial changes.I thought we had some hooks on gitmaster to help prevent accidents like
inadvertent branch deletion.We have hooks to prevent a number of things, but not the removal of
branches (or tags). We'll send an email to committers telling you it's
been done, but we don't prevent it.It would probably be pretty easy to add a hook preventing it though -
do we want that? (we could still delete branches of course - but it
would require an admin to do it directly on the git server, which is
highly unlikely to happen by mistake)
I think it's highly unlikely to happen by mistake as it is.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Magnus Hagander <magnus@hagander.net> writes:
On Wed, Jan 26, 2011 at 17:37, Andrew Dunstan <andrew@dunslane.net> wrote:
I thought we had some hooks on gitmaster to help prevent accidents like
inadvertent branch deletion.
We have hooks to prevent a number of things, but not the removal of
branches (or tags). We'll send an email to committers telling you it's
been done, but we don't prevent it.
It would probably be pretty easy to add a hook preventing it though -
do we want that? (we could still delete branches of course - but it
would require an admin to do it directly on the git server, which is
highly unlikely to happen by mistake)
Given that nobody is supposed to push temporary branches to the master
repo anyway, an intended branch removal should be a pretty darn rare
event. Now, our committers all seem to be pretty careful people, so
I don't feel strongly about having extra security on this --- but if
it's easy to do, it's probably a good idea.
regards, tom lane
On 01/27/2011 11:29 AM, Tom Lane wrote:
Given that nobody is supposed to push temporary branches to the master
repo anyway, an intended branch removal should be a pretty darn rare
event. Now, our committers all seem to be pretty careful people, so
I don't feel strongly about having extra security on this --- but if
it's easy to do, it's probably a good idea.
Pushing a local topic branch by mistake seems much more likely to me.
Some protection against that mightn't be a bad idea. Maybe for example a
check on the branch name?
cheers
andrew
On Thu, Jan 27, 2011 at 17:36, Andrew Dunstan <andrew@dunslane.net> wrote:
On 01/27/2011 11:29 AM, Tom Lane wrote:
Given that nobody is supposed to push temporary branches to the master
repo anyway, an intended branch removal should be a pretty darn rare
event. Now, our committers all seem to be pretty careful people, so
I don't feel strongly about having extra security on this --- but if
it's easy to do, it's probably a good idea.Pushing a local topic branch by mistake seems much more likely to me. Some
protection against that mightn't be a bad idea. Maybe for example a check on
the branch name?
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?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
Magnus Hagander wrote:
On Thu, Jan 27, 2011 at 17:36, Andrew Dunstan <andrew@dunslane.net> wrote:
On 01/27/2011 11:29 AM, Tom Lane wrote:
Given that nobody is supposed to push temporary branches to the master
repo anyway, an intended branch removal should be a pretty darn rare
event. ?Now, our committers all seem to be pretty careful people, so
I don't feel strongly about having extra security on this --- but if
it's easy to do, it's probably a good idea.Pushing a local topic branch by mistake seems much more likely to me. Some
protection against that mightn't be a bad idea. Maybe for example a check on
the branch name?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.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
On 27.01.2011 18:41, Bruce Momjian wrote:
Well, branch creation can always be undone --- branch removal seems like
the big problem because it can't.
Actually, all you need to do is to push the branch back to resurrect it.
As long as your local branch is up-to-date with what was removed (or you
know the commitid and still have that in your local repository), no-one
will notice that it was gone for a moment.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
On Thu, Jan 27, 2011 at 11:41 AM, Bruce Momjian <bruce@momjian.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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Robert Haas wrote:
On Thu, Jan 27, 2011 at 11:41 AM, Bruce Momjian <bruce@momjian.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?
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
Andrew Dunstan <andrew@dunslane.net> writes:
On 01/27/2011 11:29 AM, Tom Lane wrote:
Given that nobody is supposed to push temporary branches to the master
repo anyway, an intended branch removal should be a pretty darn rare
event.
Pushing a local topic branch by mistake seems much more likely to me.
Yeah, that's probably true.
Some protection against that mightn't be a bad idea. Maybe for example a
check on the branch name?
If we *don't* install branch-removal defenses on the server, then it's
easy enough to clean up an erroneous branch push. Only if we do that
does this scenario become a problem. I find myself agreeing with Robert
that we may be creating an issue where none exists.
At this point my vote is to leave it alone until and unless we see that
people actually make this type of mistake regularly.
regards, tom lane
On Thu, Jan 27, 2011 at 17:52, Bruce Momjian <bruce@momjian.us> wrote:
Robert Haas wrote:
On Thu, Jan 27, 2011 at 11:41 AM, Bruce Momjian <bruce@momjian.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?
Correct. And *somebody* made the last commit on it, and that somebody
hopefully still has the branch around - and you can find out who that
is by looking at the committers email.
No that's not a streamlined procedure, but it's hopefully ont
something that will happen *often* at least :-)
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
Bruce Momjian <bruce@momjian.us> wrote:
OK, someone removes a branch.
As was explained earlier on this thread, it's not gone at that
point; it's a dangling reference. I think that unless someone
explicitly "prunes" the dangling references, they are left around
for a week, and can easily be checked out again.
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?
If it actually is gone from the server, you can fall back to this,
yeah.
Can master be removed too?
I don't think so.
-Kevin
Tom Lane wrote:
Andrew Dunstan <andrew@dunslane.net> writes:
On 01/27/2011 11:29 AM, Tom Lane wrote:
Given that nobody is supposed to push temporary branches to the master
repo anyway, an intended branch removal should be a pretty darn rare
event.Pushing a local topic branch by mistake seems much more likely to me.
Yeah, that's probably true.
Some protection against that mightn't be a bad idea. Maybe for example a
check on the branch name?If we *don't* install branch-removal defenses on the server, then it's
easy enough to clean up an erroneous branch push. Only if we do that
does this scenario become a problem. I find myself agreeing with Robert
that we may be creating an issue where none exists.At this point my vote is to leave it alone until and unless we see that
people actually make this type of mistake regularly.
OK, I posted the information just so people would be aware of this issue
--- I didn't expect it to be common or something we needed to protect
against.--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
On Thu, Jan 27, 2011 at 11:52 AM, Bruce Momjian <bruce@momjian.us> wrote:
Robert Haas wrote:
On Thu, Jan 27, 2011 at 11:41 AM, Bruce Momjian <bruce@momjian.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
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Robert Haas wrote:
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.
Yes, that was really my goal --- to point out that some git operations
are not reverable.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
On Thu, Jan 27, 2011 at 18:19, Robert Haas <robertmhaas@gmail.com> wrote:
On Thu, Jan 27, 2011 at 11:52 AM, Bruce Momjian <bruce@momjian.us> wrote:
Robert Haas wrote:
On Thu, Jan 27, 2011 at 11:41 AM, Bruce Momjian <bruce@momjian.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.
There is.
Shouldn't we also be able to construct it from the latest mail to
pgsql-committers, since it has the sha1 hash in it..
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
Robert Haas <robertmhaas@gmail.com> wrote:
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.
I thought that git fsck by an administrator on the server would
still show the original as a dangling commit, which could be checked
out by the SHA1 ID. No?
-Kevin
On Thu, Jan 27, 2011 at 12:24 PM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
Robert Haas <robertmhaas@gmail.com> wrote:
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.I thought that git fsck by an administrator on the server would
still show the original as a dangling commit, which could be checked
out by the SHA1 ID. No?
That's yet another way of undoing it.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Thu, Jan 27, 2011 at 12:22 PM, Bruce Momjian <bruce@momjian.us> wrote:
Robert Haas wrote:
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.
Yes, that was really my goal --- to point out that some git operations
are not reverable.
That's true, but hopefully at this point it's clear that actually
getting rid of a branch permanently would require rather a LOT of
work, and that even if someone deliberately did their absolute best to
get rid of a branch, an experienced git user could put it back in less
than 15 minutes.
I actually think a more likely scenario would be: we deliberately
remove a branch - and then someone accidentally re-pushes it. But
since we have no plans to actually do any such thing, that risk also
seems more theoretical than actual.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
andrew@dunslane.net (Andrew Dunstan) writes:
On 01/27/2011 11:29 AM, Tom Lane wrote:
Given that nobody is supposed to push temporary branches to the master
repo anyway, an intended branch removal should be a pretty darn rare
event. Now, our committers all seem to be pretty careful people, so
I don't feel strongly about having extra security on this --- but if
it's easy to do, it's probably a good idea.Pushing a local topic branch by mistake seems much more likely to
me. Some protection against that mightn't be a bad idea. Maybe for
example a check on the branch name?
There seems to be a non-zero amount of value to this; I accidentally
pushed some private branches into the Slony repo this afternoon,
briefly, by accident. It wasn't troublesome to clean it up, so I'm not
sure there's *huge* value in pushing a bunch of infrastructure into
place to prevent such.
If a problem:
a) Is readily fixed,
b) Is readily noticed,
c) Gets you "smacked down" if you leave it unfixed,
then I'm not sure it warrants going to extreme measures to prevent such
a problem.
--
select 'cbbrowne' || '@' || 'linuxdatabases.info';
http://linuxdatabases.info/info/slony.html
If all those psychics know the winning lottery numbers, why are they
all still working?