From: Daniel Barkalow <barkalow@iabervon.org>
Date: Sun, 13 Aug 2006 16:34:49 GMT
Subject: [RFC] git-publish
Message-ID: <Pine.LNX.4.64.0608131158500.9789@iabervon.org>

Like how "pull" is "fetch" + "merge", I think it would be useful to have a 
"commit" + "push". I have the general feeling that this is more like what 
users of other version control systems expect to have happen, and it's 
easy, when working on a non-network-accessible workstation, to commit and 
forget to do anything with the commit before leaving. So I'm considering a 
"git-publish" which is the trivial "git commit $* && git push".

My suspicion is that most people who run commit directly and have a 
default push location tend to want to push after every commit (or, at 
least, be fine with that, and really want to have pushed after the last of 
a batch). (Of course, there are plenty of users who don't want to push so 
often, but I bet they either mostly generate commits with git apply, git 
am, or such, or they don't have a push line and publicize their changes 
with format-patch.)

Actually, I'm also curious as to how other people generate the series of 
commits for a patch series, when they've actually got a working directory 
that contains the end result. I doubt that people actually do their 
modifications in patch order, committing each time, without writing 
and testing the end result.

	-Daniel
*This .sig left intentionally blank*