Re: git commit workflow question

["Shawn O. Pearce" <spearce@spearce.org>]

Brian Swetland <swetland@google.com> wrote:
> With perforce I often have a bunch of files modified (having p4 add'd
> or p4 edit'd them) and then only commit a subset of them.  I can do
> this interactively by doing a p4 submit and just removing the files
> I don't want to check in from the list in the changelist description
> when I'm writing up the change description in $EDITOR, invoked by
> p4 submit.
> 
> It seems like my options with git are to invoke git commit with
> a specific list of things to commit, invoke git commit --interactive
> and use the interactive menu thing to shuffle stuff around, or
> manually unstage things until I have the index in a state where
> a git commit without other arguments will do what I want.

Or use git-citool/git-gui to make commits, in which case that
will help you to arrange the index with what you want to commit.
But yes, git-commit does not pay any attention to modifications
made to the template in the edit buffer.

I'm not sure how the Git community would react to being able to edit
the list of files being committed from within the commit message
buffer.  I think most Git users run at least `git diff --cached`
before they commit to make sure they are happy with the difference.
I know a lot of users who do that.  Most/all of those users also do
not stage something into the index until they are happy with the
change, which means there isn't any list of files to remove when
it comes time to make the commit as the contents of the index is
exactly what should be committed.

I used p4 for a while before Git was invented.  I found the file
editing feature useful then because there was no concept of the
index.  Now with Git I've embraced the index so much that I'm not
sure I can work without it, and I don't need to remove files from
my index during the actual commit itself.
 
-- 
Shawn.