Re: git-feed-mail-list.sh

David Woodhouse [off-list ref] writes:

# $FROM specifies the From: header used in the mails. It'll default
# to GIT_COMMITTER_EMAIL if that exists, or to `whoami`@`hostname`

I am not sure if this part is tested..

# Unless configured otherwise, just cat it instead of mailing.
if [ -z "$FROM" ]; then
    if [ -z "$GIT_COMMITTER_EMAIL" ]; then 
	FROM="$GIT_COMMITTER_EMAIL"
    else
	FROM=`whoami`@`hostname`
    fi
fi

Maybe you meant 'if test -n "$GIT_COMMITTER_EMAIL"' here?

# takes an object and generates the object's parent(s)
createmail () {
    local commit

If you were to do bashism local, don't you want to also localize
other variables like key, SUBHEX, NEWSUB,...?

It may make sense to enhance format-patch to do the Q encoding,
so that you do not have to do this part by hand...

	git-diff -B $parent $commit > $TMPCM
	diffstat -p1 $TMPCM 2>/dev/null

With GIT 1.3.0 and later:

	git diff --patch-with-stat $parent..$commit

would be simpler here.

base=$(git-rev-parse $1)

if [ -z $2 ]; then
    lastmail=`cat $MAILTAG`
else
    lastmail=$(git-rev-parse $2)
fi

lastmail=`git rev-parse --default "$MAILTAG" ${2+"$2"}`

if [ -z $1 ]; then
    base=$(git-rev-parse HEAD) || exit 1
else
    base=$(git-rev-parse $1) || exit 1
fi

I am not sure if earlier base=$(git-rev-parse $1) is needed if
you do this here...

On Wed, 2006-05-03 at 21:35 -0700, Junio C Hamano wrote:

If you were to do bashism local, don't you want to also localize
other variables like key, SUBHEX, NEWSUB,...?

It may make sense to enhance format-patch to do the Q encoding,
so that you do not have to do this part by hand... 

Yes, that would be useful. We should perhaps to the From: and To:
headers too. Here's my current version (thanks for the feedback)...

The remaining problem is that the invocation of 'date' doesn't work with
new versions of coreutils. This...

   date=(${rest#*> })
   sec=${date[0]}; tz=${date[1]}
   dtz=${tz/+/+ }; dtz=${dtz/-/- }
   pdate="$(date -Rud "1970-01-01 UTC + $sec sec $dtz" 2>/dev/null)"

... doesn't work any more on FC-5, because:

 $ date -Rud '1970-01-01 UTC + 1147104611 sec + 0100'
date: invalid date `1970-01-01 UTC + 1147104611 sec + 0100'

-- 
dwmw2

On Tue, 9 May 2006, David Woodhouse wrote:

The remaining problem is that the invocation of 'date' doesn't work with
new versions of coreutils. This...

   date=(${rest#*> })
   sec=${date[0]}; tz=${date[1]}
   dtz=${tz/+/+ }; dtz=${dtz/-/- }
   pdate="$(date -Rud "1970-01-01 UTC + $sec sec $dtz" 2>/dev/null)"

... doesn't work any more on FC-5, because:

Well, you might choose to just not use "git-cat-file commit" but instead 
ask git to format the thing for you.

Ie you could probably more easily parse the data from something like

	git show -B --patch-with-stat --pretty=fuller $commit

instead of using "git-cat-file commit $commit" and generating the stat and 
diff manually.

That way you get the dates etc pretty-printed for you by git.

			Linus

On Mon, 2006-05-08 at 17:19 -0700, Linus Torvalds wrote:

Well, you might choose to just not use "git-cat-file commit" but instead 
ask git to format the thing for you.

Ie you could probably more easily parse the data from something like

	git show -B --patch-with-stat --pretty=fuller $commit

instead of using "git-cat-file commit $commit" and generating the stat and 
diff manually.

That way you get the dates etc pretty-printed for you by git.

Aha, thanks. Git has learned to do a lot more since I first started
hacking up a copy of git-log.sh to feed the mailing lists, and it even
had to walk the commit tree manually :)

The output of (the undocumented) '--pretty=fuller' is probably good
enough that I can just feed the mailing list with it directly. I think I
have to add the commit and the parent manually, but that's easy enough
to do -- the commit is obviously known, and the parent is just
$(git-rev-parse $commit^1).

Anyone got any objections to switching the kernel git-commits-* lists to
this format?

-- 
dwmw2

On Tue, 9 May 2006, David Woodhouse wrote:

Anyone got any objections to switching the kernel git-commits-* lists to
this format?

As long as the "commit <sha1>" id is there (and "--pretty=fuller" does 
have it), I'll be happy. At some point, the commit mailing list didn't 
actually mention the commit ID itself, just the tree/parent IDs.

The "fuller" format should be fine, if you care about committer. Otherwise 
just use the standard "--pretty", which drops committer info.

		Linus

On 5/9/06, Linus Torvalds [off-list ref] wrote:

Ie you could probably more easily parse the data from something like

        git show -B --patch-with-stat --pretty=fuller $commit

Is there a way to track merge like that ? Documentation is not very
clear and near from empty.

--
Beber
#e.fr@freenode

On Mon, 2006-05-08 at 17:45 -0700, Linus Torvalds wrote:

As long as the "commit <sha1>" id is there (and "--pretty=fuller" does 
have it), I'll be happy.

Ah, right. Those are _commit_ IDs in that strange first line. I'll
reformat those to 'Commit:' and 'Parent:' for the mailing list.

Having 'git-show --pretty=email' would be nice. I think Junio is working
on something which will achieve that, right?

 At some point, the commit mailing list didn't 
actually mention the commit ID itself, just the tree/parent IDs.

Yeah, I know -- and I got complaints :)

-- 
dwmw2

On Tue, 9 May 2006, Bertrand Jacquin wrote:

On 5/9/06, Linus Torvalds [off-list ref] wrote:

quoted

Ie you could probably more easily parse the data from something like

        git show -B --patch-with-stat --pretty=fuller $commit

Is there a way to track merge like that ? Documentation is not very
clear and near from empty.

Sure.

If you want to track merges and get their patches, add the "--cc" flag, 
which tells git to use the "conflict combination patch" that shows any 
visible conflicts.

(NOTE NOTE NOTE! This is _not_ the same as showing what conflicted: if you 
edited the result to match one of the original branches, it will be quiet 
in --cc, but if the result of a conflict was something that was in 
_neither_ branch, it will be shown! So most clean merges will not show any 
conflict diff at all, but the diffstat will be shown against the "first 
parent").

And you probably don't want to abbreviate the parent commit SHA1's (which 
are shown for merges, but not regular commits), so add "--no-abbrev".

If you want to show parents for _all_ commits, you could do something like

  git show --no-abbrev --cc -C --patch-with-stat --pretty=fuller --parents |
	sed '1 s/commit [0-9a-f]*/\0\nParents:   / ; /^Merge: / d'

which removes a potential "Merge: " line in favour of listing the parents 
on a "Parents:" line, and which also shows merges nicely.

That said, the diffstat for merges is usually just a lot of noise. It's 
sometimes nice (you've merged from a topic branch), but if you have merged 
from the mainline _into_ a topic branch, it's just annoying.

So the above is just a wild suggestion. Caveat emptor.

		Linus

On Tue, 9 May 2006, David Woodhouse wrote:

Ah, right. Those are _commit_ IDs in that strange first line. I'll
reformat those to 'Commit:' and 'Parent:' for the mailing list.

Right. That first line (that starts with "commit") lists the commit ID, 
and if you say "--parents", the commit ID's of the parents will be 
appended.

So if you want to turn that into "Commit: <id>" and "Parent: <id>", you'll 
want to do something like this:

  git show --no-abbrev -C --patch-with-stat --pretty=fuller --parents $commit |
	sed '1 s/commit \([0-9a-f]*\)/Commit:     \1\nParent:    /'

which should look pretty (count the spaces to make sure it lines up 
right with the other fields).

(And if you ever want to report on merges, you'll want to change that a 
bit, but it should be reasonably close to the above)

		Linus