I screwed up matplotlib/master on github

Development matplotlib-devel
1

I offer my sincerest apologies, I royally screwed up and thought
that I was pushing out to one of my own branches and somehow
ended up pushing a 2 day old copy of master out to
matplotlib/master with 'git push -f'. Assuming Mike's work from
today is also in his own master branch, I think the damage can be
undone by just pulling from
https://github.com/mdboom/matplotlib/master and pushing that to
https://matplotlib/matplotlib/master, but at this point I don't
trust myself and just want to not cause any more damage than I've
already done.

I realize that people get their commit right revoked for such
careless shenanigans, but I will be grateful if you'd all allow
me the opportunity always run any push commands with the
--dry-run flag from now on.

very sorry,

···

--
Paul Ivanov
314 address only used for lists, off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7

2

Paul Ivanov, on 2011-03-24 01:30, wrote:

I offer my sincerest apologies, I royally screwed up and thought
that I was pushing out to one of my own branches and somehow
ended up pushing a 2 day old copy of master out to
matplotlib/master with 'git push -f'. Assuming Mike's work from
today is also in his own master branch, I think the damage can be
undone by just pulling from
https://github.com/mdboom/matplotlib/master and pushing that to
https://matplotlib/matplotlib/master, but at this point I don't
trust myself and just want to not cause any more damage than I've
already done.

I realize that people get their commit right revoked for such
careless shenanigans, but I will be grateful if you'd all allow
me the opportunity always run any push commands with the
--dry-run flag from now on.

I can't figure out a way to pull it from there, but I think Eric
was the last to commit to trunk before I (destructively) pushed
my stale copy. Eric's last commit hash was:
8506c33c811e970c6aa73a446d3ed223ac48f989

At least that's what I see on Sign in to GitHub · GitHub

hopefully this will help someone who get git better than I do.

best,

···

--
Paul Ivanov
314 address only used for lists, off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7

3

I offer my sincerest apologies, I royally screwed up and thought
that I was pushing out to one of my own branches and somehow
ended up pushing a 2 day old copy of master out to
matplotlib/master with 'git push -f'. Assuming Mike's work from
today is also in his own master branch, I think the damage can be
undone by just pulling from
https://github.com/mdboom/matplotlib/master and pushing that to
https://matplotlib/matplotlib/master, but at this point I don't
trust myself and just want to not cause any more damage than I've
already done.

I realize that people get their commit right revoked for such
careless shenanigans, but I will be grateful if you'd all allow
me the opportunity always run any push commands with the
--dry-run flag from now on.

With git you can clean up bad commits by simply changing the reference to master, or reorder and edit commits with rebase. Darren, can you take a look and see what should be done? It may be more complicated when you have multiple forks and branches, this part I'm less clear on so perhaps Darren you can comment on this too.

Anyhow Paul, just an accident. Pales in comparison to my losing all of the ancient commit history in a CVS reorganization.

···

On Mar 24, 2011, at 3:30 AM, Paul Ivanov <pivanov314@...149...> wrote:

4

Paul, just an FYI, the section “to reset, or not to reset” on page 24 of “git from the bottom up” discusses resetting the head to prior commits.

http://ftp.newartisans.com/pub/git.from.bottom.up.pdf

But we should let Darren (or someone with comparable git foo) make the call about the right way to repair the tree.

JDH

···

On Mar 24, 2011, at 4:59 AM, John Hunter <jdh2358@…149…> wrote:

With git you can clean up bad commits by simply changing the reference to master, or reorder and edit commits with rebase. Darren, can you take a look and see what should be done? It may be more complicated when you have multiple forks and branches, this part I’m less clear on so perhaps Darren you can comment on this too.

5

Hi Paul,

Paul Ivanov, on 2011-03-24 01:30, wrote:

I offer my sincerest apologies, I royally screwed up and thought
that I was pushing out to one of my own branches and somehow
ended up pushing a 2 day old copy of master out to
matplotlib/master with 'git push -f'. Assuming Mike's work from
today is also in his own master branch, I think the damage can be
undone by just pulling from
https://github.com/mdboom/matplotlib/master and pushing that to
https://matplotlib/matplotlib/master, but at this point I don't
trust myself and just want to not cause any more damage than I've
already done.

I realize that people get their commit right revoked for such
careless shenanigans, but I will be grateful if you'd all allow
me the opportunity always run any push commands with the
--dry-run flag from now on.

I can't figure out a way to pull it from there, but I think Eric
was the last to commit to trunk before I (destructively) pushed
my stale copy. Eric's last commit hash was:
8506c33c811e970c6aa73a446d3ed223ac48f989

At least that's what I see on Sign in to GitHub · GitHub

hopefully this will help someone who get git better than I do.

Welcome to the wonderful world of git and DVCS!

I think you could have solved this one by:

git reset --hard 8506c33c811e970c6aa73a446d3ed223ac48f989

and pushing that. Assuming you had that commit, which I guess you would have.

The way I try and avoid doing that very easy thing is

1) Having a moderately frightening name for the upstream remote like
'upstream-rw'.
2) Having a moderately frightening name for the tracking branch like:

git co -b main-master --track upstream-rw/master

3) Making sure I've got the git-completion bash command line
completion tools working, so I can always see my branch name
4) Never working on main-master, always branching, and merging when I'm sure.
5) Deleting my own master branch to avoid confusion. This involves:

Going to your github fork, choosing Admin, set default branch to be
something other than 'master'

git co that-other-branch
git branch -D master # delete locally
git push origin :master # delete on github

Every error, is a jewel.

See you,

Matthew

···

On Thu, Mar 24, 2011 at 2:55 AM, Paul Ivanov <pivanov314@...149...> wrote:

6

Matthew Brett, on 2011-03-24 16:37, wrote:

Welcome to the wonderful world of git and DVCS!

Thanks, I wish I could claim that I only started using git
recently, but I've just sort of been uncomfortably trying my best
to not cause too much trouble for the past year and a half...

I think you could have solved this one by:

git reset --hard 8506c33c811e970c6aa73a446d3ed223ac48f989

and pushing that. Assuming you had that commit, which I guess you would have.

This actually wasn't the case - I hadn't pulled from
matplotlib/master for a few days, hence the stale commit become a
head after my push.

The way I try and avoid doing that very easy thing is

1) Having a moderately frightening name for the upstream remote like
'upstream-rw'.
2) Having a moderately frightening name for the tracking branch like:

git co -b main-master --track upstream-rw/master

good tips, thanks.

3) Making sure I've got the git-completion bash command line
completion tools working, so I can always see my branch name

This was actually the case for me - I wasn't working on master,
but a seperate branch called 'one-figure' which didn't have a
remote branch affiliated with it (or a wrong one). I had
previously pushed it using 'git push ivanov one-figure', and
*wrongly* assumed that this state was preserved somewhere

16:46@...945...(one-figure)$

4) Never working on main-master, always branching, and merging when I'm sure.

5) Deleting my own master branch to avoid confusion. This involves:

Going to your github fork, choosing Admin, set default branch to be
something other than 'master'

git co that-other-branch
git branch -D master # delete locally
git push origin :master # delete on github

Every error, is a jewel.

Wise words, but if that were true, De Beers and Tiffany's
couldn't hope to compete with me.

best,

···

--
Paul Ivanov
314 address only used for lists, off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7

7

There's also this git command I just discovered. It seems to solve all of these issues, and the documentation is written in the same crystal-clear style of the other git manpages:

Mike

···

________________________________________
From: Paul Ivanov [pivanov314@...149...]
Sent: Thursday, March 24, 2011 8:20 PM
To: matplotlib-devel@lists.sourceforge.net
Subject: Re: [matplotlib-devel] I screwed up matplotlib/master on github

Matthew Brett, on 2011-03-24 16:37, wrote:

Welcome to the wonderful world of git and DVCS!

Thanks, I wish I could claim that I only started using git
recently, but I've just sort of been uncomfortably trying my best
to not cause too much trouble for the past year and a half...

I think you could have solved this one by:

git reset --hard 8506c33c811e970c6aa73a446d3ed223ac48f989

and pushing that. Assuming you had that commit, which I guess you would have.

This actually wasn't the case - I hadn't pulled from
matplotlib/master for a few days, hence the stale commit become a
head after my push.

The way I try and avoid doing that very easy thing is

1) Having a moderately frightening name for the upstream remote like
'upstream-rw'.
2) Having a moderately frightening name for the tracking branch like:

git co -b main-master --track upstream-rw/master

good tips, thanks.

3) Making sure I've got the git-completion bash command line
completion tools working, so I can always see my branch name

This was actually the case for me - I wasn't working on master,
but a seperate branch called 'one-figure' which didn't have a
remote branch affiliated with it (or a wrong one). I had
previously pushed it using 'git push ivanov one-figure', and
*wrongly* assumed that this state was preserved somewhere

16:46@...945...(one-figure)$

4) Never working on main-master, always branching, and merging when I'm sure.

5) Deleting my own master branch to avoid confusion. This involves:

Going to your github fork, choosing Admin, set default branch to be
something other than 'master'

git co that-other-branch
git branch -D master # delete locally
git push origin :master # delete on github

Every error, is a jewel.

Wise words, but if that were true, De Beers and Tiffany's
couldn't hope to compete with me.

best,
--
Paul Ivanov
314 address only used for lists, off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7

8

Yo,

···

On Mon, Mar 28, 2011 at 8:17 AM, Michael Droettboom <mdroe@...31...> wrote:

There's also this git command I just discovered. It seems to solve all of these issues, and the documentation is written in the same crystal-clear style of the other git manpages:

git-brunch(1) — wingolog

It is indeed a stylistic masterpiece. And then you have the aptly
named and actually useful:

http://git-wt-commit.rubyforge.org/git-wtf

Matthew