# How to split a big commit 6 messages from 2011-04-04 to 2011-04-05. Participants: Nguyen Thai Ngoc Duy, Ramkumar Ramachandra, Jonathan Nieder, Lasse Makholm. Thread: https://gitlist.dev/t/26986 ## Nguyen Thai Ngoc Duy, 2011-04-04 11:52 Subject: How to split a big commit Message-ID: URL: https://gitlist.dev/e/BANLkTikFXzut7fY5Tr0u-abu5Q0rMUOCmA%40mail.gmail.com ``` After a lot of small commits and a few mixed up large commits, it was too messy that I merged them all into one big commit then started spliting it into smaller, reasonable patches. Just wonder if anybody else faces the same thing and how they deal with it. I used "git reset --soft ^" and "git add -N" because there were new files, but it was clumsy. -- Duy ``` ## Ramkumar Ramachandra, 2011-04-04 13:00 Subject: Re: How to split a big commit Message-ID: <20110404130016.GA16975@kytes> URL: https://gitlist.dev/e/20110404130016.GA16975%40kytes In-Reply-To: ``` Hi Nguyen, Nguyen Thai Ngoc Duy writes: > After a lot of small commits and a few mixed up large commits, it was > too messy that I merged them all into one big commit then started > spliting it into smaller, reasonable patches. Just wonder if anybody > else faces the same thing and how they deal with it. I used "git reset > --soft ^" and "git add -N" because there were new files, > but it was clumsy. To split a big commit, I simply reverse-diff-apply the changes that I don't want in the big commit, and I stage all changes. Then, I again reverse-diff-apply all the staged changes, and keep that in the unstaged portion. Your repository should look like this now: commit bigcommit diff --git a/bigfile b/bigfile +Desirable change +Undesirable change Staged changes: diff --git a/bigfile b/bigfile -Undesirable change Unstaged changes: diff --git a/bigfile b/bigfile +Undesirable change Now simply 'commit --amend' to remove the undesirable change from the bigcommit, and commit the unstaged changes to produce a new commit. Final result: commit bigcommit diff --git a/bigfile b/bigfile +Desirable change commit newcommit diff --git a/bigfile b/bigfile +Undesirable change I can afford to do this kind of jugglery very easily because I use Magit with Emacs. After highlighting the relevant portions, reverse-diff-apply is one keystroke :) But yes, you're probably right- there should be an easier way to do this. Maybe a 'git split' that allows you to interactively select the portions of an existing commit that you'd like to exclude from the commit and turn into a new commit? Hope that helps. -- Ram ``` ## Nguyen Thai Ngoc Duy, 2011-04-04 14:25 Subject: Re: How to split a big commit Message-ID: URL: https://gitlist.dev/e/BANLkTinpiR2sHS35uqD%2BuLnTKVtimhT7eg%40mail.gmail.com In-Reply-To: <20110404130016.GA16975@kytes> ``` On Mon, Apr 4, 2011 at 8:00 PM, Ramkumar Ramachandra wrote: > To split a big commit, I simply reverse-diff-apply the changes that I > don't want in the big commit, and I stage all changes.  Then, I again > reverse-diff-apply all the staged changes, and keep that in the > unstaged portion. Won't work for me. The reverse part would be way larger than the to-commit part. > ... > I can afford to do this kind of jugglery very easily because I use > Magit with Emacs.  After highlighting the relevant portions, > reverse-diff-apply is one keystroke :) Hmm.. interesting. Never got around to actually use magit. I may have a good reason now. > But yes, you're probably right- > there should be an easier way to do this.  Maybe a 'git split' that > allows you to interactively select the portions of an existing commit > that you'd like to exclude from the commit and turn into a new commit? Hmm..yeah something like grep for chunks, then automatically splitting those chunks out would be nice. I have another use for such a tool too. When .po files are automatically updated by intltool (gnome translation helper tool), comment lines are all changed because they contain source line and those line likely change. With this tool I can filter out comment-only changes. Thanks for the idea. -- Duy ``` ## Jonathan Nieder, 2011-04-05 00:08 Subject: Re: How to split a big commit Message-ID: <20110405000852.GA1704@elie> URL: https://gitlist.dev/e/20110405000852.GA1704%40elie In-Reply-To: ``` Hi Duy, Nguyen Thai Ngoc Duy wrote: > After a lot of small commits and a few mixed up large commits, it was > too messy that I merged them all into one big commit then started > spliting it into smaller, reasonable patches. Just wonder if anybody > else faces the same thing and how they deal with it. I used "git reset > --soft ^" and "git add -N" because there were new files, > but it was clumsy. I tend to do "git reset HEAD^ -- ." and then "git add -N ." and "git add -p", for what it's worth. ``` ## Lasse Makholm, 2011-04-05 02:31 Subject: Re: How to split a big commit Message-ID: URL: https://gitlist.dev/e/BANLkTikZ_-OE1u_T%2BwGkYa3cSN0-KL-bGg%40mail.gmail.com In-Reply-To: <20110405000852.GA1704@elie> ``` On 5 April 2011 02:08, Jonathan Nieder wrote: > Hi Duy, > > Nguyen Thai Ngoc Duy wrote: > >> After a lot of small commits and a few mixed up large commits, it was >> too messy that I merged them all into one big commit then started >> spliting it into smaller, reasonable patches. Just wonder if anybody >> else faces the same thing and how they deal with it. I used "git reset >> --soft ^" and "git add -N" because there were new files, >> but it was clumsy. > > I tend to do "git reset HEAD^ -- ." and then "git add -N ." and > "git add -p", for what it's worth. In addition, after you've added some hunks, use git stash to stow away all the other changes to test each new commit seperately. /Lasse ``` ## Nguyen Thai Ngoc Duy, 2011-04-05 02:52 Subject: Re: How to split a big commit Message-ID: URL: https://gitlist.dev/e/BANLkTim5j8cezy8jhs9dqPXYJRkRGf0GMA%40mail.gmail.com In-Reply-To: <20110405000852.GA1704@elie> ``` On Tue, Apr 5, 2011 at 7:08 AM, Jonathan Nieder wrote: > Hi Duy, > > Nguyen Thai Ngoc Duy wrote: > >> After a lot of small commits and a few mixed up large commits, it was >> too messy that I merged them all into one big commit then started >> spliting it into smaller, reasonable patches. Just wonder if anybody >> else faces the same thing and how they deal with it. I used "git reset >> --soft ^" and "git add -N" because there were new files, >> but it was clumsy. > > I tend to do "git reset HEAD^ -- ." and then "git add -N ." and > "git add -p", for what it's worth. But you would need to undo "git add -N" for those files you don't want in yet? -- Duy ```