Daniel Barkalow <barkalow@xxxxxxxxxxxx> wrote: > On Sun, 13 Aug 2006, Sam Ravnborg wrote: > > > 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. > > 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? 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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html