Publishing git trees

Scott@Ubuntu has posted a few times over the past week or so about some of the problems he’s hit while using git and the more I think about them and read them, I think that a lot of it comes down to expectations of a very different mode of working than the git developers "push".

The git way seems to largely be that the most common way for someone new to contribute code is that they write a patch (or series of patches), commit them locally, and then send them via email for review and eventual merging. These are made easier through the existence of commands like git format-patch, git send-email and git am (apply-mailbox). These really are wonderful tools if your workflow is around using email for patch review and merging as is done in the kernel and many other places. There’s certainly an argument to be made that this sort of mailing list review ends up improving code quality. But it’s not the only way. And since git is about there being multiple ways to do things, maybe some of the other ways need to be made easier too…

One of the ones that seems to pop up commonly is that people want to have their trees available for others to pull from/merge in. This is doable today, but as Scott notes, it’s not entirely straight-forward and requires some knowledge of how to set things up. What if, instead, there was a git publish command that was able to essentially push your working branch to a remote location (via ssh/scp) and do the things necessary so that it’s clonable via http out of the box and not require any initial login and creating a repo, etc. The question that comes to mind is “if I run git publish again, how does it differ from a git push” and the answer is probably not much, but I’m open to other opinions

The obvious second step after that would be to add easy-to-use support for publishing to somewhere like gitorious. That would help for people who don’t have web hosting or a number of other things. And that is a gap that bzr ends up filling by allowing people to use launchpad for arbitrary bzr hosting.

The other workflow that might be interesting to better support would be something like Review Board. I keep wanting to set up an instance to play with and possibly even have people use for things like livecd-tools or anaconda patches. It seems to combine some of the upsides of mailing list review (easy for all to see, easy to annotate changes, …) without some of the downsides (mailing lists suck, a topic for another day) There’s some movement underway to try to get an install going for Fedora Infrastructure, so if you’re interested, help is wanted!.

What do people think? Would a git publish command as described above (minus the aside of the Review Board stuff) be useful/interesting?

3 thoughts on “Publishing git trees”

  1. > The question that comes to mind is “if I run git publish again, how does it differ from a git push” and the answer is probably not much, but I’m open to other opinions

    For this reason, maybe it makes more sense to add this as an option to push, something like –do-init or –create which means “create the remote repository if it doesn’t already exist”. Subsequent pushes can just use what’s already there.

    This way you avoid adding command bloat in the core git, and users can always alias “publish” to “push –create” if they like.

Comments are closed.