This is an addendum to GitMinutes #29: James Moger on GitBlit
push HEAD:refs/for/5
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
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.
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