Hi,
I could'nt resist, so please forgive the shameless self-promotion ☺
I have recently coded a little tool I called git-repo, that you can find
on pypi (pip install git-repo), that simplifies the process:
On Sat, May 28, 2016 at 12:19:21PM -0700, Yegappan Lakshmanan wrote:
> Fork the Vim repository
1. Fork, Clone and configure upstream branch:
% git hub fork --clone vim/vim
→ remote upstream is vim/vim and remote github is <you>/vim
I prefer using github instead of "origin" because that avoids confusion
between upstream and origin… I mean which one is which ? At least, you
know that github remote is always *yours*.
> Synchronizing a fork with the upstream
> $ git checkout master
> $ git fetch upstream
> $ git rebase upstream/master
> $ git push github master
well, that's still explicit, so it's nice!
> Creating a branch
> 1. Clone the Vim repository:
<strikes this>
> $ cd <some-directory>
> $ git clone https://github.com/<your-name>/vim/vim.git
</strikes this>
a. you already got a fork that you've cloned locally, so why make
another clone?
b. the https://github.com/<your-name>/vim/vim.git URL is wrong, it
should be https://github.com/<your-name>/vim.git
But let's consider that you're on a new computer, or you've erased your
local copy:
% git clone <your-name>/vim
> 2. Create a branch for the feature/bug fix:
> $ git checkout -b <branch-name>
> 3. Push the new branch to remote master:
> $ git push github <branch-name>
>
> Committing changes to a branch
> 1. Commit the changes:
> $ git commit -m "Commit comment"
> 2. Push the changes to the branch:
> $ git push github <branch-name>
>
> Creating a pull request
> Go to github.com and create a pull request for the branch to submit
> the changes for merging into the main Vim repository
% git hub request create "title" -m "description"
(I just realized that I forgot to implement that feature, so I'll just
implement it, so thank you for that ☺ I'll add it for v1.6.1)
> Synchronizing a branch with the master
<strikes this>
> $ git checkout master
> $ git fetch upstream
> $ git rebase upstream/master
> $ git checkout <branch-name>
> $ git rebase master
> $ git push --force
</strikes this>
Well there's a bunch of useless commands here!
% git checkout <branch-name>
% git fetch --all
% # here you can review what has changed before rebasing!
% git rebase upstream/master
% git push --force
you could even simplify this with:
% git checkout <branch-name>
% git pull upstream master
% git push --force
Though I prefer to review the fetched commits before changing my local
copy of the branch.
> Cloning a branch
> $ cd <some-directory>
> $ git clone https://github.com/<your-name>/vim.git
Again, why would you create a new directory for cloning a branch? You
can easily switch branches with `git checkout`. And if you've got
uncommitted changes, you can either commit them, or `git stash` them!
% git stash
> $ git checkout <branch-name>
% git stash pop
> Pulling in latest changes from master
<strikes this>
> $ git stash
> $ git pull
> $ git stash pop
</strikes this>
Well that one is confusing for whoever read this, and I guess you're
confused about it. A pull is `git fetch` followed by a `git rebase`.
So instead of stashing your changes, you should:
% git fetch --all
that will download all changes from all branches of all remotes, and
then you will be able to rebase onto the latest upstream's changes
at a convenient time for you:
% git rebase upstream/master
Though you can go review the changes you've fetched from the upstream
before rebasing.
> Misc Commands
> $ git status
> $ git diff origin/master
> $ git log -v
> $ git branch
Don't forget to read the help for most commands:
→ git help stash
→ git help rebase (git rebase -i is both awesome and dangerous)
→ git help reflog (which will save your ass in case you messed up)
On all platforms, you can review graphically using:
→ gitk --all
And on each platform, I can only advise you to use:
→ tig
→ gitg or git-cola on Xorg
→ gitxr on OSX
And add vimagit as a vim plugin, to be able to choose each chunks that
will make a commit, as if you're like me you're always fixing a few bugs
while you're implementing a new feature, but you want to make separate
commits in separate branches for bugfixes and features!
Finally, about the "self-promotion", git-repo is still alpha, I'm
already using it everyday, and it definitely needs a lot of polishing.
So please, if you like it (or the idea): report bugs, feature requests,
submit patches…
It's all on https://github.com/guyzmo/git-repo (it's also on gitlab and
bitbucket, BTW).
Cheers,
--
Guyzmo
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
