Include all previous git history

[idbrii]

Hi!

I've been tracking your plugin on vim.org in github and I have git history for all previous versions.

Would you consider pulling in my history?
https://github.com/idbrii/bufkill.vim/commits/qpkorr-master

If I git diff 0513f5f cf928d3 (your repo at master and mine at qpkorr-master) and there's no difference.

You can pull in my history like this:

# checkout another branch to preserve what you haven't pushed. That commit
# is the master in your branch at the time I pulled in your changes.
git checkout -b history 0513f5f
git remote add idbrii [email protected]:idbrii/bufkill.vim.git
git fetch idbrii
# see that there are no significant differences
git diff history idbrii/qpkorr-master
# This is the only "dangerous" part, but we're in a new branch, so it's safe.
git reset --hard idbrii/qpkorr-master
# Now if you have any new changes since I pushed, you can reapply them on top.
git checkout master
# Check if you've made changes
git log 0513f5f..master
# If you have changes, rebase on top. If you get any merge conflicts,
# you can skip them since you're rebasing on top of identical code.
git rebase history
# If you don't have any changes, update your master and cleanup
git reset --hard history
git branch -d history

Then you'll have history going back to v1.0

And then I can send you some pull requests for bug fixes.

(Edit: I removed my redundant README in my branch and renamed it to qpkorr-master. I've added more information for rebasing your history.)

[qpkorr]

Hi David!
Thanks very much for your email.
My recent changes were in response to someone wanting an "official" github repo for my plugins, and whilst I use git to maintain my home directory files (dot files, vim files, etc), I wasn't a seasoned github user, and also had to learn how to use subtrees to include the repos in my main repo.
In short, it was a bit of a learning curve - but afterwards - it did occur to me that yes, maybe I should have included all the prior versions - it would be nicer. That said - the old history is somewhat history, which no one is likely ever to care about again (and if they really do, vim.org has it).  Also - I'm a bit of a pragmatist - and happy to add improvements from others via less trackable means (ie, diff the files and merge changes manually).
All of that waffle... means there's a much higher chance of me following your suggestion thanks to you including instructions! :)
I'll try to have a go over the weekend and let you know what happens (one way or another).  In the worst case I'll certainly add your two fixes - one in particular looks rather important!
Cheers,John
From: David Briscoe [email protected]
To: qpkorr/vim-bufkill [email protected]
Sent: Friday, May 15, 2015 2:00 AM
Subject: [vim-bufkill] Include all previous git history (#1)

Hi!I've been tracking your plugin on vim.org in github and I have git history for all previous versions.Would you consider pulling in my history?
https://github.com/idbrii/bufkill.vim/commits/masterIf I git diff 0513f5f 4e303ca (your repo at master and mine at master) then the only difference is the README file copied from vim.org. I can remove that if you'd like.You can pull in my history like this:# checkout another branch to preserve what you haven't pushed. That commit

is the master in your branch at the time I pulled in your changes.

git checkout -b history 0513f5f
git remote add idbrii [email protected]:idbrii/bufkill.vim.git
git fetch idbrii

see that there are no significant differences

git diff history idbrii/master

This is the only "dangerous" part, but we're in a new branch, so it's safe.

git reset --hard idbrii/master
git checkout master

Now if you have any new changes since I pushed, you can reapply them on top.

git rebase history
Then you'll have history going back to v1.0And then I can send you some pull requests for bug fixes.—
Reply to this email directly or view it on GitHub.

[idbrii]

I edited my original instructions a bit. For simplicity, if you just want to grab my history and haven't made any recent changes, you can just do this:

git remote add idbrii [email protected]:idbrii/bufkill.vim.git
git fetch idbrii
git reset --hard idbrii/qpkorr-master

Also, I think once you do that, github will realize that our two repos (and everyone else who cloned vim-scripts) are the same project and we can automatically do pull requests.

[qpkorr]

Hi David,
Thanks for your extra emails.  I had a go.  Your instructions worked fine, but after having doing the reset --hard, I figured I needed to push the changes back.Prior to pushing, I tried a pull, which asked to do a merge.  I tried again without the pull, and the pushing failed and told me to do a pull, thus:#: John@j3lt:/tmp/wipenow ; git pushTo /tmp/vim-bufkill ! [rejected]        master -> master (non-fast-forward)error: failed to push some refs to '/tmp/vim-bufkill'hint: Updates were rejected because the tip of your current branch is behindhint: its remote counterpart. Integrate the remote changes (e.g.hint: 'git pull ...') before pushing again.hint: See the 'Note about fast-forwards' in 'git push --help' for details.
(And I'm using a few temporary clones to test this stuff with, nothing has been pushed to github yet.)
After the pull, the gitk history doesn't really look as we'd want it (and git log looks similar) - any suggestions?gitk appearance attached - note the duplicate commits...
Thanks,John

  From: David Briscoe <[email protected]>

To: qpkorr/vim-bufkill [email protected]
Sent: Friday, May 15, 2015 2:00 AM
Subject: [vim-bufkill] Include all previous git history (#1)

Hi!I've been tracking your plugin on vim.org in github and I have git history for all previous versions.Would you consider pulling in my history?
https://github.com/idbrii/bufkill.vim/commits/masterIf I git diff 0513f5f 4e303ca (your repo at master and mine at master) then the only difference is the README file copied from vim.org. I can remove that if you'd like.You can pull in my history like this:# checkout another branch to preserve what you haven't pushed. That commit

is the master in your branch at the time I pulled in your changes.

git checkout -b history 0513f5f
git remote add idbrii [email protected]:idbrii/bufkill.vim.git
git fetch idbrii

see that there are no significant differences

git diff history idbrii/master

This is the only "dangerous" part, but we're in a new branch, so it's safe.

git reset --hard idbrii/master
git checkout master

Now if you have any new changes since I pushed, you can reapply them on top.

git rebase history
Then you'll have history going back to v1.0And then I can send you some pull requests for bug fixes.—
Reply to this email directly or view it on GitHub.

[idbrii]

Ah, right. I missed a final step:

git push --force origin master

As I said, the "reset --hard" is the dangerous part and we have to force push because we did that. Git rejects pushes that use a different history than what's already in the destination repo. But since we're trying to use history that's shared by me and other vim-scripts cloners, that's what we want.

Prior to pushing, I tried a pull, which asked to do a merge.

Do a pull before any of these steps to ensure your local master is up to date. (I assumed whatever you have locally more up to date than what's on github.) Since we have to do push --force, git will get confused if you pull after the above steps.

[qpkorr]

Thanks David - hopefully both my repos are looking a little better for you now - next step, I guess I'll need to learn about pull requests ;)
Cheers,John
From: David Briscoe [email protected]
To: qpkorr/vim-bufkill [email protected]
Cc: John Orr [email protected]
Sent: Tuesday, May 19, 2015 7:54 AM
Subject: Re: [vim-bufkill] Include all previous git history (#1)

Ah, right. I missed a final step:git push --force origin master
As I said, the "reset --hard" is the dangerous part and we have to force push because we did that. Git rejects pushes that use a different history than what's already in the destination repo. But since we're trying to use history that's shared by me and other vim-scripts cloners, that's what we want.
Prior to pushing, I tried a pull, which asked to do a merge.
Do a pull before any of these steps to ensure your local master is up to date. (I assumed whatever you have locally more up to date than what's on github.) Since we have to do push --force, git will get confused if you pull after the above steps.

—
Reply to this email directly or view it on GitHub.

[idbrii]

I looked around and it seems that the only way you can receive pull requests if by being part of the same network. Since @vim-scripts created the one with all the history, many people have cloned it (including myself).

So you have two choices:

• Delete this repo and re-clone from one in that existing network.
• Keep this the way it is and hope everyone else re-clones from your network.

Re-cloning from one in the existing network doesn't require you to change your local git history. You're just changing what's on github. You will lose anything that's not in the repo: wiki, issues, pull request history. Since your repos are still new, I think that just means this issue, and I'm okay with that if you are.

To re-clone: Delete this repo, clone from mine (which includes your head), then add your new github repo as a remote in your local git. My bufkill and renamer repos have master branches that match your repos.

If you want to test it out, you can do the above steps without deleting this repo and if everything looks good then delete this repo and rename your new one. Github supports renaming pretty well in my experience.

Another caveat is your repo will now say "forked from". I don't know if you can remove that without disconnecting from the network. Maybe you want to fork from vim-scripts and push your changes instead? This article suggested contacting Github support. I've never talked to them, so I don't know how accommodating they are.

[qpkorr]

I don't really understand the vim-scripts repo's intent.  They took a snapshot of the vimscripts scripts from vim.org at some point - but do they update them?  If a script changes on vim.org (as mine have), how is this change meant to be propagated to the vimscripts repo?  I figure there needs to be some mechanism?  Do vimscripts just accept all pull requests - I don't understand how the model is intended to work, so I'm unsure how I should use it, and whether I should.  Is there documentation on the process that you've found? I found none during a quick look.
From: David Briscoe [email protected]
To: qpkorr/vim-bufkill [email protected]
Cc: John Orr [email protected]
Sent: Friday, August 7, 2015 6:13 AM
Subject: Re: [vim-bufkill] Include all previous git history (#1)

I looked around and it seems that the only way you can receive pull requests if by being part of the same network. Since @vim-scripts created the one with all the history, many people have cloned it (including myself).So you have two choices:

• Delete this repo and re-clone from one in that existing network.
• Keep this the way it is and hope everyone else re-clones from your network.
  Re-cloning from one in the existing network doesn't require you to change your local git history. You're just changing what's on github. You will lose anything that's not in the repo: wiki, issues, pull request history. Since your repos are still new, I think that just means this issue, and I'm okay with that if you are.To re-clone: Delete this repo, clone from mine (which includes your head), then add your new github repo as a remote in your local git. My bufkill and renamer repos have master branches that match your repos.If you want to test it out, you can do the above steps without deleting this repo and if everything looks good then delete this repo and rename your new one. Github supports renaming pretty well in my experience.Another caveat is your repo will now say "forked from". I don't know if you can remove that without disconnecting from the network. Maybe you want to fork from vim-scripts and push your changes instead? This article suggested contacting Github support. I've never talked to them, so I don't know how accommodating they are.

—
Reply to this email directly or view it on GitHub.

[bronson]

Hi, the intent was to allow pathogen / vundle / vim-update-bundles to be able to install plugins directly. Now (5 years later), most plugin authors have moved to github and there's much less of a need for the vim-scripts mirror.

Yes, it keeps up-to date: https://github.com/vim-scripts?tab=activity One or two repos are skipped but nobody's dug in to figure out why.

gmarik and I aren't interested in developing vim-scripts further but enough people are still using it that taking it down might be premature. Dunno.

One of these days I intend to make a page explaining all this. :)