4

How do I suppress the "Changes not staged for commit" output when committing? Note that:

  • I know I can do > /dev/null, but I'm hoping not to suppress other things.
  • I'm not talking about the commit message -- I'm talking about what its printed to the terminal.
user541686
  • 205,094
  • 128
  • 528
  • 886
  • You are asking about the default commit message that is displayed? – Andrew C Nov 28 '15 at 21:06
  • Why bother? It's just an information about files changed but not included into the commit. It's useful when you prepare a series of commits from a given changed worktree. – user3159253 Nov 28 '15 at 21:12
  • @user3159253: Just because you might find it useful doesn't mean I do... – user541686 Nov 28 '15 at 21:16
  • 1
    take a look at REPO/.git/hooks/prepare-commit-msg.sample, they have an example which shows how to comment out the 'conflicts' section that could be adapted – Andrew C Nov 28 '15 at 21:18
  • Possible duplicate of [How can I change the default comments in the git commit message?](http://stackoverflow.com/questions/3966714/how-can-i-change-the-default-comments-in-the-git-commit-message) – bperson Nov 28 '15 at 22:40
  • @ddr2: Not a duplicate, see my edit. – user541686 Nov 29 '15 at 00:23
  • 1
    this is confusing. What's that output ? Can you give us an example ? Except from the one commented-out in the default commit message (if you enter a commit message via an editor) ... the only other one I can think of is in `git status` which is a completely different matter ? – bperson Nov 29 '15 at 00:28
  • If you're not using an editor, you will get something like `[master 436246b] test 1 file changed, 1 insertion(+)` as output from commiting, so nothing containing "changes not staged for commit" ;) – bperson Nov 29 '15 at 00:29
  • 1
    @ddr2: Sorry it's confusing, I encounter it when I try to commit with no files added. (It's part of a script, obviously not something I would do by hand.) – user541686 Nov 29 '15 at 00:47
  • so I've been checking a bit the git.git code, a funny solution could be to use --allow-empty, allowing the creation of empty commits so you never see that message ;) – bperson Nov 29 '15 at 01:12
  • @ddr2: Yeah but I don't want that haha. – user541686 Nov 29 '15 at 01:26

1 Answers1

1

After a bit of digging in the git.git codebase, I am afraid you should be designing a way to ignore those lines in your script.

During a commit, if you don't use --allow-empty, git will go through that code:

if (!commitable && whence != FROM_MERGE && !allow_empty &&
    !(amend && is_a_merge(current_head))) {
    s->display_comment_prefix = old_display_comment_prefix;
    run_status(stdout, index_file, prefix, 0, s);
    ...
    return 0;
}

And run_status does the following thing:

switch (status_format) {
    case STATUS_FORMAT_SHORT:
        wt_shortstatus_print(s);
        break;
    case STATUS_FORMAT_PORCELAIN:
        wt_porcelain_print(s);
        break;
    case STATUS_FORMAT_UNSPECIFIED:
        die("BUG: finalize_deferred_config() should have been called");
        break;
    case STATUS_FORMAT_NONE:
    case STATUS_FORMAT_LONG:
        wt_status_print(s);
        break;
    }
}

STATUS_FORMAT_PORCELAIN (use --porcelain) and STATUS_FORMAT_SHORT (git config status.short true) will result in the same minified output:

 M bla.txt

and STATUS_FORMAT_LONG (AND STATUS_FORMAT_NONE, not sure why ?), will result in the usual output:

Changes not staged for commit:
    modified:   bla.txt

That said, let's not despair, this is software we're talking about, there is always a way around the problem (I still need to completely test this though ;) )

You could use --allow-empty to get pass that code branch and create an empty commit. Then, you chain that with a post-commit hook that checks whether the latest commit is empty, if it is, the hook runs git reset --hard HEAD~1 and you could be good to go ?

bperson
  • 1,285
  • 10
  • 19