Thread: 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/ > 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
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
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/
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?