# git-am and workflow question 7 messages from 2007-02-08 to 2007-02-11. Participants: Kumar Gala, Junio C Hamano, Jakub Narebski, Michael S. Tsirkin. Thread: https://gitlist.dev/t/6733 ## Kumar Gala, 2007-02-08 00:34 Subject: git-am and workflow question Message-ID: URL: https://gitlist.dev/e/FA0FC64E-75D2-4722-8BD9-F7E6C8C9AFA7%40kernel.crashing.org ``` I poked around the docs and mailing lists but didn't find an answer to my question some simple searches so I figured it might be easier to just post a query to the list. So my problem is that I'm applying some patches from a mbox and want to be able to do some slight modifications before actually committing the change. I was wondering how people solve this problem (if at all). thanks - kumar ``` ## Junio C Hamano, 2007-02-08 07:27 Subject: Re: git-am and workflow question Message-ID: <7vodo5153j.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vodo5153j.fsf%40assigned-by-dhcp.cox.net In-Reply-To: ``` Kumar Gala writes: > I poked around the docs and mailing lists but didn't find an answer to > my question some simple searches so I figured it might be easier to > just post a query to the list. > > So my problem is that I'm applying some patches from a mbox and want > to be able to do some slight modifications before actually committing > the change. I was wondering how people solve this problem (if at all). I am one of the two people who have been applying e-mailed patches to a repository using git for the longest time, so I am probably qualified to comment. The other person is obviously Linus, but our workflows are a bit different. Linus's first pass is to read his mails in his usual e-mail client; he saves potentially worthy patches in a separate mailbox for later review. In the second pass, he opens the saved mailbox in an editor, while fixing up bits in the commit messages and diff text. Then after making another pass for the final review, he applies them in a single batch. I tend to work more incrementally. My "first pass" is to read mails and fire off kibitzing responses without doing anything other than marking potentially worthy patches for later review. My second pass is actually applying the patch by piping each e-mail message from my e-mail client to "git am -3 -s", and if I do not like something in the patch, I make corrections and then run "git commit --amend". My final pass is "git log -p", and if I find something I want to fix, I do "git format-patch -$N" and "git reset --hard HEAD~$N", fix it up in the editor by editing the commit message and the diff text, and "git am" to rebind the branch. In short, there are two different approaches: - If a fix is something trivial, and if you are comfortable editing diff text in your editor, then edit it before applying. - If a fix is more involved, you are probably better off stopping immediately after applying the patch you want to fix up, make the fix in your working tree, and commit it with "git commit --amend". ``` ## Jakub Narebski, 2007-02-08 08:34 Subject: Re: git-am and workflow question Message-ID: URL: https://gitlist.dev/e/eqen7k%24fb5%241%40sea.gmane.org In-Reply-To: ``` [Cc: git@vger.kernel.org] Kumar Gala wrote: > I poked around the docs and mailing lists but didn't find an answer > to my question some simple searches so I figured it might be easier > to just post a query to the list. > > So my problem is that I'm applying some patches from a mbox and want > to be able to do some slight modifications before actually committing > the change. I was wondering how people solve this problem (if at all). Both git-am and git-applymbox have interactive mode, although I'm not sure how extensively interactive this mode is. -- Jakub Narebski Warsaw, Poland ShadeHawk on #git ``` ## Kumar Gala, 2007-02-08 16:07 Subject: Re: git-am and workflow question Message-ID: <9A55745B-03D2-47B3-8359-FF2D9575502E@kernel.crashing.org> URL: https://gitlist.dev/e/9A55745B-03D2-47B3-8359-FF2D9575502E%40kernel.crashing.org In-Reply-To: <7vodo5153j.fsf@assigned-by-dhcp.cox.net> ``` On Feb 8, 2007, at 1:27 AM, Junio C Hamano wrote: > Kumar Gala writes: > >> I poked around the docs and mailing lists but didn't find an >> answer to >> my question some simple searches so I figured it might be easier to >> just post a query to the list. >> >> So my problem is that I'm applying some patches from a mbox and want >> to be able to do some slight modifications before actually committing >> the change. I was wondering how people solve this problem (if at >> all). > > I am one of the two people who have been applying e-mailed > patches to a repository using git for the longest time, so I am > probably qualified to comment. The other person is obviously > Linus, but our workflows are a bit different. > > Linus's first pass is to read his mails in his usual e-mail > client; he saves potentially worthy patches in a separate > mailbox for later review. In the second pass, he opens the > saved mailbox in an editor, while fixing up bits in the commit > messages and diff text. Then after making another pass for the > final review, he applies them in a single batch. > > I tend to work more incrementally. My "first pass" is to read > mails and fire off kibitzing responses without doing anything > other than marking potentially worthy patches for later review. > My second pass is actually applying the patch by piping each > e-mail message from my e-mail client to "git am -3 -s", and if I > do not like something in the patch, I make corrections and then > run "git commit --amend". My final pass is "git log -p", and if > I find something I want to fix, I do "git format-patch -$N" and > "git reset --hard HEAD~$N", fix it up in the editor by editing > the commit message and the diff text, and "git am" to rebind the > branch. > > In short, there are two different approaches: > > - If a fix is something trivial, and if you are comfortable > editing diff text in your editor, then edit it before > applying. > > - If a fix is more involved, you are probably better off > stopping immediately after applying the patch you want to fix > up, make the fix in your working tree, and commit it with > "git commit --amend". Thanks. Have there been any thoughts on having git-am apply the patch and then let the user do some modifications before the commit? I kinda did this by hand by doing the following: git-am -i ... < suspend > patch -p1 < .dotest/patch < modify > git-diff > .dotest/patch < cleanup > < resume > - k ``` ## Junio C Hamano, 2007-02-08 22:49 Subject: Re: git-am and workflow question Message-ID: <7vveicxo23.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vveicxo23.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <9A55745B-03D2-47B3-8359-FF2D9575502E@kernel.crashing.org> ``` Kumar Gala writes: > Thanks. Have there been any thoughts on having git-am apply the patch > and then let the user do some modifications before the commit? I > kinda did this by hand by doing the following: > > git-am -i ... > < suspend > > patch -p1 < .dotest/patch > < modify > > git-diff > .dotest/patch > < cleanup > > < resume > If you are using "am -i", I think the above is already there (I mean, you should not have to do ^Z where you write ). When you get the interactive prompt: Apply? [y]es/[n]o/[e]dit/[v]iew patch/[a]ccept all I think you can edit $dotest/patch in whatever way. However, if I were to do bulk application _with_ incremental fixup (which I think is a combination that would not work very well for the way I work, though), I would probably have two windows (I work inside "screen", so I would use two screens), and run "am -i" in one and run shell in the other. Normally I would just say 'y' to the prompt, and after applying something I might want to do fixups, I would go to the shell, do fixups and "commit --amend", come back and let "am -i" to continue with the next patch. ``` ## Michael S. Tsirkin, 2007-02-10 22:18 Subject: Re: git-am and workflow question Message-ID: <20070210221852.GC32216@mellanox.co.il> URL: https://gitlist.dev/e/20070210221852.GC32216%40mellanox.co.il In-Reply-To: <7vodo5153j.fsf@assigned-by-dhcp.cox.net> ``` > My second pass is actually applying the patch by piping each > e-mail message from my e-mail client to "git am -3 -s", and if I > do not like something in the patch, I make corrections and then > run "git commit --amend". git-commit --amend seems to rewrite the commit author which is annoying if you only want to modify the log message a little. As a work-around I copy the author info from the log and passing --author explicitly, but is there an easier way? -- MST ``` ## Junio C Hamano, 2007-02-11 06:45 Subject: Re: git-am and workflow question Message-ID: <7vps8hdwf7.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vps8hdwf7.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <20070210221852.GC32216@mellanox.co.il> ``` "Michael S. Tsirkin" writes: >> My second pass is actually applying the patch by piping each >> e-mail message from my e-mail client to "git am -3 -s", and if I >> do not like something in the patch, I make corrections and then >> run "git commit --amend". > > git-commit --amend seems to rewrite the commit author which is > annoying if you only want to modify the log message a little. As a > work-around I copy the author info from the log and passing --author > explicitly, but is there an easier way? I am puzzled about this comment. You should not have to do anything funky at all. "commit --amend" changes the committer information (because you are now committing something different and at a different time from what was recorded in the original commit object), but does not touch the author information at all. We _might_ have had a bug in an ancient version but I even doubt it. ```