Hi, On Sun, May 29, 2016 at 12:59 PM, 'Guyzmo' via vim_dev <[email protected]> wrote: > Hi, > > I couldn’t 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? >
I prefer to use separate directories for each feature/bug fix development. For each directory, I start with cloning the Vim repository. > > b. the https://github.com/<your-name>/vim/vim.git URL is wrong, it > should be https://github.com/<your-name>/vim.git > Yes. I will fix it. > > 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 > I will try these steps and will update the list. > > 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! > As I mentioned above, I prefer to use a separate directory for each feature development. > > % 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 > What will happen to the changes in the local directory? Will the above command overwrite all the local changes or will it automatically merge the changes? - Yegappan > > 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.
