<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@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Dave Watson Software Engineer MIMvista Corp - 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
