Dnia niedziela 25. maja 2008 10:49, Dennis Schridde napisał:
> Am Samstag, 24. Mai 2008 14:33:42 schrieb Jakub Narebski:
>> Dnia sobota 24. maja 2008 11:13, Dennis Schridde napisał:
>>> Am Samstag, 24. Mai 2008 03:30:43 schrieb Jakub Narebski:
>>>> Dennis Schridde <devurandom@xxxxxxx> writes:
>>>>>
>>>>> 2) Can I make format-patch include the full commit message, date,
>>>>> author, stats in the patches? (To mimic what git-show would show me.)
>>>>> Will this be sent via send-email, too?
>>>>
>>>> Errr... git-format-patch output _does_ include full commit message,
>>>> author, author date and diffstat.
>>>
>>> For me only the first line of the commit message is printed in the
>>> subject, all other lines are missing.
>>
>> What version of git do you use? If I remember correctly this area
>> was worked on some time ago, so git-format-patch takes now whole first
>> paragraph as a subject of email, folding it using appropriate RFC
>> style.
It does, and does not help, see below for details.
> Then that multiline subject must have been lost somewhere along the way. Maybe
> some mailserver in between striped it down to one line...
Actually, after some testing it looks like while git-format-patch
generates correct patches for commit messages which do not follow
git convention of single line summary followed (optionally) by longer
description and (optionally) signoff, git-am doesn't correctly apply
them.
It is easy to understand why it is this way: git-format-patch uses
RFC 2822 (I think) folding of mail headers, so the subject looks like
below:
Subject: <prefix> <first line of commit message> LF
SP <second line of commit message> ...
where <prefix> is for example "[PATCH]" or "[PATCH m/n]". Now git-am
doesn't know if the patch was generated by git-format-patch, or does
it have subject line wrapped by MUA / MTA as to, for example, do not
cross line length limit for email headers.
Now git-rebase, which by default in non-interactive mode uses
git-format-patch | git-am pipeline, _doesn't_ munge commit messages,
even if they do not follow git commit message convention.
It does it by using undocumented (at least not mentioned in git-am(1)
manpage, even if it is shown in "git am -h" output (long usage)) option
to git-am, namely '--rebasing'. Unfortunately, at least if you want
to apply patches send by email, it imples '--keep', so
"git am --rebasing" won't strip "[PATCH]" or "[PATCH m/n]" prefix.
>>> If I want a message to appear in the body at all, I need a special way to
>>> format my commit messages: 1 line summary, 1 empty line, description.
>>> Only the description is then shown in the email.
>>> This seems inconvenient, especially for smaller changes.
>>
>> What do you think this commit message convention git uses is from?
>> It stems from exchanging patches by email, where you had to put short,
>> single line description in the email subject, and describe change in
>> more detail in message (email) body. If you don't follow this
>> commit message convention many git tools (tig, gitk, git-shortlog, etc.)
>> will not work as expected.
>>
> I guess this is then a feature request?
> To use first line for subject, and repeat the whole commit-message in the
> body?
IIRC you can always repeat "Subject:" in the body of email, and it
would be used as first line (first paragraph with '--rebasing', see
above) of commit message instead of _email_ subject.
>>> Further, attachments do not at all contain any information like that.
>>> See the attached example.
>>
>> Errr... I just tried "git format-patch --attach"[1] and it creates by
>> default multi-part attachement, first part is commit message, second
>> is patch itself. The commit message contains diffstat.
>>
> I wanted to know whether I could make that 2nd part ("patch itself") also
> contain the whole commit message, date, author (so it looks like what
> git-show gives me).
I don't see why not. You can easy distinguish old format (with first
line / first paragraph given by subject of email) from new format (with
whole commit message as first MIME-attachement part) by the fact that
old format part begins with an empty line... well, beside the fact that
you would have be careful and use old format for commit messages which
begins with empty line (git-commit wouldn't create such messages, so
they have to come for example from misconversion from other SCM).
I have CC-ed Dscho and Mike McCormack, authors of --attach option to
git-format-patch.
>>>>> 4) Can I make format-patch output one deletion and one insertion for a
>>>>> complete rewrite of a function, instead of multiple deletes/inserts?
>>>>
>>>> Try git-format-patch with -B option, or -B<num>.
>>>
>>> I tried that already. Whether I specified -B or not, it always gave
>>> the exact same output (says diff).
>>
>> Ah, I'm sorry. The -B is to recognize total rewrite, i.e. such a change
>> that is best represent as delete old contents and create new one.
>>
> Total rewrite of a file? So not appropriate for the total rewrite of just a
> function?
It is not.
But if I remember correctly some time ago either Linus or Junio
modified diff output to concatenate chunks if they are separated by
less than 2*context+2 lines, or something like that. Unfortunately
I cannot find either thread on git mailing list, or commit adding this
feature...
--
Jakub Narebski
Poland
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
