Recently I forgot to add #reviewthis directive for modifications of codebase that belongs to team A. And a subtle bug was introduced that way. Ops! I agreed earlier that all changes done to moduleB should be passed to a reviewer that will do peer review for that particular change. What a shame (We are using excellent GitHub’s review mechanism, BTW).
How to avoid that situation in a future? Should I rely on my memory? Is it possible for a human to track so many small rules manually? My intuition tells me that enforcement of those small ruleset should be automated.
GIT allows you to specify so called “commit hooks” that can validate many stages of GIT workflow. I’ll use simplest local verification of commit message, first the rule in plain text:
If you are changing moduleB you should notify developerC about this change
Today I moved using site-uptime.net development from Bazaar repository to GIT using elegant bzr2git script. The why:
- In-place branches (I used to use them heavily)
- Faster (no Python libs loading during “cold” start)
- Can’t live without “git rebase -i” now
Recently I was asked to help with fixing branch that had:
- invalid name (wrong artifact number)
- invalid comment inside (also based on wrong artifact number)
it was a mistake and programmer wanted to preserve changes done on branch, but using different name.
The solution I proposed was to:
If you are merging/cherry-picking changes frequently between GIT branches it’s very useful to know exactly what changes were already merged, what changes are waiting for merge and for wchich change there will be a conflict during merge.
This information should be available from “git log“, but unfortunately I dif not get good results (even with –cherry-pick). Then some other solution must be prepared.
I decided to create a small script that will perform series of cherry-picks and prepare a report that shows integration status. Usage is pretty simple:
$ git-merge-status SHA1..SHA2
I’ve been assigned recently a task to prepare development process for two teams that are working on separate version control systems (GIT and Perforce in my case). One of important parts of this task is to create effective method of syncing codebases between both storages.
Of course we have git-p4 tool, but my requirements are a bit complicated for this tool:
- Only subset of whole GIT repository will be stored in P4
- GIT repository already exists with some history (the same for P4)
so I decided to write small script that will do at least P4 -> GIT sync.