Re: splitting a commit that adds new files
Jeff King p...@peff.net writes: [1] I _do_ use reset -p when splitting commits, but I do not think it is useful here. I use it for oops, I staged this change, but it actually belongs in the next commit. Undo my staging, but leave the changes in the working tree for the next one. Sure. I thought that was exactly what Duy was attempting to do when he splitted a commit into two (or more). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: splitting a commit that adds new files
On Tue, Feb 4, 2014 at 1:11 AM, Junio C Hamano gits...@pobox.com wrote: Jeff King p...@peff.net writes: [1] I _do_ use reset -p when splitting commits, but I do not think it is useful here. I use it for oops, I staged this change, but it actually belongs in the next commit. Undo my staging, but leave the changes in the working tree for the next one. Sure. I thought that was exactly what Duy was attempting to do when he splitted a commit into two (or more). For splitting into two commits, reset -p or reset @^; add -p would be more or less the same, although I still prefer to think this is what I need than this is what I do _not_ need. add -p is more convenient when the commit is big and you need to split into more than two because the number of revert chunks may be higher than the number of added chunks. I recall editing a patch with checkout -p sometimes does not work, not sure it happens with reset -p too. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: splitting a commit that adds new files
Duy Nguyen pclo...@gmail.com writes: I usually start splitting a commit with reset @^ then add -p back. The problem is reset @^ does not keep track of new files added in HEAD, so I often end up forgetting to add new files back (with add -p). I'm thinking of making reset to do add -N automatically for me so I won't miss changes in add -p. But maybe people already know how to deal with this case without adding more code? Is reset -p what you are looking for? I do not use that myself, though. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: splitting a commit that adds new files
On Sun, Feb 02, 2014 at 10:15:07AM -0800, Junio C Hamano wrote: Duy Nguyen pclo...@gmail.com writes: I usually start splitting a commit with reset @^ then add -p back. The problem is reset @^ does not keep track of new files added in HEAD, so I often end up forgetting to add new files back (with add -p). I'm thinking of making reset to do add -N automatically for me so I won't miss changes in add -p. But maybe people already know how to deal with this case without adding more code? Is reset -p what you are looking for? I do not use that myself, though. I don't think so. He is at a commit that needs split, so the first thing to do is to shift the HEAD back. reset -p is only about changing the index[1]. I suppose you could start with a soft reset, and then reset -p away the changes. But then you are going backwards (this does not belong in the commit, remove it rather than this does belong in the commit, add it). I don't typically have a problem with this because I keep my directory free of untracked files (they are either marked by .gitignore, or something that I am planning to commit). So just running git status gives me a neat list of what needs to be added (and typically git add -N . is a good starting point upon which to build a git add -p session). -Peff [1] I _do_ use reset -p when splitting commits, but I do not think it is useful here. I use it for oops, I staged this change, but it actually belongs in the next commit. Undo my staging, but leave the changes in the working tree for the next one. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
