{"thread":{"id":"9840","subject":"Re: git commit workflow question","startedAt":"2007-09-14T18:14:17Z","lastAt":"2007-09-15T12:07:51Z","messageCount":3,"participants":["Shawn O. Pearce","Wincent Colaiuta","David Watson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"53042","messageId":"20070914181417.GU3099@spearce.org","threadId":"9840","inReplyTo":"20070914103348.GA22621@bulgaria","subject":"Re: git commit workflow question","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-09-14T18:14:17Z","receivedAt":"2007-09-14T18:14:17Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Brian Swetland wrote:\n> With perforce I often have a bunch of files modified (having p4 add'd\n> or p4 edit'd them) and then only commit a subset of them. I can do\n> this interactively by doing a p4 submit and just removing the files\n> I don't want to check in from the list in the changelist description\n> when I'm writing up the change description in $EDITOR, invoked by\n> p4 submit.\n> \n> It seems like my options with git are to invoke git commit with\n> a specific list of things to commit, invoke git commit --interactive\n> and use the interactive menu thing to shuffle stuff around, or\n> manually unstage things until I have the index in a state where\n> a git commit without other arguments will do what I want.\n\nOr use git-citool/git-gui to make commits, in which case that\nwill help you to arrange the index with what you want to commit.\nBut yes, git-commit does not pay any attention to modifications\nmade to the template in the edit buffer.\n\nI'm not sure how the Git community would react to being able to edit\nthe list of files being committed from within the commit message\nbuffer. I think most Git users run at least `git diff --cached`\nbefore they commit to make sure they are happy with the difference.\nI know a lot of users who do that. Most/all of those users also do\nnot stage something into the index until they are happy with the\nchange, which means there isn't any list of files to remove when\nit comes time to make the commit as the contents of the index is\nexactly what should be committed.\n\nI used p4 for a while before Git was invented. I found the file\nediting feature useful then because there was no concept of the\nindex. Now with Git I've embraced the index so much that I'm not\nsure I can work without it, and I don't need to remove files from\nmy index during the actual commit itself.\n \n-- \nShawn.\n"},{"id":"53108","messageId":"BCFC81AB-0EDD-4C3C-B7D4-DEC60E2565C3@wincent.com","threadId":"9840","inReplyTo":"20070914181417.GU3099@spearce.org","subject":"Re: git commit workflow question","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2007-09-15T11:31:37Z","receivedAt":"2007-09-15T11:31:37Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 14/9/2007, a las 20:14, Shawn O. Pearce escribió:\n\n> I'm not sure how the Git community would react to being able to edit\n> the list of files being committed from within the commit message\n> buffer. I think most Git users run at least `git diff --cached`\n> before they commit to make sure they are happy with the difference.\n> I know a lot of users who do that.\n\nYes, I generally check what's in the index before going ahead with a \ncommit; in fact I have the following alias in my .bash_profile so \nthat I can just type \"staged\" to see what'll be in the commit, along \nwith an \"unstaged\" alias for the opposite:\n\nalias staged='git diff --cached'\n\nHaving said that, it would be very useful to be able to edit the list \nwithin the commit message buffer for those occasions where you \nrealise that stuff you have staged in the index really should be two \nseparate commits. It would enable this very simple workflow:\n\n 1. review changes, realize that some of the changes belong in a \nseparate commit\n 2. commit, omitting the unwanted changes\n 3. commit again, this time with the remainder of the changes\n\nWithout the ability to edit the list within the commit message buffer \nyour workflow becomes a bit more cumbersome:\n\n 1. review changes, realize that some of the changes belong in a \nseparate commit\n 2a. explicitly pass files to commit on the commandline (cumbersome \nif number of files is large); or:\n 2b. use git-commit --interactive (again can be relatively \ncumbersome); or:\n 2c. explicitly unstage unwanted files, commit, then restage them \nand commit\n\nSo, yes, the proposed functionality isn't necessary by any means, but \nit would make some nice usability sugar. I know that in the past my \nexperience with other SCMs that can do this has made me mistakenly \nbelieve that Git does too.\n\nCheers,\nWincent\n"},{"id":"53110","messageId":"20070915120750.GA21968@mimvista.com","threadId":"9840","inReplyTo":"BCFC81AB-0EDD-4C3C-B7D4-DEC60E2565C3@wincent.com","subject":"Re: git commit workflow question","fromName":"David Watson","fromEmail":"dwatson@mimvista.com","sentAt":"2007-09-15T12:07:51Z","receivedAt":"2007-09-15T12:07:51Z","isPatch":false,"sender":{"key":"dwatson@mimvista.com","avatar":null},"body":"The Eclipse plugin (egit) actually already supports this\nfeature, and I use it all the time. It's incredibly handy, since I can\nstag things as much as I want, and then commit then piecemeal.\n\nHowever, I'm not convinced this should necessarily be included in git, at\nleast not by editing the commit message. Perhaps it should be a task for a\nporcelain? I know you can do something similar using git-gui as\nwell, just by clicking on files in its top view to stage/unstage. Or like\nrebase -i, where you first get a buffer with a list of stuff to be done,\nand then in a separate buffer you get the commit message.\n\nOn Sat, Sep 15, 2007 at 01:31:37PM +0200, Wincent Colaiuta wrote:\n> El 14/9/2007, a las 20:14, Shawn O. Pearce escribi?:\n> \n> > I'm not sure how the Git community would react to being able to edit\n> > the list of files being committed from within the commit message\n> > buffer. I think most Git users run at least `git diff --cached`\n> > before they commit to make sure they are happy with the difference.\n> > I know a lot of users who do that.\n> \n> Yes, I generally check what's in the index before going ahead with a commit; in \n> fact I have the following alias in my .bash_profile so that I can just type \n> \"staged\" to see what'll be in the commit, along with an \"unstaged\" alias for \n> the opposite:\n> \n> alias staged='git diff --cached'\n> \n> Having said that, it would be very useful to be able to edit the list within \n> the commit message buffer for those occasions where you realise that stuff you \n> have staged in the index really should be two separate commits. It would enable \n> this very simple workflow:\n> \n> 1. review changes, realize that some of the changes belong in a separate \n> commit\n> 2. commit, omitting the unwanted changes\n> 3. commit again, this time with the remainder of the changes\n> \n> Without the ability to edit the list within the commit message buffer your \n> workflow becomes a bit more cumbersome:\n> \n> 1. review changes, realize that some of the changes belong in a separate \n> commit\n> 2a. explicitly pass files to commit on the commandline (cumbersome if number \n> of files is large); or:\n> 2b. use git-commit --interactive (again can be relatively cumbersome); or:\n> 2c. explicitly unstage unwanted files, commit, then restage them and commit\n> \n> So, yes, the proposed functionality isn't necessary by any means, but it would \n> make some nice usability sugar. I know that in the past my experience with \n> other SCMs that can do this has made me mistakenly believe that Git does too.\n> \n> Cheers,\n> Wincent\n> \n> -\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n\n-- \nDave Watson\nSoftware Engineer\nMIMvista Corp\n"}]}