Multiple user questions

Multiple user questions

[Dennis Schridde]

[-- Attachment #1: Type: text/plain, Size: 801 bytes --]

Hello!

I have some questions regarding the usage of Git, I did not find answered in 
manpages or on IRC:

1) Can I somehow make send-email just send one email with multiple patches 
attached?
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?
3) Can I make format-patch --attach / --inline additionaly include this in the 
attachements as well?
4) Can I make format-patch output one deletion and one insertion for a 
complete rewrite of a function, instead of multiple deletes/inserts?
5) If rebase -i does not keep at least one valid line, it will "do nothing" 
(instead of deleting all revisions). Is that intended? Why?

Thanks for your answers,
Dennis

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Multiple user questions

[Dennis Schridde]

[-- Attachment #1: Type: text/plain, Size: 917 bytes --]

Am Freitag, 23. Mai 2008 13:27:37 schrieb Dennis Schridde:
> Hello!
>
> I have some questions regarding the usage of Git, I did not find answered
> in manpages or on IRC:
>
> 1) Can I somehow make send-email just send one email with multiple patches
> attached?
> 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?
> 3) Can I make format-patch --attach / --inline additionaly include this in
> the attachements as well?
> 4) Can I make format-patch output one deletion and one insertion for a
> complete rewrite of a function, instead of multiple deletes/inserts?
> 5) If rebase -i does not keep at least one valid line, it will "do nothing"
> (instead of deleting all revisions). Is that intended? Why?
>
> Thanks for your answers,
> Dennis
PS: Please CC me, because I am not subscribed.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Multiple user questions

[Jakub Narebski]

Dennis Schridde <devurandom@gmx.net> writes:

> 1) Can I somehow make send-email just send one email with multiple patches 
> attached?

This way you cannot reply to each patch separately in an easy way.
Thats what "[PATCH n/m]" and threading/chaining to cover letter is
for.

> 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.

git-send-email can send fir-format-patch patches (and usually is used
in such way).

> 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>.

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: Multiple user questions

[Dennis Schridde]

[-- Attachment #1.1: Type: text/plain, Size: 1826 bytes --]

Thanks for your answers!

Am Samstag, 24. Mai 2008 03:30:43 schrieb Jakub Narebski:
> Dennis Schridde <devurandom@gmx.net> 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.
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.

Further, attachments do not at all contain any information like that.
See the attached example.

> > 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).

The <num> parameter to -B is not mentioned or explained in the manpages.

5) fsck --full --lost-found shows me a lot of "dangling commit". I would like 
to clean them up. prune did only remove "dangling tree" and blobs.
(Reason: Last time I droped a stash accidently, I was able to find it in that 
list. I will not be able to do this again if it continues to grow at that 
rate.)
How can I do that?
Further fsck --full --unreachable also shows a lot of unreachable things 
(commits, trees, blobs). Can that be cleaned up as well?

Greetings,
Dennis

Again: Please CC me, as I am not subscribed.

[-- Attachment #1.2: 5b7f87a087d7372b04fd81202191a3d8cb818bab.diff --]
[-- Type: text/x-diff, Size: 1190 bytes --]

diff --git a/src/projectile.c b/src/projectile.c
index 1389d4c..f9ae99a 100644
--- a/src/projectile.c
+++ b/src/projectile.c
@@ -640,8 +640,8 @@ static void proj_InFlightDirectFunc( PROJECTILE *psProj )
 	/* we want a delay between Las-Sats firing and actually hitting in multiPlayer
 	magic number but that's how long the audio countdown message lasts! */
 	const unsigned int LAS_SAT_DELAY = 8;
-	unsigned int timeSoFar;
-	unsigned int distancePercent; /* How far we are 0..100 */
+	int timeSoFar;
+	int distancePercent; /* How far we are 0..100 */
 	float distanceRatio; /* How far we are, 1.0==at target */
 	float distanceExtensionFactor; /* Extended lifespan */
 	Vector3i move;
@@ -909,8 +909,8 @@ static void proj_InFlightIndirectFunc( PROJECTILE *psProj )
 		- Some optimisations by leaving out tests which are never true (homing, AA, counter-missile, lassat)
 	*/
 
-	unsigned int timeSoFar;
-	unsigned int distancePercent; /* How far we are 0..100 */
+	int timeSoFar;
+	int distancePercent; /* How far we are 0..100 */
 	float distanceRatio; /* How far we are, 1.0==at target */
 	float distanceExtensionFactor; /* Extended lifespan */
 	Vector3i move;

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Multiple user questions

[Jakub Narebski]

Dnia sobota 24. maja 2008 11:13, Dennis Schridde napisał:
> Thanks for your answers!

You are welcome.
 
> Am Samstag, 24. Mai 2008 03:30:43 schrieb Jakub Narebski:
>> Dennis Schridde <devurandom@gmx.net> 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.

Note though that git-am migh convert this first paragraph to single
line, losing formatting in the progress.  I think there is some option
to preserve formatting.

> 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.

> 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.

This is if I remember correctly quite new thing, so it might need
some polishing.

[1] I use git version 1.5.5

>>> 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.

If I remember correctly there was some work lately, I think by Linus,
to join together neighbour chunks to make diff more readable.  But
I think there were no configurable parameters... I also don't remember
if it hit released version...

> The <num> parameter to -B is not mentioned or explained in the manpages.

It is explained in diffcore, which in future version of git would be
in manpage, and not only as HTML / text documentation.

-- 
Jakub Narebski
Poland

Re: Multiple user questions

[Dennis Schridde]

[-- Attachment #1: Type: text/plain, Size: 2939 bytes --]

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@gmx.net> 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.
Then that multiline subject must have been lost somewhere along the way. Maybe 
some mailserver in between striped it down to one line...

> > 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?

> > 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).

> [1] I use git version 1.5.5
I use 1.5.5.1

> >>> 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?

--Dennis

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Multiple user questions

[Jakub Narebski]

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@gmx.net> 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

Re: Multiple user questions

[Dennis Schridde]

[-- Attachment #1: Type: text/plain, Size: 754 bytes --]

I just ran into a lost stash again and thus would like to get an answer to 
this question, which was forgotten last time:
(lost-found is really growing in a pace it will take me very long to find my 
lost stash.)

5) fsck --full --lost-found shows me a lot of "dangling commit". I would like 
to clean them up. prune did only remove "dangling tree" and blobs.
(Reason: Last time I droped a stash accidently, I was able to find it in that 
list. I will not be able to do this again if it continues to grow at that 
rate.)
How can I do that?
Further fsck --full --unreachable also shows a lot of unreachable things 
(commits, trees, blobs). Can that be cleaned up as well?

Greetings,
Dennis

Again: Please CC me, as I am not subscribed.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Multiple user questions

[Brandon Casey]

Dennis Schridde wrote:
> I just ran into a lost stash again and thus would like to get an answer to 
> this question, which was forgotten last time:
> (lost-found is really growing in a pace it will take me very long to find my 
> lost stash.)

How did you lose it?

If you did 'git stash drop' and then realized that you dropped the wrong stash,
you can apply that stash and then recreate it since 'stash drop' also prints out
the sha1 and 'stash apply' can use that.

For example:

   # edit edit edit
   $ git stash
   # hmm I don't need that old stash anymore
   $ git stash drop
   Dropped refs/stash@{0} (5dcea62df980fa157e7755f82125dfc3bbd52ff5)
   # whoops I didn't mean to drop _that_ stash
   $ git stash apply 5dcea62df980fa157e7755f82125dfc3bbd52ff5
   $ git stash

Of course, that only works if you realize pretty quickly that you dropped the
wrong stash. Also realize my example was rather simplified and the working
directory may need to be prepped before reapplying the dropped stash.

-brandon

Re: Multiple user questions

[Dennis Schridde]

[-- Attachment #1: Type: text/plain, Size: 1719 bytes --]

Am Freitag, 6. Juni 2008 23:19:49 schrieben Sie:
> Dennis Schridde wrote:
> > I just ran into a lost stash again and thus would like to get an answer
> > to this question, which was forgotten last time:
> > (lost-found is really growing in a pace it will take me very long to find
> > my lost stash.)
>
> How did you lose it?
>
> If you did 'git stash drop' and then realized that you dropped the wrong
> stash, you can apply that stash and then recreate it since 'stash drop'
> also prints out the sha1 and 'stash apply' can use that.
>
> For example:
>
>    # edit edit edit
>    $ git stash
>    # hmm I don't need that old stash anymore
>    $ git stash drop
>    Dropped refs/stash@{0} (5dcea62df980fa157e7755f82125dfc3bbd52ff5)
>    # whoops I didn't mean to drop _that_ stash
>    $ git stash apply 5dcea62df980fa157e7755f82125dfc3bbd52ff5
>    $ git stash
>
> Of course, that only works if you realize pretty quickly that you dropped
> the wrong stash. Also realize my example was rather simplified and the
> working directory may need to be prepped before reapplying the dropped
> stash.
It was indeed too late. (I assumed to have rerecorded the stash, but later 
realised that the new stash contained only parts of the changes.)

I am now using this script:
for commit in $(git fsck --full --lost-found | grep commit | awk '{print 
$3}') ; do
        git show ${commit} | head -n7 | \
                grep "On ${branch}:" | grep "${message}" > /dev/null \
                && git show ${commit} | head -n7
done

Though that list grows pretty long, so I would like to cut down the output of 
fsck-lost-found after I am sure nothing worthy is "lost" anymore.

--Dennis

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]