Re: git commit workflow question

[David Watson <dwatson@mimvista.com>]

<shameless plug>The Eclipse plugin (egit) actually already supports this
feature, and I use it all the time. It's incredibly handy, since I can
stag things as much as I want, and then commit then piecemeal.</shameless
plug>

However, I'm not convinced this should necessarily be included in git, at
least not by editing the commit message. Perhaps it should be a task for a
porcelain? I know you can do something similar using git-gui as
well, just by clicking on files in its top view to stage/unstage. Or like
rebase -i, where you first get a buffer with a list of stuff to be done,
and then in a separate buffer you get the commit message.

On Sat, Sep 15, 2007 at 01:31:37PM +0200, Wincent Colaiuta wrote:
>  El 14/9/2007, a las 20:14, Shawn O. Pearce escribi?:
> 
> > 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.
> 
>  Yes, I generally check what's in the index before going ahead with a commit; in 
>  fact I have the following alias in my .bash_profile so that I can just type 
>  "staged" to see what'll be in the commit, along with an "unstaged" alias for 
>  the opposite:
> 
>  alias staged='git diff --cached'
> 
>  Having said that, it would be very useful to be able to edit the list within 
>  the commit message buffer for those occasions where you realise that stuff you 
>  have staged in the index really should be two separate commits. It would enable 
>  this very simple workflow:
> 
>    1. review changes, realize that some of the changes belong in a separate 
>  commit
>    2. commit, omitting the unwanted changes
>    3. commit again, this time with the remainder of the changes
> 
>  Without the ability to edit the list within the commit message buffer your 
>  workflow becomes a bit more cumbersome:
> 
>    1. review changes, realize that some of the changes belong in a separate 
>  commit
>    2a. explicitly pass files to commit on the commandline (cumbersome if number 
>  of files is large); or:
>    2b. use git-commit --interactive (again can be relatively cumbersome); or:
>    2c. explicitly unstage unwanted files, commit, then restage them and commit
> 
>  So, yes, the proposed functionality isn't necessary by any means, but it would 
>  make some nice usability sugar. I know that in the past my experience with 
>  other SCMs that can do this has made me mistakenly believe that Git does too.
> 
>  Cheers,
>  Wincent
> 
>  -
>  To unsubscribe from this list: send the line "unsubscribe git" in
>  the body of a message to majordomo@vger.kernel.org
>  More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Dave Watson
Software Engineer
MIMvista Corp