This is an addendum to GitMinutes #29: James Moger on GitBlit
This syntax is used for two scenarios.
a. pushing to a ticket that DOES NOT have any commits
b. pushing a rewrite of commits to a ticket that DOES have commits
Details on a.
If I created ticket 5 & pushed some commits to it and you wanted to contribute to this ticket too, you would...
git fetch. This will grab a new branch ref (origin/ticket/5) and then you would "git checkout ticket/5". Git is smart enough to automatically setup "origin/ticket/5" as the remote tracking branch.
Make your commits.
git push. Very simple.
Details on b.
Unless you have RW+ (rewind) permissions the repository, Gitblit will reject non-fast-forward updates pushed to a branch. Tickets need special considerations since I do not want contributors handicapped by the repository-level permissions. You can use the HEAD:refs/for/5 push refspec to push non-fast-forward updates to a ticket and bypass the normal permissions check. There are some permission checks enforced here too - that is documented on my site. This refspec can also be used to push fast-forward updates, but I don't recommend using it that way. It is simpler and better to use the normal Git branch tracking technique.
The Barnum (pt) script simplifies some of this by allowing you to:
# starting and proposing code pt start topic pt propose (HEAD:refs/for/new) pt start N pt propose (HEAD:refs/for/N) # checkout pt checkout N (git checkout ticket/N) pt co N # pushing pt push (push fast-foward to upstream) pt push -f (push rewind HEAD:refs/for/N) # remove local branch pt cleanup N pt rm N