4 ms·

So you end up committing untested code? (since you did test the whole change, not just part of it). Sounds like a bad idea to me.

• _ikke_ 14y ago
  git stash -k; make test; git stash pop, git commit; Problem solved.
  • tebeka 14y ago
    The problem is with the process, people will forget. You probably need to automate this.
    • _ikke_ 14y ago
      If people forget to test their commits, they're going to forget them without using git add -p too.
    • DannoHung 14y ago
      test: stash-keep-index
• masklinn 14y ago
  That is most definitely a major issue of this technique, though it can probably be mitigated through various hooks.
  • stevvooe 14y ago
    I find this technique great to keep unrelated fixes in separate commits. A single revision may not pass a set of unit tests, but the entire feature branch will before being merged into the release line. Keeping the barrier low for committed code is one of git's best features.
    • chimeracoder 14y ago
      > Keeping the barrier low for committed code is one of git's best features. When I first learned git, I was told, 'You'll never have to comment out code again'. Keeping the barrier for commits low (along with git -p and git rebase -i) makes this a reality.
    • masklinn 14y ago
      > A single revision may not pass a set of unit tests, but the entire feature branch will before being merged into the release line I really don't care a whit about your feature branch when your broken commits mean I can't bisect an issue.
• __alexs 14y ago
  So what? Just test the commit after you've made it. You can always reset and try again before pushing.
• msbarnett 14y ago
  None of this implies committing untested code. The index is not a commit; it is a pre-commit staging area. When you use 'git add -p', you are adding hunks to the staging area, not committing them. What's the difference? When you're done staging your patch, you can then check out the staging area and run unit tests on it prior to promoting it to a commit. Doesn't compile? Tests fail? Restage as necessary.
  • Myrmornis 14y ago
    Really? I'd definitely commit before running tests. You can always use reset to redo the commit later. Branches are cheap, commits are cheap.
• tjdetwiler 14y ago
  I usually do something like: git add -p git commit git stash <run tests> If it fails then I can stash pop and commit -p --amend and try again.
  • _ikke_ 14y ago
    With stash -k you can test without committing first. Although git is very flexible regarding this, I prefer to at least test the code before committing it.
  • int3 14y ago
    `git checkout-index` allows you to run tests on the index before committing and without messing with your working tree. The only downside is that it might take a while for a large project. Example script: https://github.com/philc/vimium/blob/master/git_hooks/pre-commit https://github.com/philc/vimium/blob/master/git_hooks/pre-co...
• xyzzyb 14y ago
  When you're done, just use Bernhardt's "run-command-on-git-revisions" to run tests on each of the commits to ensure they are all working code. https://github.com/garybernhardt/dotfiles/blob/master/bin/run-command-on-git-revisions https://github.com/garybernhardt/dotfiles/blob/master/bin/ru...
• Jach 14y ago
  Nothing wrong with committing untested code, it's pushing it as a ref one can reasonably expect people will merge/fast-forward to that it becomes a problem. git add -p is a nifty workaround for the type of people who don't like the workflow of "commit early, commit often" (some people have 'save file' bound to also make a commit) but who still want to have lots of small, contained commits.
  • tomlu 14y ago
    Not a huge deal, but it can become problematic when you're using something like git bisect.
• Myrmornis 14y ago
  Committing untested code is an excellent idea. You should do it several times a day. Pushing untested code to a shared branch on a public remote is a bad idea.
• tlrobinson 14y ago
  A lot of times I use "git add -p" to cleanup code, e.x. if I added some extra logging statements I don't want to commit I can go through adding everything except the log statements, then reset everything that hasn't been added to the index.