Create a gist now

Instantly share code, notes, and snippets.

Working with GitBlit tickets

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

Details on a.

If I created ticket 5 & pushed some commits to it and you wanted to contribute to this ticket too, you would...

  1. 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.

  2. Make your commits.

  3. 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment