git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: git commit workflow question

From
DWDavid Watson <dwatson@mimvista.com>
Date
Sep 15, 2007, 12:07 UTC
Message-ID
<20070915120750.GA21968@mimvista.com>
In-Reply-To
<BCFC81AB-0EDD-4C3C-B7D4-DEC60E2565C3@wincent.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:
Show 46 quoted lines
>  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
Previous: Wincent Colaiuta
Message 3 of 3 in “Re: git commit workflow question”
  1. Shawn O. PearceSep 14, 2007
  2. Wincent ColaiutaSep 15, 2007
  3. David WatsonSep 15, 2007

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.