git-log --format missing trailing newline character

git-log --format missing trailing newline character

[Alejandro Colomar]

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

Hi!

I'm having trouble scripting around git-log(1), due to a missing newline
character at the end of the file.

	$ git -v
	git version 2.45.2
	$ git log --format=format:'%H' HEAD^^^..HEAD | wc -l
	2
	$ git log --format=format:'%H' HEAD^^^..HEAD
	2ff431ab1b46a25088fe40baf1faf35ea9fac722
	e75e6c4504022ae52d877926e63c908d9572088a
	178442837d39560a789a8044a8eb90fde3ad7cd7

Would you mind fixing this bug?  POSIX requires that text files end in a
newline character, precisely for being able to use UNIX tools to process
output from arbitrary commands.


Have a lovely night!
Alex

-- 
<https://www.alejandro-colomar.es/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: git-log --format missing trailing newline character

[Kristoffer Haugsbakk]

On Mon, Dec 23, 2024, at 21:28, Alejandro Colomar wrote:
> Hi!
>
> I'm having trouble scripting around git-log(1), due to a missing newline
> character at the end of the file.
>
> 	$ git -v
> 	git version 2.45.2
> 	$ git log --format=format:'%H' HEAD^^^..HEAD | wc -l
> 	2
> 	$ git log --format=format:'%H' HEAD^^^..HEAD
> 	2ff431ab1b46a25088fe40baf1faf35ea9fac722
> 	e75e6c4504022ae52d877926e63c908d9572088a
> 	178442837d39560a789a8044a8eb90fde3ad7cd7
>
> Would you mind fixing this bug?  POSIX requires that text files end in a
> newline character, precisely for being able to use UNIX tools to process
> output from arbitrary commands.

Is the format here simplified relative to your use case?  Or do you just
want to process commits as one-hash-per-line?  I would use
git-rev-list(1) instead in that case.

-- 
Kristoffer Haugsbakk

Re: git-log --format missing trailing newline character

[Alejandro Colomar]

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

Hi Kristoffer,

On Mon, Dec 23, 2024 at 09:36:48PM GMT, Kristoffer Haugsbakk wrote:
> On Mon, Dec 23, 2024, at 21:28, Alejandro Colomar wrote:
> > Hi!
> >
> > I'm having trouble scripting around git-log(1), due to a missing newline
> > character at the end of the file.
> >
> > 	$ git -v
> > 	git version 2.45.2
> > 	$ git log --format=format:'%H' HEAD^^^..HEAD | wc -l
> > 	2
> > 	$ git log --format=format:'%H' HEAD^^^..HEAD
> > 	2ff431ab1b46a25088fe40baf1faf35ea9fac722
> > 	e75e6c4504022ae52d877926e63c908d9572088a
> > 	178442837d39560a789a8044a8eb90fde3ad7cd7
> >
> > Would you mind fixing this bug?  POSIX requires that text files end in a
> > newline character, precisely for being able to use UNIX tools to process
> > output from arbitrary commands.
> 
> Is the format here simplified relative to your use case?  Or do you just
> want to process commits as one-hash-per-line?

I want to process commits as one-hash-per-line, yes.

The entire pipeline I have is this:

	git rev-list "$old..HEAD" \
	| sed 's,.*,https://www.alejandro-colomar.es/src/alx/linux/man-pages/man-pages.git/commit/?h=contrib\&id=&,';

which I run in <hooks/post-update> in my server for printing URIs to all
of the newly pushed commits.  I use that for easily pasting them to the
confirmation email I write to contributors when I apply and push one of
their patches.

>  I would use
> git-rev-list(1) instead in that case.

Hmmm, thanks!  I knew there had to be some git-rev-something for this,
but couldn't find it!  :)

I had workarounded it by doing

	git log --oneline --abbrev=40 | cut -f1 -d' '

However, git-rev-list(1) is better, of course, so I'll use it.

Anyway, it feels awkward that git-log(1) skips the last newline whith
--format=format.  Should that be fixed?


Have a lovely night!
Alex

> 
> -- 
> Kristoffer Haugsbakk
> 

-- 
<https://www.alejandro-colomar.es/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: git-log --format missing trailing newline character

[Andreas Schwab]

On Dez 23 2024, Alejandro Colomar wrote:

> Anyway, it feels awkward that git-log(1) skips the last newline whith
> --format=format.  Should that be fixed?

If you want terminator semantics, use tformat: instead of format:.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: git-log --format missing trailing newline character

[Alejandro Colomar]

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

Hi Andreas,

On Mon, Dec 23, 2024 at 10:09:14PM GMT, Andreas Schwab wrote:
> On Dez 23 2024, Alejandro Colomar wrote:
> 
> > Anyway, it feels awkward that git-log(1) skips the last newline whith
> > --format=format.  Should that be fixed?
> 
> If you want terminator semantics, use tformat: instead of format:.

Thanks!

Have a lovely night!
Alex

-- 
<https://www.alejandro-colomar.es/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: git-log --format missing trailing newline character

[Junio C Hamano]

Alejandro Colomar <alx@kernel.org> writes:

> Hi Andreas,
>
> On Mon, Dec 23, 2024 at 10:09:14PM GMT, Andreas Schwab wrote:
>> On Dez 23 2024, Alejandro Colomar wrote:
>> 
>> > Anyway, it feels awkward that git-log(1) skips the last newline whith
>> > --format=format.  Should that be fixed?
>> 
>> If you want terminator semantics, use tformat: instead of format:.

Or, "--format=%H" should do the right thing, as that is a mere
short-hand for "--pretty=tformat:%H".

Re: git-log --format missing trailing newline character

[Alejandro Colomar]

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

Hi Junio,

On Thu, Dec 26, 2024 at 08:00:42AM -0800, Junio C Hamano wrote:
> Alejandro Colomar <alx@kernel.org> writes:
> 
> > Hi Andreas,
> >
> > On Mon, Dec 23, 2024 at 10:09:14PM GMT, Andreas Schwab wrote:
> >> On Dez 23 2024, Alejandro Colomar wrote:
> >> 
> >> > Anyway, it feels awkward that git-log(1) skips the last newline whith
> >> > --format=format.  Should that be fixed?
> >> 
> >> If you want terminator semantics, use tformat: instead of format:.
> 
> Or, "--format=%H" should do the right thing, as that is a mere
> short-hand for "--pretty=tformat:%H".

Hmmm.  So many times having read that part of the manual, and I had
never noticed that.  I had never seen that tformat existed, and even
less that the default was it (when there's %placeholder string).  I had
always read 'format' instead of 'tformat'.  :)

Thanks!

-- 
<https://www.alejandro-colomar.es/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]