[RFC] git-publish

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*

Daniel Barkalow <barkalow@iabervon.org> writes:

I for one would be horrified ;-) but that's probably just me.

Some people seem to like 'commit -o' (which now is the default), and worse yet (from 'discipline' point of view) there are even people who want to be able to edit the patch preview in place in 'commit -v' buffer. Commits by these people are by definition not even compile tested in isolation. I suspect those are the very people who would want to push immediately after they make commits.

Chilly.

Don't get me wrong -- I am not opposed to "git-commit && git-push". It may be handy if you are pushing into some alternate (backup) location. But "publish" (implying "public consumption") is too much for my taste, and I am hesitant to endorse such a workflow.

Hi,

On Sun, 13 Aug 2006, Daniel Barkalow wrote:

I found myself the other day, looking for files I committed on a box which was 280 kilometer away, where I forgot to push. So I understand your feeling.

However, adding to Junio's arguments, I find it saner to keep them separated: you should commit _often_. Way more often than you would need to push. There are many reasons, why small patches are more beautiful than big ones, and git actually encourages you to make small patches.

I'd rather have a command which tells me if I have commits after the last time I pushed.

Ciao, Dscho

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Yes.

However, I have not felt the need for "a command". In my workflow, I use tracking branches for the push destination.

Before I rewind / rebase / clean-up, I fetch from my usual push destination with these lines:

	URL: kernel.org:/pub/scm/git/git.git/
        Pull: master:refs/tags/ko-master
        Pull: next:refs/tags/ko-next
        Pull: +pu:refs/tags/ko-pu
        Pull: maint:refs/tags/ko-maint

and have a script to do this (Meta/KO -- found in "todo" branch):

	#!/bin/sh
	git fetch ko
        for i in master next pu maint
        do
        	git show-branch $i ko-$i
        done

I primarily use this to make sure I do not rewind beyond what are already pushed out, but I also can use it to see what's outstanding to be pushed.

On Sun, Aug 13, 2006 at 12:34:49PM -0400, Daniel Barkalow wrote:

hack hack git commit -a test <= ohh crap a trivial bug git format-patch HEAD^..HEAD git reset HEAD^ --hard patch -p1 0001* hack hack git commit -a <= reading in old changelog from 0001*

The above is easier if you know git I expect. If I find bugs in older patches I just go back more steps.

I often (twice or more for each kernel release) throw away my kbuild.git tree and start all over. That gives me a recent kernel to work with and still providing Linux with a linar history.

I have considered stgit - but have not tried it. The above works pretty well for me (my fingers and my logic i accused to it now) so the incentive to shift is small.

But important note is that publishing is something I defer until some limited test has been done. And when I omit that I have always ended u pushing some crappy stuff that needs to be dealt with.

	Sam

On Sun, Aug 13, 2006 at 09:13:46PM +0200, Sam Ravnborg wrote:

If it is the top commit you want to change it is possible to do so with the '--amend' option to git commit. Instead of the sequence of commands above you can just do:

    hack hack
    git commit -a
    test <= trivial bug
    hack hack
    git commit -a --amend

It wont work if you find bugs in older patches though.

I really like stgit. IMHO it is much easier to use stgit when preparing a patch series compared to git itself. Maybe it is because I never got used to the sequence of commands you described above.

- Fredrik

On Sun, 13 Aug 2006, Sam Ravnborg wrote:

I also test before publishing. But I test before committing, too, because I never get anything right (or even logically complete) the first time. My cycle is edit/build/test, and if the test is successful, I commit and push. Do other people really commit after editing each time? Or are they testing before the commit, and doing more extensive testing after the commit before the push?

	-Daniel
*This .sig left intentionally blank*

On Sun, Aug 13, 2006 at 04:11:32PM -0400, Daniel Barkalow wrote:

It happens that I discover bugs while working on next issue. And sometime I get my light moments after commiting a patch.

Obviously I test before commit.

	Sam

On 8/13/06, Sam Ravnborg <sam@ravnborg.org> wrote:

In such a case I usually run git log or gitk to find the commit where a fix is best applied, git checkout -b tmp <commit-sha1>, edit/commit, git checkout <test-branch> (if needed), git pull . tmp, find out that I made a typo, fix it, test, "git checkout -m tmp" and "git commit" and finally merge the tmp branch or cherry-pick the changes somewhere safe. Then remove the tmp branch (it's such a special branch to me). Sometimes I clone the current repo somewhere just to create the temporary branch there, work in the cloned repo, and pull fixes to test back in the first repo (it helps to avoid recompilations, while only fixed files will be updated and recompile)

Daniel Barkalow <barkalow@iabervon.org> wrote:

I typically edit/commit/test, with a possible commit --amend after the test to fix whatever trivial bug came up during the test. But usually I get the initial edit right, so I don't --amend that often.

When building a patch series for core GIT I tend to make heavy use of git-format-pach and git-am; e.g. I'll edit/commit/test each change, then go back and do something like:

	git format-patch -o .. next
	git reset --hard next
	git am ../0003-*
	git am ../0001-*
	git am ../0002-*

or whatever to clean up my history before doing a final test and format-patch for emailing. The reason I do this is I tend to to pay attention to "patch size" when writing a change but I try to minimize the number of changed lines before submitting so the patch is cleaner. :-)

When I'm not hacking on core GIT I'm typically using `git push` to publish my changes to a common repository. In this case I still tend to commit before I test so I'd definately _not_ use a `git commit && git push` style of operation.

Although other SCMs (e.g. SVN or CVS) would encourage you to commit and push to the remote immediately this is actually a pretty bad idea in GIT.

If the remote is ahead of you then the push would automatically fail. If you are working on a team where everyone is doing `git commit && git push` then you will probably find that every other commit the remote is ahead of you, requiring you to pull first. But with CVS and SVN you usually don't run into that issue unless you touched the same files, and typically in that type of workflow users only edit "their" files so conflicts like that tend not to happen very often.

But even worse this style of workflow will generate a very messy history. Almost every commit will have been done in isolation, with yet another merge commit to connect it to the commit that beat it into the shared repository. This is not going to look very pretty in gitk.

So in my humble opinion I think this is not really a workflow style that should be encouraged with GIT. But perhaps tools to show you what would happen if you pushed right now (e.g. a shortlog of the commits that would upload or that must be downloaded and merged) would be useful.

Shawn Pearce <spearce@spearce.org> writes:

Well, non-distributed SCM is totally a different story. For them, committing is to propagating the change to the central repository to be consumed by others.

You can use git in that way as well, but you do not have to, and that is an improvement;-).

On Sun, Aug 13, 2006 at 09:51:27PM -0400, Shawn Pearce wrote:

I think the real reason CVS histories stay un-messy is that 'cvs commit' is actually more like 'git-commit && git-fetch && git-rebase origin && git-push'. That is the workflow I use for small personal repositories where I am replacing CVS with git. I always want to keep the server up to date so my work is accessible from multiple machines, and I almost never want to branch (I generally only rebase because I forgot a push or pull). I still don't think I'd want all of that in one command, though.

Like git-log --pretty=online origin..HEAD?

One of the things I like about git is how easy it is to find out what's going on. I have a large number of small project repostories checked out at any given time. I can quickly get the status of all of them with this script:

  #!/bin/sh

  count_zero() {
      test `"$@" | wc -l` = 0
  }

  check_git() {
    cd $1
    count_zero git-ls-files \
      -m -o -d --exclude-per-directory=.gitignore \
      --directory --no-empty-directory || echo COMMIT:$1
    if test -e .git/branches/origin -o -e .git/remotes/origin; then
      git-fetch || echo FETCH:$1
      count_zero git-rev-list master..origin || echo MERGE:$1
      count_zero git-rev-list origin..master || echo PUSH:$1
    else
      echo ORIGIN:$1
    fi
    test "`git-count-objects | cut -d' ' -f1`" -gt 1000 && echo PACK:$1
  }

  for i in `find $PROJECT_ROOTS -type -d -name .git | sed 's!/.git$!!'`; do
    echo Checking $i...
    errors="$errors `check_git $i`
  done
  echo $errors | sed -e 's/ /\n/g' -e 's/:/: /g'

This lets me know if I've forgotten to commit anything, if I've forgotten to push (or if I haven't even set up an origin yet!), or if there are new changes waiting for me to merge.

-Peff

On 8/14/06, Daniel Barkalow <barkalow@iabervon.org> wrote:

Slightly OT... I thought git-publish host:/path/to/repo.git would be something to automate the initial "publishing" actions, which for me are:

 ssh host 'mkdir path/to/repo.git'
 ssh host 'GIT_DIR=path/to/repo.git git init-db'
 ssh host 'GIT_DIR=path/to/repo.git git repo-config someopts'
 git-push git+ssh://host:/path/to/repo.git

Hmmmm. Would this be git publish-repo maybe?

cheers,

martin

Dear diary, on Mon, Aug 14, 2006 at 01:53:07AM CEST, I got a letter where Martin Langhoff <martin.langhoff@gmail.com> said that...

Actually, this is a nice idea for cg-admin-setuprepo, thanks. :-) It now accepts a git+ssh URL just as well as a local path. (It won't work with git-shell, but that's a good thing.)