git-am and workflow question

git-am and workflow question

[Kumar Gala]

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

Re: git-am and workflow question

[Junio C Hamano]

Kumar Gala <galak@kernel.crashing.org> 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".

Re: git-am and workflow question

[Jakub Narebski]

[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

Re: git-am and workflow question

[Kumar Gala]

On Feb 8, 2007, at 1:27 AM, Junio C Hamano wrote:

> Kumar Gala <galak@kernel.crashing.org> 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

Re: git-am and workflow question

[Junio C Hamano]

Kumar Gala <galak@kernel.crashing.org> 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 <suspend>).
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.

Re: git-am and workflow question

[Michael S. Tsirkin]

> 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

Re: git-am and workflow question

[Junio C Hamano]

"Michael S. Tsirkin" <mst@mellanox.co.il> 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.