gitpr

This is a good article that covers how to communicate in a pull request. I think there are two other essentials in making good pull requests. 1. Good commit messages. Follow this guide: https://chris.beams.io/posts/git-commit/ 2. Following the pull request workflow correctly. Follow this guide: https://github.com/susam/gitpr Writing good and consistent commit messages make the commit log easy to read and search. Pull request workflow is equally important. It is kind of a rules of engagement that co-developers follow to keep working on their stuff concurrently. It keeps unnecessary merges to minimum and keeps the commit history clean. By following these two things, you are not only going to be nice to your co-developers but you are going to be nice to your managers and release departments too who could look at your commit log and figure ou

I never really understood Git until I read this tutorial: https://github.com/susam/gitpr Things began to click for me as soon as I read this in its intro section: > Beginners to this workflow should always remember that a Git branch is not a container of commits, but rather a lightweight moving pointer that points to a commit in the commit history. A---B---C ↑ (master) > When a new commit is made in a branch, its branch pointer simply moves to point to the last commit in the branch. A---B---C---D ↑ (master) > A branch is merely a pointer to the tip of a series of commits. With this little thing in mind, seemingly complex operations like rebase and fast-forward merges become easy to understand and use. This "moving pointer" model of Git branches led me to instant enlightenment. No

All the git-rebase-fu I have ever needed while working with pull requests, I have found in this well written guide: https://github.com/susam/gitpr Quoting from this document below. # Rebase topic branch on the main development branch (optional). git checkout TOPIC-BRANCH git rebase master # Edit commits, e.g., last 3 commits in topic branch (optional). git checkout TOPIC-BRANCH git rebase -i HEAD~3 # Force push rebased/edited commits to the pull request (optional). git push -f origin TOPIC-BRANCH

Recently came across this nice guide on Git pull request workflow: https://github.com/susam/gitpr All the important stuff is in the first 4 pages. I have the PDF version on my desktop. Also printed pages 3 and 4 and stuck it to my cubicle wall.

I agree. If one is going to use LaTeX directly or indirectly via Pandoc, eventually one would have to build up a personal template to fine-tune the look and feel of the documents. If one is going to write LaTeX code anyway, it seems easier and cleaner to use LaTeX all the way, move all the boilerplate along with the personal template to say, a file named preamble.tex, and \input{preamble.tex} in the documents. However, there are situations where Pandoc can be convenient. For example, I wanted a document[1] to be written primarily as README.md (CommonMark format), so that GitHub could render it as the project README. At the same time I wanted to render a PDF output from a customized form of the content. Pandoc is convenient for cases like this although it takes a bit of work to fine-tune the formatting and customize the content for each o

In case anyone finds these useful, here are some git log aliases I use everyday. FORMAT="%C(auto)%h %C(magenta)%ad %C(cyan)%an%C(auto)%d %s" PRETTY="--pretty=format:'$FORMAT' --date=short" git config --global alias.lga "log --graph --all $PRETTY" git config --global alias.lg "log --graph $PRETTY" git config --global alias.la "log --all $PRETTY" git config --global alias.ll "log $PRETTY" git config --global alias.lf "log --pretty=fuller --stat" There are two interesting things to note here: • Since the --decorate option is now enabled by default (at least since Git 2.13), I don't have the --decorate option in my aliases. You may have to add them if you are using an older version of Git. • Often while looking at the commit log, I need to know the commit date and the committer name which --oneline option does not